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 |