2.2.3 New IETF Standards Track Discussion (newtrk) Bof

Current Meeting Report

Newtrk session

Steve Bellovin (filling in for Scott Bradner) presided

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

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 

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 

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 

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 


Moving Forward on Working Group Snapshot
RFC Primary Marking