Subject: [newtrk] draft newtrk minutes

From: [email-masked] (Scott Bradner)
Date: Wed, 31 Mar 2004 22:23:03 -0500 (EST)

here is a cut at a set of minutes for newtrk based on teh jabber log

comments to me please

Scott

-----

DraftMinutes of Newtrk session

Steve Bellovin (filling in for Scott Bradner) presided

Spencer Dawkins gave a presentation on Working Group Snapshots.
	(See presentation)

Q: is a WGS ephemeral?  
Avri : do not see the point of WGS if ephemeral
Spencer: propose that WGS not ephemeral

Q: what about backward compatibility between standards and WGSs?
Spencer: a WGS is just a way that a WG can indicate that a proposal is
ready for review - the reviewers  may tear you to shreds - insisting on
backward compatibility would be the wrong thing

Q: is a WGS part of the standards process - e.g. to get implementation
experience? what if vendors implements then the WG changes the technology
and the vendor complains?
A: Spencer: the WG declares the purpose for a WGS - if purpose is to get
reviews then vendor implementation not recommended and any vendor who does
implement can be told "sorry that was the wrong thing to do."  

Allison Mankin: So there are different reasons to do a WGS, if one of the
reasons to do one is to interop testing, we used to do informational or
experimental RFCs for this.  Maybe WGS should not be overloaded.

Dave Crocker: I see a WGS as a general tool that could be used in a number
of ways including for WG internal coordination, its not always for public
status.

comment: lightweight process to define a WGS would be good - just let a WG
declare that a ID is a WGS

Charles Perkins: would be good to have a specific document that vendors
implement instead of random ephemeral IDs.  suppose you have a document
that is basic ally done but has a normative reference to something that
will not be done for a while - a WGS could stay around instead of expiring 

Spencer then presented John Loughney's slides.  The IETF is good at
generating RFCs but not good at generating or maintaining standards.
Outsiders do not have a clear idea what a particular standard entails.
The transport area has spun up a WG to try to define TCP.  A STD label can
lump multiple RFCs together.

discussion: what could live on a web page vs what should be in a RFC

Aaron Falk: this is an important issue since a RFC is not a living
document - once published it is fixed

James Polk: I can see how this could be used for SCTP but applying it to
IPSec could be hard, need to have a reason to update/obsolete a document,
could get quite large and unmanageable 

David Black: Echoing Aaron Falk's point - there are issues here that are
quite subjective - what does "deployed widely" or "known harmful" mean?

Harald: some states make sense and some do not - no new technology is
"deployed widely" - "write once read many" is probably better for the
Internet than having every user of IETF technology has to figure out all
this stuff on his own.

Allison Mankin gave a presentation on "RFC Primary Marking"
The issue is that people reading an Informational or Experimental RFC has
no way to know if the RFC is the product of IETF deliberation or was an
independent submission to the RFC Editor.  An additional problem is that a
document that was rejected by a WG can later be published a RFC by the RFC
Editor.  Currently the IESG does a full technical review of 
RFC Editor documents but the IESG has revisited the words in RFC 2026 and
in the future will only do the light review called for in RFC 2026.  Thus,
RFC Editor Informational and Experimental RFCs in the future will look
just like IETF generated Informational and Experimental  RFCs but will not
have the same level of review.  For example the IESG will not insist that
these documents have a Security Considerations section (though the RFC
Editor may do so).  The IESG currently plans to add a "secondary marker"
to such documents saying that the document was not reviewed by the IETF.

Bob Hinden: Two comments: 1/ maybe it would be better to put a label on
RFCs that are from the IETF instead of labeling what is not. 2/ the new
IESG review process (no security considerations sec etc) is close to what
some people would like to see in IESG review of IETF working group
documents.

Allison: It is not likely that the IESG will stop insisting on Security
Considerations sections in IETF documents.

Dave Crocker:  (1) The concern that people can not figure out what is and
is not an IETF RFC comes up every few years. There is always a concern of
some people abusing this confusion but we can not fix everything.  Also,
it has not shown that this behavior is breaking this, we just don't like
it. (2) we are low on money - how will this fix that? (3) we have a
serious crises in getting work done in a timely fashion; how will this fix
any of that?  There were something like 101 non-standards track RFCs last
year and 116 standards track.  A lot of lost effort went into reviewing
the non-standards track documents.

??: what do we do about already published RFCs? 

Steve Bellovin: They are grandfathered - once published RFCs never change

Sam Hartman: Do we still need individual submissions directly to the RFC
Editor outside the IETF process? (e.g. getting an AD to sponsor an
individual submission)

Larry Masinter: what's changed is that we were providing a useful service
publishing easily accessible documents that were not available other ways.
The service of accepting publications via RFC-Editor from outside the IETF
is solving a problem that's not there any more.

John Klensin: we've got a fairly sloppy standards process, which serves
the community well. One of the things that protects us in a consensus
environment is the ability to publish dissenting opinions in public view.

Steve Bellovin: there is no intention to disenfranchise that; see my
proposal to the IESG on publishing alternate things reviewed by WG.

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html