Re: The purpose of a Last Call
+1 If it's going to be an IETF Standard, it has to have IETF consensus. This seems consistent with the way individual (i.e., non-WG) submissions are handled through the IESG. Leslie. Pete Resnick wrote: On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote: Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about "working" groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? http://tools.ietf.org/rfc/rfc4844.txt http://tools.ietf.org/id/draft-irtf-rfcs-03.txt We have (IMO) historically screwed up with regard to IRTF and individual documents and not given them a proper stream to the RFC Editor. The above documents are dealing with that problem. However, for this particular case, I'm with Sam: An IRTF document that is going into the *IETF* standards track is pretty much akin to an any other organizations documents going into the IETF standards track. It may be the case that the IETF and IRTF have a lot more sharing of resources and visibility, than say the IETF and ITU or IEEE, and therefore the hand-off should be quite a bit easier. However, there is no doubt that this is *different* than a WG handing off a document to the IESG for standards track approval. A WG has (ostensibly) been subject to the direct observation of an AD all along and therefore the IESG should have a pretty full understanding of the IETF-wide consensus that has built up around any document coming out of that WG by the time the Last Call comes around. That's not going to be the case for an IRTF (or individual or other external organization) document. Yes, this is a less-than-efficient use of IETF Last Call. But if you want to make efficient use of the process for an *IETF* standards track document, work on it in the IETF. pr -- --- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
> "Pete" == Pete Resnick <[EMAIL PROTECTED]> writes: Pete> http://tools.ietf.org/rfc/rfc4844.txt Pete> http://tools.ietf.org/id/draft-irtf-rfcs-03.txt Pete> We have (IMO) historically screwed up with regard to IRTF Pete> and individual documents and not given them a proper stream Pete> to the RFC Editor. The above documents are dealing with that Pete> problem. As far as I can tell we're in agreement. Implicit in my comment was that this document was being published through the IETF stream. (I'll leave as an excersise for the pedants what happens if the IRTF tries to publish an informational document for the IETF stream.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The purpose of a Last Call
On 11/7/08 at 9:38 AM -0800, Dave CROCKER wrote: Sam Hartman wrote: It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about "working" groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? http://tools.ietf.org/rfc/rfc4844.txt http://tools.ietf.org/id/draft-irtf-rfcs-03.txt We have (IMO) historically screwed up with regard to IRTF and individual documents and not given them a proper stream to the RFC Editor. The above documents are dealing with that problem. However, for this particular case, I'm with Sam: An IRTF document that is going into the *IETF* standards track is pretty much akin to an any other organizations documents going into the IETF standards track. It may be the case that the IETF and IRTF have a lot more sharing of resources and visibility, than say the IETF and ITU or IEEE, and therefore the hand-off should be quite a bit easier. However, there is no doubt that this is *different* than a WG handing off a document to the IESG for standards track approval. A WG has (ostensibly) been subject to the direct observation of an AD all along and therefore the IESG should have a pretty full understanding of the IETF-wide consensus that has built up around any document coming out of that WG by the time the Last Call comes around. That's not going to be the case for an IRTF (or individual or other external organization) document. Yes, this is a less-than-efficient use of IETF Last Call. But if you want to make efficient use of the process for an *IETF* standards track document, work on it in the IETF. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The purpose of a Last Call
Sam Hartman wrote: > It seems quite clear to me that RFC 2418 does not apply at all to the output of an RG. Sam, I've looked around and the WG Guidelines doc happens to be the only place I could find that defines the purpose of a Last Call. The mere fact that the title of document is about "working" groups doesn't obviously limit the scope of that definition. Please explain. Perhaps there is documentation for the individual and RG avenues that I missed? From a process and consensus building standpoint, this last call needs to be treated the same as an individual submission, not WG output. RGs are not required to maintain the level of openness, minutes, etc that WGs do. Thus, they don't get the presumption of consensus that a WG does and the comments in 2418 about last calls do not apply. Even if a particular RG is open, it's still not a WG; just as we would expect input from an external organization to be treated through the individual process regardless of the As John said, there was quite a bit of history to this work. All of it entirely open. So I suspect this boils down to a question of whether there is a concern about actual history or formality of history, and whether you are suggesting that a Last Call for RG or Ind. Sub. carries an affirmative obligation for the submitters to provide a detailed review of the decision-making history for their work? Again: If someone sees a specific problem, presents it and explains why they think it is a problem, then having the submitters respond with details about the specific history of the relevant decision(s) makes complete sense. This, to me, is the essence of what a Last Call should deal with, no matter the source of the document. If, on the other hand, Last Call is an open invitation for an unbounded series of "why did you make this decision?" challenges, I'll ask you to explain how this is a community benefit, absent a broad consensus of concern, rather than its primarily serving to make the IETF approval process arbitrarily indeterminate. We have the real and concrete submission of a specification that documents existing practice and, so far, a solid demonstration of support for it. So what is the purpose of encouraging individuals to lodge open-ended challenges? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
