Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On Aug 28, 2009, at 4:13 AM, Dave CROCKER wrote: I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. As Russ said: the IESG can suggest text, which can be an IESG note. The RFC Editor, more specifically the Independent Submission Editor, is responsible for the followup, which includes the possibility of the variation described below. FWIW (and in my no-hats opinion) this 'negotiation' between IESG and ISE should all happen well before the RFC is submitted to the production center and the RFC Series Editor (RSE) should in general not be part of this loop. Only if the ISE and the IESG cannot come to agreement then the RSE is called in as described in RFC5620 section 4.1.3. ... I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. +1. One can debate various details and costs about the RFC Editor function. But it really is quite useful to have the editor exert an independent review of IESG efforts to modify an RFC. Not because the IESG is suspect, but because it is deeply involved in the topics it comments on and that could cause misguided decisions. By contrast, the RFC Editor can consider suggested IESG notes with detachment. My impression, too, is that this has produced revised IESG text. d/ -- Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On Jun 2, 2009, at 8:03 , Olaf Kolkman wrote: RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. Olaf, I believe this means in the contents of the document. I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. Olaf, I believe this means in the contents of the document. I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. The RFC Editor has a lot of discretion here. To date, the RFC Editor has never rejected an IESG Note. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On 2009-08-28 03:56, Russ Housley wrote: RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. Olaf, I believe this means in the contents of the document. I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. The RFC Editor has a lot of discretion here. To date, the RFC Editor has never rejected an IESG Note. I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. By the time an RFC comes out, it's too late for an appeal process to affect the outcome. So I find the current text of 3932bis completely appropriate. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. ... I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. +1. One can debate various details and costs about the RFC Editor function. But it really is quite useful to have the editor exert an independent review of IESG efforts to modify an RFC. Not because the IESG is suspect, but because it is deeply involved in the topics it comments on and that could cause misguided decisions. By contrast, the RFC Editor can consider suggested IESG notes with detachment. My impression, too, is that this has produced revised IESG text. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On 1 jun 2009, at 16:56, Jari Arkko wrote: I do think though that additional information at the level of This RFC describes FOO. A standardized version of FOO can be found from RFC . is useful. I think -07 version of the 3932bis is an improvement over the previous one, and should be approved. The proposed text would allow for these sort of suggestions to be made to the Independent Series Editor (ISE, the approval body for the Independent Submissions Stream). IMHO these relational notes would be useful additions to Independent stream documents. Maybe not even as an IESG Note but as language in the abstract and/or introduction. However, the proposed language would also allow standard templates to be added. That would IMHO be wrong. I understand that for many people the distinction between the various streams is not always clear and that a large number of folk think that the RFC series is synonymous with Internet Standard documents, but I do not think that the IESG Note is the magic bullet to solve that. In any case: RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. That wording is chosen in such a way that the decision is with the RFC Editor, more specifically the ISE. I would try to bring 3932bis in line with that: OLD: The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. NEW: The IESG may recommend [to the RFC Editor] to add an IESG note . The text in section 3 uses request which IMHO is in line with the spirit of 4846. And makes clear that the ISE could in fact push back on the recommendation or request. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I am bringing this draft to its second last call. After the completion of the headers and boilerplates document and extensive discussions within the IESG, it has become clear that several ADs had an issue with the 3932bis draft. I have asked Russ to post a new version which I believe resolves the issue. However, the changes -- even if small -- relate to what information there exists about the status of RFCs in the RFCs themselves, so I felt that it this is an issue that needs to be taken to the community. I am formally asking for the community review of the new version of the draft, but I like to think about this last call as a way to find out what the IETF community is thinking about the topic. Once we know, I hope we can approve the draft version that matches that opinion. Comments should be sent to the ietf@ietf.org mailing list. Note that there has been past discussion of what the header and boilerplates should say. This discussion happened on the rfc-interest list. 3932bis is about IESG notes and IESG processing, and the notes are of course very much related to what the boilerplates have already said. However, the boilerplates should be taken as given for the purposes of our discussion here. The rfc-interest list had consensus to publish the headers and boilerplates in its final form. Only changes to 3932bis are under consideration now. The core of the issue is what non-IETF RFCs say about their relationship to IETF. According to the new headers and boilerplates document, the source is clearly indicated. However, the issue brought up in the IESG review was that this can be insufficient at times. In general, additional information about the role of the relationship of the RFC to the IETF work would be useful for readers. The new version of the 3932bis draft suggests that the IESG may add a statement to a non-IETF RFC about its relationship to IETF work. Previous language indicated that such statements would be exceptional. The consensus view on the hb document was that the front matter should say what the RFC is, as opposed to saying what the RFC is not. IESG's issue with the 3932bis notes under this situation was three-fold. First, there is an assumption that the readers are familiar with the different streams (what they are and what they're not) -- which many readers of RFCs might not be. Second, the relationship between some non-IETF RFC and IETF work is often more complex than is captured by just the stream and maturity level. Third, additional explanation (not boilerplate) specific to the situation could help putting the work in context The relevant changes from the previous version of the draft are in Section 1.1: OLD: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents. NEW: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. and Section 3: OLD: Generally, the RFC headers and boilerplate clearly describe the relationship of the document to the IETF standards process [N3]. In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG response may be accompanied by a clarifying IESG note and a request that the RFC Editor include the IESG note in the document if the document is published. NEW: The RFC headers and boilerplate is intended to describe the relationship of the document to the IETF standards process [N3]. In addition the IESG may request that the RFC Editor include the IESG note to clarify the relationship of the document to the IETF standards process, such as pointers to related IETF RFCs. A more detailed diff is available at http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
And to start off the comments, I wanted tell my personal opinion about this. First, I have not been extremely happy with either the hb or the 3932bis document, as some people who have been reading the various lists may gather. However, I think they were already good enough to be shipped before the changes to 3932bis. (And indeed, hb has been shipped by the IAB.) And I can't get that excited about debates regarding the role of the various boilerplate texts, because I suspect that the only people reading them are the ones who are going to respond to this thread :-) I do think though that additional information at the level of This RFC describes FOO. A standardized version of FOO can be found from RFC . is useful. I think -07 version of the 3932bis is an improvement over the previous one, and should be approved. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
The changes described in your other note (copied after your text to preserve context) are reasonable in the abstract. However, the devil is in the details. As I understand it, the reason for calling the extra note exceptional is that the IESG has in the past sometimes used that note to place far more pejorative language than you suggest, in places that it really does not belong. That can turn a reasoanble publicaiton request into a political fight. In fact, in most cases where there is a published RFC on the same topic, the RFC Editor has demonstrated an expectation that the author will define accurately and clearly the relationship of their work to the existing published work. So it is not at all clear to me that the case you site is even particularly important. My inclination would be to stick with the OLD wording. Yours, Joel Jari Arkko wrote: And to start off the comments, I wanted tell my personal opinion about this. First, I have not been extremely happy with either the hb or the 3932bis document, as some people who have been reading the various lists may gather. However, I think they were already good enough to be shipped before the changes to 3932bis. (And indeed, hb has been shipped by the IAB.) And I can't get that excited about debates regarding the role of the various boilerplate texts, because I suspect that the only people reading them are the ones who are going to respond to this thread :-) I do think though that additional information at the level of This RFC describes FOO. A standardized version of FOO can be found from RFC . is useful. I think -07 version of the 3932bis is an improvement over the previous one, and should be approved. Jari (From Jari's earlier message...) The relevant changes from the previous version of the draft are in Section 1.1: OLD: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents. NEW: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. and Section 3: OLD: Generally, the RFC headers and boilerplate clearly describe the relationship of the document to the IETF standards process [N3]. In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG response may be accompanied by a clarifying IESG note and a request that the RFC Editor include the IESG note in the document if the document is published. NEW: The RFC headers and boilerplate is intended to describe the relationship of the document to the IETF standards process [N3]. In addition the IESG may request that the RFC Editor include the IESG note to clarify the relationship of the document to the IETF standards process, such as pointers to related IETF RFCs. A more detailed diff is available at http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Joel, However, the devil is in the details. As I understand it, the reason for calling the extra note exceptional is that the IESG has in the past sometimes used that note to place far more pejorative language than you suggest, in places that it really does not belong. That can turn a reasoanble publicaiton request into a political fight. That's true. However, I think that 3932bis (any version) is already supposed to reduce that problem, by not having standard, default pejorative language. The changes in -07 relate to the frequency of notes and their content. I'm not sure the frequency matters for avoiding the pejorative language problem. If the IESG puts in bad language, they can do so both in -06 and -07... if you want to solve that problem you need a couple of things: first, remove the bad default language. Second, provide a better instruction on what the note, if any, should contain. I think -07 is an improvement in this respect, because it now talks about the relationship of the RFC to IETF and pointers to standards track specifications. Third, the IESG folk simply need to have good judgment about using the notes. And if they don't, Nomcom should hear about it... Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Monday, June 01, 2009 18:30 +0300 Jari Arkko jari.ar...@piuha.net wrote: Joel, However, the devil is in the details. As I understand it, the reason for calling the extra note exceptional is that the IESG has in the past sometimes used that note to place far more pejorative language than you suggest, in places that it really does not belong. That can turn a reasoanble publicaiton request into a political fight. That's true. However, I think that 3932bis (any version) is already supposed to reduce that problem, by not having standard, default pejorative language. Joel, I share your concerns. While I have not yet read -07 carefully, my sense is that -06 was more satisfactory and that the substantive differences to -07 tend to reopen doors and encourage behavior best avoided. That said, 3932bis is clearly better than 3932 (at least as it has been interpreted) and I have to pretty much agree with Jari that the differences don't amount to anything if one or more ADs decide to misbehave and the IESG decides to go along. The changes in -07 relate to the frequency of notes and their content. I'm not sure the frequency matters for avoiding the pejorative language problem. If the IESG puts in bad language, they can do so both in -06 and -07... if you want to solve that problem you need a couple of things: first, remove the bad default language. Second, provide a better instruction on what the note, if any, should contain. I think -07 is an improvement in this respect, because it now talks about the relationship of the RFC to IETF and pointers to standards track specifications. Third, the IESG folk simply need to have good judgment about using the notes. And if they don't, Nomcom should hear about it... Actually, I would hope that, under the new RFC Editor system, the ISE and/or RSE would feel enabled to appeal every time the IESG pushes past the kind of evaluation or statements on which the spirit of both 3932 (as I originally read it) and 3932bis focus... or to simply ignore the IESG statement/request. Indeed, I would hope that, unless the reasons for the IESG statement are clear, that they would feel obligated to do so -- from my point of view, any legitimate situation in which the IESG feels obligated to make a statement is one in which authors and the ISE process have failed to make the document and its relationship to other work clear. In general, if the problems are real, it is better to fix documents that exhibit them than to patch in statements, regardless of where those are coming from. I hope and trust that it will never be necessary to develop or invoke procedures in that area. But, were abuses to occur, I would hope that there would be a sufficient record of appeals and the associated discussion to make the issues far more clear to a relevant Nomcom than just being passed a message. In fact, I'd expect an AD who lost one or two such appeals to either adjust his or her attitudes or resign, without having to wait for a Nomcom. I would encourage everyone interested in the topic to study the RFC Editor Model document, RFCs 4844 and 4846, and any job descriptions and SOWs to be sure that none of them contain any language that would prevent the use of the appeals process to deal with abuses in this area by IESG members. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Monday, June 01, 2009 17:47 +0300 Jari Arkko jari.ar...@piuha.net wrote: I am bringing this draft to its second last call. After the completion of the headers and boilerplates document and extensive discussions within the IESG, it has become clear that several ADs had an issue with the 3932bis draft. I have ... Note that there has been past discussion of what the header and boilerplates should say. This discussion happened on the rfc-interest list. 3932bis is about IESG notes and IESG processing, and the notes are of course very much related to what the boilerplates have already said. However, the boilerplates should be taken as given for the purposes of our discussion here. The rfc-interest list had consensus to publish the headers and boilerplates in its final form. Only changes to 3932bis are under consideration now. But there is one important interaction with what you write below. The big change (from today's forms) in Headers and Boilerplates isn't the identification of the stream. It is to permit (very nearly require), statements about review and level of consensus behind a document. Those statements are expected to be factual and (except for the IETF stream) do not depend on IESG judgments about protocol quality, relationships, etc. The core of the issue is what non-IETF RFCs say about their relationship to IETF. According to the new headers and boilerplates document, the source is clearly indicated. Not just the source, but the level and type of review and consensus. However, the issue brought up in the IESG review was that this can be insufficient at times. Insufficient if only the stream is identified? Or insufficient even after a kind of review and level of consensus statement is made? In general, additional information about the role of the relationship of the RFC to the IETF work would be useful for readers. The new version of the 3932bis draft suggests that the IESG may add a statement to a non-IETF RFC about its relationship to IETF work. Previous language indicated that such statements would be exceptional. If the intent is to make them common, I think there is a fundamental disconnect.If the intent is to not say exceptional but to treat them that way, then see my earlier response to you and Joel. The consensus view on the hb document was that the front matter should say what the RFC is, as opposed to saying what the RFC is not. IESG's issue with the 3932bis notes under this situation was three-fold. First, there is an assumption that the readers are familiar with the different streams (what they are and what they're not) -- which many readers of RFCs might not be. Second, the relationship between some non-IETF RFC and IETF work is often more complex than is captured by just the stream and maturity level. Third, additional explanation (not boilerplate) specific to the situation could help putting the work in context This discussion leads me to wonder whether the IESG has lost sight of the descriptions of relationships, review, and consensus for which HB provides. Is that possible? The relevant changes from the previous version of the draft are in Section 1.1: OLD: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents. NEW: The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. As written, this violates provisions of RFC 4846 as well as some of the language in the current RFC Editor Model draft. The IESG may _request_ that notes or other language be added.The ISE may respond to that by -- adding the notes, -- handing the document back to the authors with a request to address the underlying issues, -- adding some other note, presumably with the approval of the author(s), -- withdrawing the document, or -- rejecting the IESG request. In the last case, I would hope that the ISE would provide the IESG with an explanation. But nothing we have now requires that explanation or requires the ISE to engage in a dialogue with the IESG on the subject. And, IMO, that is the right balance. and Section 3: ... The Section 3 change does not encounter that procedural objection because it says ...the IESG may request john
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John, The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. As written, this violates provisions of RFC 4846 as well as some of the language in the current RFC Editor Model draft. The IESG may _request_ that notes or other language be added. Indeed -- thanks for catching this. It should say may choose to request or some words to that effect. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. As written, this violates provisions of RFC 4846 as well as some of the language in the current RFC Editor Model draft. The IESG may _request_ that notes or other language be added. Indeed -- thanks for catching this. It should say may choose to request or some words to that effect. I suggest: The IESG may request the inclusion of an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Monday, June 01, 2009 21:47 +0300 Jari Arkko jari.ar...@piuha.net wrote: As written, this violates provisions of RFC 4846 as well as some of the language in the current RFC Editor Model draft. The IESG may _request_ that notes or other language be added. Indeed -- thanks for catching this. It should say may choose to request or some words to that effect. Either that, or Russ's wording, would be fine with me. I believe that the bottom-line principles here are: (1) As above, the IESG requests that the ISE do things; it does not insert text or require that text be inserted. (2) Regardless of whether words like exceptional appear, the expectation should be that the typical independent submission document (or other non-IETF-stream document) will contain only the stream identification and whatever statements about review and consensus go with it, per headers and boilerplates. Requests for Additional statements should be unusual and very specific to the circumstances of a given document. (3) There are no statements to the effect that something is not an IETF-stream documents or, for that matter, not the Constitution of Lower Slobbovia. I don't think those need to be formally prohibited (partially because I have no idea how such a rule would be written) but I would hope that the ISE and RSE would ignore any such request. My impression has been that all three of those principles had already achieved consensus, either on the RFC-Internet list or in the process of reviewing and approving other documents. Of course, that impression could be wrong or the broader community could have something else to say. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-07.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a second Last Call. More information on why a second Last Call is needed will be provided by the responsible AD. The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-iesg-rfc3932bis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17615rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I am pleased to go with: The IESG has concluded that publication could potentially disrupt the IETF work done in WG X and recommends not publishing the document at this time. I'm OK with this as well. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
At 08:19 10-11-2008, Russ Housley wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? In a different message, John mentioned has concluded. That sounds better as the numbered items are about conclusions reached. My second preference would be The IESG believes. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? In a different message, John mentioned has concluded. That sounds better as the numbered items are about conclusions reached. My second preference would be The IESG believes. I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. 1. The IESG has concluded that there is no conflict between this document and IETF work. 2. The IESG has concluded that this work is related to IETF work done in WG X, but this relationship does not prevent publishing. 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for X and should therefore not be published without IETF review and IESG approval. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Russ, FWIW, I can live with this formulation. I would still prefer to get rid of harmful... see below. --On Thursday, 13 November, 2008 12:41 -0500 Russ Housley [EMAIL PROTECTED] wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. ... I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. ... 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. I would recommend replacing is potentially harmful with something like could impede the smooth progress of. That eliminates the issue of harm and replaces it with what is actually a slightly weaker condition. Phrases like could potentially disrupt would be roughly equivalent, again without implying that the IETF process is so fragile that the publication of a document could harm it. But, if the IESG is ok with that implication of fragility and you prefer to leave harmful, I can live with it. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John: I am pleased to go with: The IESG has concluded that publication could potentially disrupt the IETF work done in WG X and recommends not publishing the document at this time. Thanks for the suggestions. Russ At 01:01 PM 11/13/2008, John C Klensin wrote: Russ, FWIW, I can live with this formulation. I would still prefer to get rid of harmful... see below. --On Thursday, 13 November, 2008 12:41 -0500 Russ Housley [EMAIL PROTECTED] wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. ... I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. ... 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. I would recommend replacing is potentially harmful with something like could impede the smooth progress of. That eliminates the issue of harm and replaces it with what is actually a slightly weaker condition. Phrases like could potentially disrupt would be roughly equivalent, again without implying that the IETF process is so fragile that the publication of a document could harm it. But, if the IESG is ok with that implication of fragility and you prefer to leave harmful, I can live with it. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Monday, 10 November, 2008 11:19 -0500 Russ Housley [EMAIL PROTECTED] wrote: John: In the previous note from me, I responded to you and Jari on your main points. In this note, I am responding to your editorial points. Textual nit-picking * The second full paragraph of the Introduction (The IETF is responsible...), second sentence, should read ..., and any other IETF-generated Informational or Experimental documents. Otherwise, one may suck most of the Independent Submission ... I agree. The revised sentence reads: These RFCs, and any other IETF-generated Informational or Experimental documents, are reviewed by appropriate IETF bodies and published as part of the IETF Stream. Excellent * The document is confused about tense and mood of particular words and the general tone of the language used. For example, Section 1 Paragraph 5, last sentence, says ...was a considerable drain... this is not and should probably should have been ...this was not. As another example, consider ... Agree: s/this is not/this was not/ To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. Much better. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? I find (sic) that find is better than thinks, but probably prefer believes. has concluded would be even better, IMO. * The assertion in paragraph 7 of Section 1 is not correct. While it probably was the case in the years _immediately_ preceding 2006, there was a period of several years in which the IAB performed a (sometimes pro-forma) review of IRTF ... I suggest the following change to the first sentence in that paragraph: Prior to 2006, documents from the IRTF were treated as either IAB submissions or individual submissions via the RFC Editor. That would be correct. Thanks. * If you really want to right to claim harmful to the Internet, then Section 6 is incomplete, because some of the classes of harm that you might be trying to prevent involve security. Are you talking about this paragraph? If the IESG does not find any conflict between an independent submission and IETF work, then the RFC Editor is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. If the IESG does not find any conflict between an IRTF submission and IETF work, then the IRSG is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. Not really. Most of the really problematic text about harm has been removed, for which I thank you. But, just as we have (correctly, IMO) been quite insistent that publication of a document cannot infringe anyone's (non-copyright) IPR, it is hard for me to believe that the publication of a document can harm the Internet or even harm the IETF's standards process. Cause some operational difficulties if implemented, yes. Cause some confusion if published out of sequence with other work, probably. But I think this document would be enhanced if all language about harm resulting from publication (even the above) were removed and replaced by language describing what sort of damage is being anticipated or prevented. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John, That was a long list of issues. Let me start off by saying that RFC 3932 is already a part of the daily procedures we operate on. Draft-housley was written to make an incremental improvement on it. This incremental improvement is the publication of the headers and boilerplates document, which allows us to simplify the process for independent submissions and requires less use of IESG notes. I believe we both share the opinion that these are necessary and useful improvements. And, given that the headers and boilerplates change is going forward I hope we can accomplish the 3932 revision at the same time. Some more detailed answers: (1) The IESG should never make an assertion that is known to be false. ... Even if the IESG has not reviewed a document, it doesn't imply that the IETF has not. I agree that some independent submission stream documents have been in the IETF discussions. The issue is whether any sort of final review occurred. I'd be happy to see a wording change here. E.g., Documents published in streams other than the IETF Stream are not reviewed by the IETF for such things ... = Documents published in streams other than the IETF Stream do not get a full review and are not required to get any review by the IETF for such things ... The second sentence of that paragraph should be removed entirely unless the IESG wants to deprive itself of flexibility to formally ask for community input by prohibiting the use of Last Calls on Independent Submission drafts (a flexibility that language in 4846 was intended to preserve). As I commented to SM, I do believe the IESG needs to have the room to make judgment calls. In the case that I mentioned in that e-mail, we actually did ask for community input (after first getting some unsolicited input :-), though not in the form of document review or a last call. Again, I would like to see a change in the document on this. (2) The numbered list in Section 3 is the substantive core of this document. Harmful in Item 3 is potentially damaging to, or problematic for, the IETF Standards Process, not harmful to the Internet. Yes. And this is what is says: harmful to the IETF work. Potentially is important there too. The IESG should not be expected to foretell possible futures or provide an analysis of how damage might occur: it should merely have to have a reasonable basis for believing that WG or other standards process disruption might occur or that an end-run is being attempted. I agree and I support adding this word. On your sweeping issue: I believe most of the practical applicability of RFC 3932 has been in the area of checking for conflict with WG process (response 3) and IANA rules (response 4). Again, response 3 text is IMHO already clear. That being said, I do believe there should be an opportunity check for possible harm as stated in response 5 as well. From my perspective that item is reserved for the cases where we, e.g., old protocols for which no IANA procedures have been defined. The practical reality is that we find such cases daily. We could make the text more specific, require more last calls and steps before such claims can be made. But frankly, I do not want to turn the independent submission process into a one that requires IETF review; it seems counter-intuitive. The IESG should make a quick check as described in the document, and if they screw up, the next step should be an appeal or talking to the nomcom. Of course, as I already explained I don't mind stating that a last call might be a useful tool in some special cases. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John Jari: Let me start off by saying that RFC 3932 is already a part of the daily procedures we operate on. Draft-housley was written to make an incremental improvement on it. This incremental improvement is the publication of the headers and boilerplates document, which allows us to simplify the process for independent submissions and requires less use of IESG notes. I believe we both share the opinion that these are necessary and useful improvements. And, given that the headers and boilerplates change is going forward I hope we can accomplish the 3932 revision at the same time. Some more detailed answers: (1) The IESG should never make an assertion that is known to be false. ... Even if the IESG has not reviewed a document, it doesn't imply that the IETF has not. I agree that some independent submission stream documents have been in the IETF discussions. The issue is whether any sort of final review occurred. I'd be happy to see a wording change here. E.g., Documents published in streams other than the IETF Stream are not reviewed by the IETF for such things ... = Documents published in streams other than the IETF Stream do not get a full review and are not required to get any review by the IETF for such things ... Even if such a document started in the IETF process, it did not complete the IETF process. I can imagine a situation where a document goes to IETF Last Call that demonstrates that there is not consensus, and that document ends up being published in the individual submission stream, but that has not happened in my memory. It certainly is not the normal situation. I suggest: Documents published in streams other than the IETF Stream do not receive full review by the IETF for such things as security, congestion control, or inappropriate interaction with deployed protocols. The second sentence of that paragraph should be removed entirely unless the IESG wants to deprive itself of flexibility to formally ask for community input by prohibiting the use of Last Calls on Independent Submission drafts (a flexibility that language in 4846 was intended to preserve). As I commented to SM, I do believe the IESG needs to have the room to make judgment calls. In the case that I mentioned in that e-mail, we actually did ask for community input (after first getting some unsolicited input :-), though not in the form of document review or a last call. Again, I would like to see a change in the document on this. I suggest a replacement sentence: Generally, there is no attempt for IETF consensus or IESG approval. (2) The numbered list in Section 3 is the substantive core of this document. Harmful in Item 3 is potentially damaging to, or problematic for, the IETF Standards Process, not harmful to the Internet. Yes. And this is what is says: harmful to the IETF work. Potentially is important there too. The IESG should not be expected to foretell possible futures or provide an analysis of how damage might occur: it should merely have to have a reasonable basis for believing that WG or other standards process disruption might occur or that an end-run is being attempted. I agree and I support adding this word. The revised sentence says: The IESG finds that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. On your sweeping issue: I believe most of the practical applicability of RFC 3932 has been in the area of checking for conflict with WG process (response 3) and IANA rules (response 4). Again, response 3 text is IMHO already clear. That being said, I do believe there should be an opportunity check for possible harm as stated in response 5 as well. From my perspective that item is reserved for the cases where we, e.g., old protocols for which no IANA procedures have been defined. The practical reality is that we find such cases daily. We could make the text more specific, require more last calls and steps before such claims can be made. But frankly, I do not want to turn the independent submission process into a one that requires IETF review; it seems counter-intuitive. The IESG should make a quick check as described in the document, and if they screw up, the next step should be an appeal or talking to the nomcom. Of course, as I already explained I don't mind stating that a last call might be a useful tool in some special cases. This was the whole point of RFC 3932 and the subsequent creation of the RFC Editorial Board. The IESG received the following comment. I think it is okay to share here with the sender's identity removed. | I think the draft is good as it is. I don't plan to respond in detail to | John Klensin's comments, but my bottom line is that I think the proposed | wording is correct. I do support the independence of the Independent stream, | but I don't think that deprives the IESG of the right to speak for the | IETF in asserting harm,
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
SM, Thanks for your review and thank you Russ for the edits. I'll just comment on the one remaining issue: 3. The IESG finds that publication is harmful to the IETF work done in WG X and recommends not publishing the document at this time. I don't think that harmful is appropriate here. I gather that the aim is to prevent circumvention of the IETF process and conflicts with work being carried out by the Working Group. It could be phrased as: The IESG finds that this work is related to IETF work done in WG X and recommends not publishing the document at this time. The issue is that mere conflict with work in a WG is not a sufficient reason to recommend against publishing. The IESG needs to make a judgment call that such publication would actually be harmful to the standardization process in the WG. For instance, in a recent case we approved an independent publication even if the document was clearly in the domain of a WG because we felt the circumstances supported it. You have to consider a number of aspects, where the WG is in its process, whether the particular submission is likely to confuse the process, etc. I don't care so much what words we use to say this, but I would like to see that the ability to make this judgment call is retained. This is why I like the current text more than the proposed one above. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John: In the previous note from me, I responded to you and Jari on your main points. In this note, I am responding to your editorial points. Textual nit-picking * The second full paragraph of the Introduction (The IETF is responsible...), second sentence, should read ..., and any other IETF-generated Informational or Experimental documents. Otherwise, one may suck most of the Independent Submission stream into the IETF stream, contradicting the rest of the document. Part of the problem with the text that is now in the document is that there is no clear definition of standards-related. I agree. The revised sentence reads: These RFCs, and any other IETF-generated Informational or Experimental documents, are reviewed by appropriate IETF bodies and published as part of the IETF Stream. * The document is confused about tense and mood of particular words and the general tone of the language used. For example, Section 1 Paragraph 5, last sentence, says ...was a considerable drain... this is not and should probably should have been ...this was not. As another example, consider the numbered list in Section 3. The first item says has not found, but the others are The IESG finds. Note also the difference between a finding and the result of an unsuccessful search (we looked for it and didn't find it). Personally, I believe that the notion of the IESG making findings excessively judicial -- several of these items are really statements about the IESG's beliefs-- but that is a matter of taste. Agree: s/this is not/this was not/ To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? * The assertion in paragraph 7 of Section 1 is not correct. While it probably was the case in the years _immediately_ preceding 2006, there was a period of several years in which the IAB performed a (sometimes pro-forma) review of IRTF Informational and Experimental documents and then published them as IAB documents, with minimal or no interaction with the IESG. Of course, IRTF submissions onto the standards track (if not entirely prohibited) are outside the scope of this document. I suggest the following change to the first sentence in that paragraph: Prior to 2006, documents from the IRTF were treated as either IAB submissions or individual submissions via the RFC Editor. * If you really want to right to claim harmful to the Internet, then Section 6 is incomplete, because some of the classes of harm that you might be trying to prevent involve security. Are you talking about this paragraph? If the IESG does not find any conflict between an independent submission and IETF work, then the RFC Editor is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. If the IESG does not find any conflict between an IRTF submission and IETF work, then the IRSG is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. * Finally, unless the omission from the Acknowledgments was intended as an editorial comment, I call your attention to the rather extensive discussion I participated in about this document among Jari, Olaf, yourself, and sometimes Leslie and Harald in early October. Although I identified the historical problem with the description of IRTF processes there (a comment that was apparently ignored, since the problematic text is still present), several of my comments made it into the document. I believe that that the IETF's IPR rules, as well as ordinary courtesy, require that set of contributions (which certainly include Jari's) be reflected in the Acknowledgments. That is clearly a nit and, at some level, I don't care. But it also suggests, especially in context with some of the issues raised above, that this document has been handled somewhat less carefully that might be appropriate for something of its importance. The acknowledgements now include these names: Jari Arkko, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, and Olaf Kolkman. My apologies to anyone who was inadvertently omitted. If others ought to be included as well, please speak up. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Hi Russ, At 14:10 09-11-2008, Russ Housley wrote: Not all Informational and Experimental documents are standards-related. Some are. Not all Informational and Experimental documents are published as part of the IETF stream. Some are. I'm not sure what text change would help add clarity. I understand that. You provided some text in a later message which sounds better. This is very similar to the point raised by John Klensin. Since harmful is the term used in RFC 3292, I have asked Harald to provide some insights before making any changes to this wording. I understand your point, but I want to make sure that I'm not missing some historical context. Jari's message provided me an insight of why the word is used and about documents on which the IESG reaches conclusion 5. The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of independent submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions. That sounds better. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Hi Jari, At 03:33 10-11-2008, Jari Arkko wrote: The issue is that mere conflict with work in a WG is not a sufficient reason to recommend against publishing. The IESG needs to make a judgment call that such publication would actually be harmful to the standardization process in the WG. For instance, in a recent case we approved an independent publication even if the document was clearly in the domain of a WG because we felt the circumstances supported it. You have to consider a number of aspects, where the WG is in its process, whether the particular submission is likely to confuse the process, etc. I see your point. I do expect the IESG to make a judgement call and not turn down a work merely because it may have some relation to the work being carried out in a Working Group. Although I don't like the word harmful, I see the rationale for that word in the text. I don't care so much what words we use to say this, but I would like to see that the ability to make this judgment call is retained. This is why I like the current text more than the proposed one above. I agree with you. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Thanks for your review. My responses below. The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-04.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the I'm commenting on draft-housley-iesg-rfc3932bis-05 as that's the latest version at the moment. In Section 1: These RFCs, and any other Informational or Experimental standards-related documents, are reviewed by appropriate IETF bodies and published as part of the IETF Stream. I read that as Informational and Experimental are also standards-related. This is at odds with statements such as This memo does not specify an Internet standard of any kind. which is usually seen in Informational and Experimental documents. Not all Informational and Experimental documents are standards-related. Some are. Not all Informational and Experimental documents are published as part of the IETF stream. Some are. I'm not sure what text change would help add clarity. Although most people know what WG is, it doesn't hurt to have the following for clarity: This review was often a full-scale review of technical content, with the Area Director (ADs) attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups (WG) and so on. Sure. In Section 3: 3. The IESG finds that publication is harmful to the IETF work done in WG X and recommends not publishing the document at this time. I don't think that harmful is appropriate here. I gather that the aim is to prevent circumvention of the IETF process and conflicts with work being carried out by the Working Group. It could be phrased as: The IESG finds that this work is related to IETF work done in WG X and recommends not publishing the document at this time. This is very similar to the point raised by John Klensin. Since harmful is the term used in RFC 3292, I have asked Harald to provide some insights before making any changes to this wording. I understand your point, but I want to make sure that I'm not missing some historical context. 5. The IESG finds that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. I read that as we cannot publish this document as it requires IETF review and IESG approval. It may be easier for all parties to ask for an IETF review instead of rejecting publication outright. The point is that a different publication path, not the Independent Publication Stream, is needed to obtain the IETF review. That is the point of the IETF stream. The IESG assumes that the RFC Editor, in agreement with the IAB, will manage mechanisms for appropriate technical review of independent submissions. Likewise, the IESG also assumes that the IRSG, in agreement with the IAB, will manage mechanisms for appropriate technical review of IRTF submissions. I don't see why there has to be assumptions here. I suggest dropping the assumes and clearly spell out who is going to manage what. How about: The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of independent submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
At 07:02 21-10-2008, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-04.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the I'm commenting on draft-housley-iesg-rfc3932bis-05 as that's the latest version at the moment. In Section 1: These RFCs, and any other Informational or Experimental standards-related documents, are reviewed by appropriate IETF bodies and published as part of the IETF Stream. I read that as Informational and Experimental are also standards-related. This is at odds with statements such as This memo does not specify an Internet standard of any kind. which is usually seen in Informational and Experimental documents. Although most people know what WG is, it doesn't hurt to have the following for clarity: This review was often a full-scale review of technical content, with the Area Director (ADs) attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups (WG) and so on. In Section 3: 3. The IESG finds that publication is harmful to the IETF work done in WG X and recommends not publishing the document at this time. I don't think that harmful is appropriate here. I gather that the aim is to prevent circumvention of the IETF process and conflicts with work being carried out by the Working Group. It could be phrased as: The IESG finds that this work is related to IETF work done in WG X and recommends not publishing the document at this time. 5. The IESG finds that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. I read that as we cannot publish this document as it requires IETF review and IESG approval. It may be easier for all parties to ask for an IETF review instead of rejecting publication outright. The IESG assumes that the RFC Editor, in agreement with the IAB, will manage mechanisms for appropriate technical review of independent submissions. Likewise, the IESG also assumes that the IRSG, in agreement with the IAB, will manage mechanisms for appropriate technical review of IRTF submissions. I don't see why there has to be assumptions here. I suggest dropping the assumes and clearly spell out who is going to manage what. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
--On Tuesday, 21 October, 2008 08:02 -0700 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-04.txt as a BCP Russ, Harald, and IESG, While the version listed in the Last Call was -04, I note that -05 has been posted and my comments are addressed to it. As a procedural observation, my recollection is that, for many years, the IESG has been discouraging posting of new versions of documents during Last Call, precisely to avoid confusion about which version to comment on. While this document is much improved from earlier versions, I believe it is not nearly ready for BCP publication. I see sweeping and more specific issues as well as several nits. Sweeping Issue: The assertion of harm is a very serious one. We claim that the Internet is incredibly robust and that there are few proposed changes that can actually cause significant damage. If the places in which harm is used in this document are really intended to mean contrary to the spirit of the IETF standards process or even damaging to the effectiveness of the standards process, then say that. Note that the first example in Section 4 is clearly about something that is problematic for the standards process with no need to believe that the alternate path is harmful to the Internet, while the second one falls into the category of an inappropriate extension (more discussion on that below). Even getting from hard-to-debug interoperability problems to harm to the Internet would be a stretch (if the authors had been able to produce a careful explanation of how to experiment with those bits in an escape-proof walled garden, the document might still describe a bad idea, but that would become a technical judgment --one that this document asserts the IESG is not supposed to make-- and it would not have been, a priori, harmful. I believe that the assertion of harm to the Internet is a sufficiently strong one that the IESG should not make it without clear evidence of community consensus, starting with an explanation of why it thinks there is a problem (nor merely asserting harm) and including an IETF-wide Last Call on the assertion and explanation. Specific Issues (1) The IESG should never make an assertion that is known to be false. This has been an issue since 3932 was published and then interpreted in a way that several of us did not anticipate; a revision should not require the IESG to lie (or continue lying). The fact is that, subject to publication delay, this document and RFC 4846 permit publication of documents considered by WGs and rejected. In addition, some Independent Submissions receive very extensive review in the IETF. I hope we are not moving into the sort of lawyer-land in which formally disclaiming knowledge --counter to observable fact that the knowledge exists-- may have a special meaning. Even if the IESG has not reviewed a document, it doesn't imply that the IETF has not. If we are not moving to that part of lawyer-land, then it may be appropriate to say that the IETF takes no position on whether a document meets certain criteria or that there was no determination of IETF consensus, but it is not appropriate to say that the IETF disclaims knowledge (or has no knowledge) without a case-by-case determination of whether any significant review within the IETF occurred. The third paragraph of the Introduction should be modified to change are not reviewed to are not required to be reviewed or equivalent. The second sentence of that paragraph should be removed entirely unless the IESG wants to deprive itself of flexibility to formally ask for community input by prohibiting the use of Last Calls on Independent Submission drafts (a flexibility that language in 4846 was intended to preserve). As a further example of this problem, consider the last paragraph of the Introduction, where the text talks about the IESG pushing a document into the Independent stream that had been submitted to the IETF. Such documents are often reviewed in the IETF before being called to the IESG's attention via a publication request and then presumably reviewed and discussed by the IESG (or at least parts of it). (2) The numbered list in Section 3 is the substantive core of this document. Harmful in Item 3 is potentially damaging to, or problematic for, the IETF Standards Process, not harmful to the Internet. Potentially is important there too. The IESG should not be expected to foretell possible futures or provide an analysis of how damage might occur: it should merely have to have a reasonable basis for believing that WG or other standards process disruption might occur or that an end-run is being attempted. Item 5, when read in the context of paragraph 5 of that section (The last two...) is a horse of a different color. Let me restate what is
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I'm happy with this version. I think it updates the procedures in accordance with what we've learned since RFC3932. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'IESG Procedures for Handling of Independent and IRTF Stream Submissions ' draft-housley-iesg-rfc3932bis-04.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-11-18. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. We would also like to draw your attention to two documents that are referenced normatively. The first one, RFC 4844, defines the current RFC streams, and it was felt that this RFC should be a normative reference despite its classification as Informational. The second reference, draft-iab-streams-headers-boilerplates, is a document that the IAB will shortly send for public review and eventual publication as an RFC. It is a companion document to draft-housley; the clear indication of the source of an RFC eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents. The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-iesg-rfc3932bis-04.txt Differences to RFC 3932 can be found here: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17615rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
