Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RJ Atkinson wrote: ... BOTTOM LINE: There seems to be clear consensus amongst folks outside the IESG that (1) there is no current problem and (2) no process change is warranted to make IESG notes mandatory on non-IETF-track documents. +1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkquTaQACgkQE5f5cImnZrslVwCglTLLQLG+CyzUvJcTQclN93NC n8YAnj3TKxXsqEHjvsl0Ur2+OAa7uh1y =T1Qd -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 14 Sep 2009, at 10:00, Polk, William T. wrote: IMHO, the current text places a responsibility on the IESG to deal with exceptional circumstances but fails to provide the tools to execute that responsibility. After 27 years in government, I have a lot of experience with assignment of responsibility without authority, and none of it was positive. It is interesting to better understand your perspective. I would have read the current text in a nearly inverted meaning: providing authority to deal with someone trying to make an 'end run' around the IETF in some area of current IETF effort, by requesting the RFC-Editor to add an IESG note in such a case, but not requiring the IESG to do so. To me, the most relevant datum is that we have more than 15 years of operational experience with the current setup, and zero actual problems. [...stuff deleted here...] 3) As I understand things, and on this I might be a bit out-dated as to the current state of things, there is a concrete proposal to also add to each RFC (starting in the near future and continuing forward) the specific Document Stream (i.e. IETF, IRTF, IAB, Independent Submission) via which a particular RFC was published. I have no objection to that addition. I don't think that it is really necessary, given (1) and (2) above, but it seems to make some folks more comfortable and I don't immediately see any harm in that addition. I actually think this is a very good addition, precisely because I believe (1) and (2) are insufficient. If the reader reads and understands the boilerplate, we have the 98% solution. (I personally have my doubts about reading and understanding the boilerplate, This parenthetical bit just above is confusing, and (at least to me) non-obvious. Why would someone who can read sufficiently well to understand the content of an RFC have trouble distinguishing between the Status of this Memo texts AND also have trouble understanding the RFC's Category field ? but I believe that is the criteria the community would have the IESG apply: Assuming the reader understands the headers and boilerplate, is a note really needed?) I'm glad that you agree that seems to be the (most of the) community's perspective. [...stuff deleted here...] [I wouldn't assume that anyone speaks for the IESG on this topic, especially me! This represents my personal views only.] Fair enough. Thanks for the explanations. At a minimum, I think I understand your perspective much better. Yours, Ran Atkinson r...@extremenetworks.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi Ran, I have specific responses in-line, but I'll start with a summary of sorts for less patient readers. IMHO, the current text places a responsibility on the IESG to deal with exceptional circumstances but fails to provide the tools to execute that responsibility. After 27 years in government, I have a lot of experience with assignment of responsibility without authority, and none of it was positive. I completely accept the community's consensus that IESG notes should be reserved for the egregious cases, if any should emerge, but I would like to see a process for achieving that goal where *necessary*. Making notes mandatory is one possible mechanism, although others might be preferable. I personally support the position outlined in Jari's 9/13/09 email... On 9/12/09 7:20 AM, RJ Atkinson r...@extremenetworks.com wrote: Earlier, Tim Polk wrote (in part): % And are we really helping anyone by not clarifying the % relationship between the document and other RFCs? % % Shouldn't we provide this information as a % service to the reader? Tim, I like you, but your reasoning on this topic comes across as very confused or incompletely informed. Both of which may be true... but I'll give it another shot anyway. The information you discuss is ALREADY available and HAS BEEN available for well over a DECADE now. To be frank, the status is also very very clear to anyone who actually glances at any modern RFC. 1) Each modern RFC has a Category field in the header on the first page. This dates back at least to RFC-1517, which was published in September 1993 -- 16 years ago. 2) Separately, and for redundancy, the Status of This Memo field has made that information available in less abbreviated form. To pick two arbitrary examples from ~15 years ago that illustrate both that the markings are QUITE CLEAR at even a quick glance AND that these markings go back MANY years now: A) RFC-1704 On Internet Authentication http://www.rfc-editor.org/rfc/rfc1704.txt 1) Category: Informational (top left corner) 2) Status of this Memo says in entirety: This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. B) RFC-1626 IP MTU for use over ATM AAL5 http://www.rfc-editor.org/rfc/rfc1626.txt 1) Category: Standards Track (top left corner) 2) Status of this Memo says in entirety: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. I don't know think that this is a core issue, since it is addressed in the headers and boilerplates document, but I don't think Category and Status of Memo provide all the information needed. Even assuming the reader looks at the boilerplate and understands provided information, there is a difference in my mind between an informational (or experimental) RFC that comes from the IETF process or the IRTF process than one that is an independent submission. It is information the reader might want to factor into any implementation or deployment decisions, but is not available. 3) As I understand things, and on this I might be a bit out-dated as to the current state of things, there is a concrete proposal to also add to each RFC (starting in the near future and continuing forward) the specific Document Stream (i.e. IETF, IRTF, IAB, Independent Submission) via which a particular RFC was published. I have no objection to that addition. I don't think that it is really necessary, given (1) and (2) above, but it seems to make some folks more comfortable and I don't immediately see any harm in that addition. I actually think this is a very good addition, precisely because I believe (1) and (2) are insufficient. If the reader reads and understands the boilerplate, we have the 98% solution. (I personally have my doubts about reading and understanding the boilerplate, but I believe that is the criteria the community would have the IESG apply: Assuming the reader understands the headers and boilerplate, is a note really needed?) ANALYSIS: Noel's recent note pointing to Donald Eastlake's note is an accurate summary of the situation. We have substantial actual operational experience indicating that IESG notes are handled appropriately by the RFC Editor team. There is zero evidence of a problem. So there is no reasonable cause to make IESG notes on non-IETF-track documents mandatory. Separately, The IESG lacks authority over the
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 9/14/09 10:13 AM, RJ Atkinson r...@extremenetworks.com wrote: On 14 Sep 2009, at 10:00, Polk, William T. wrote: IMHO, the current text places a responsibility on the IESG to deal with exceptional circumstances but fails to provide the tools to execute that responsibility. After 27 years in government, I have a lot of experience with assignment of responsibility without authority, and none of it was positive. It is interesting to better understand your perspective. I would have read the current text in a nearly inverted meaning: providing authority to deal with someone trying to make an 'end run' around the IETF in some area of current IETF effort, by requesting the RFC-Editor to add an IESG note in such a case, but not requiring the IESG to do so. It is a fair observation... The word responsibility doesn't appear, so that is just the way I interpret it. Since this option is reserved for exceptional cases, I guess I think the IESG would have an obligation to address the issue, but that may be an AD-specific reading. To me, the most relevant datum is that we have more than 15 years of operational experience with the current setup, and zero actual problems. If we are lucky, this a painful exercise to establish process that will not need to be tested in practice. I certainly hope that is the case. [...stuff deleted here...] 3) As I understand things, and on this I might be a bit out-dated as to the current state of things, there is a concrete proposal to also add to each RFC (starting in the near future and continuing forward) the specific Document Stream (i.e. IETF, IRTF, IAB, Independent Submission) via which a particular RFC was published. I have no objection to that addition. I don't think that it is really necessary, given (1) and (2) above, but it seems to make some folks more comfortable and I don't immediately see any harm in that addition. I actually think this is a very good addition, precisely because I believe (1) and (2) are insufficient. If the reader reads and understands the boilerplate, we have the 98% solution. (I personally have my doubts about reading and understanding the boilerplate, This parenthetical bit just above is confusing, and (at least to me) non-obvious. Why would someone who can read sufficiently well to understand the content of an RFC have trouble distinguishing between the Status of this Memo texts AND also have trouble understanding the RFC's Category field ? It's not that the reader can't, it's that they *won't*. I don't believe readers always read the boilerplate, and I don't think many readers bother to research the difference between the categories. I find even long time members of the IETF Community can debate whether a particular document should be PS vs. BCP vs. Informational for a long time, so I am sure that the nuances will be lost on the casual reader. However, my limited expectations of the reader are irrelevant beyond confirming my pessimistic nature. I think the test we should apply is for people that will read and understand the boilerplate. (Otherwise, they wouldn't see the IESG note anyway!) but I believe that is the criteria the community would have the IESG apply: Assuming the reader understands the headers and boilerplate, is a note really needed?) I'm glad that you agree that seems to be the (most of the) community's perspective. [...stuff deleted here...] [I wouldn't assume that anyone speaks for the IESG on this topic, especially me! This represents my personal views only.] Fair enough. Thanks for the explanations. At a minimum, I think I understand your perspective much better. +1 Tim Yours, Ran Atkinson r...@extremenetworks.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Earlier, Tim Polk wrote (in part): % And are we really helping anyone by not clarifying the % relationship between the document and other RFCs? % % Shouldn't we provide this information as a % service to the reader? Tim, I like you, but your reasoning on this topic comes across as very confused or incompletely informed. The information you discuss is ALREADY available and HAS BEEN available for well over a DECADE now. To be frank, the status is also very very clear to anyone who actually glances at any modern RFC. 1) Each modern RFC has a Category field in the header on the first page. This dates back at least to RFC-1517, which was published in September 1993 -- 16 years ago. 2) Separately, and for redundancy, the Status of This Memo field has made that information available in less abbreviated form. To pick two arbitrary examples from ~15 years ago that illustrate both that the markings are QUITE CLEAR at even a quick glance AND that these markings go back MANY years now: A) RFC-1704 On Internet Authentication http://www.rfc-editor.org/rfc/rfc1704.txt 1) Category: Informational (top left corner) 2) Status of this Memo says in entirety: This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. B) RFC-1626 IP MTU for use over ATM AAL5 http://www.rfc-editor.org/rfc/rfc1626.txt 1) Category: Standards Track (top left corner) 2) Status of this Memo says in entirety: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 3) As I understand things, and on this I might be a bit out-dated as to the current state of things, there is a concrete proposal to also add to each RFC (starting in the near future and continuing forward) the specific Document Stream (i.e. IETF, IRTF, IAB, Independent Submission) via which a particular RFC was published. I have no objection to that addition. I don't think that it is really necessary, given (1) and (2) above, but it seems to make some folks more comfortable and I don't immediately see any harm in that addition. ANALYSIS: Noel's recent note pointing to Donald Eastlake's note is an accurate summary of the situation. We have substantial actual operational experience indicating that IESG notes are handled appropriately by the RFC Editor team. There is zero evidence of a problem. So there is no reasonable cause to make IESG notes on non-IETF-track documents mandatory. Separately, The IESG lacks authority over the overall RFC publication process -- our process documents say that the RFC-Editor reports to the IAB, not the IESG. This was done *precisely* because it has always been true that many RFCs are not produced via the IETF processes. The RFC process dates back to 1969 -- 40 years ago. The IETF wasn't itself formed until the middle 1980s. Lastly, the RFC Editor and IAB have responsibilities to the entire Internet community, whilst the IESG has more narrow responsibilities for IETF Standards activities. The IETF Community is a proper subset of the larger Internet Community. A number of folks aren't active in IETF work, but are active in IRTF work or are otherwise important parts of the broader Internet Community. For this reason, even if there were IETF consensus of a problem (and frankly, there seems to be smooth consensus amongst non-IESG members that there is NOT a problem), that would be the wrong yard-stick to use for changing processes applicable to non-IETF-track documents. Again, this is why RFC publication is an IAB responsibility instead of an IESG responsibility, and why our process documents say that the RFC Editor reports to the IAB. BOTTOM LINE: There seems to be clear consensus amongst folks outside the IESG that (1) there is no current problem and (2) no process change is warranted to make IESG notes mandatory on non-IETF-track documents. REQUEST: I would urge the IESG to formally abandon the advocacy to change this aspect of our processes, and to say that this has been abandoned on the IETF discussion list. Yours, Ran Atkinson r...@extremenetworks.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel Chiappa wrote: From: Stephan Wenger st...@stewe.org For the IETF as an organization, I see no value beyond traditions in staying with the RFC publication model. (The marketing value of using the RFC series is IMHO contradicted by the lack of control of the IETF over the RFC series). If I understand you correctly, you're suggesting creating a new document series for use by the IETF, for its standards documents? If so, I don't recall this possibility being discussed before, although I can't believe it hasn't been suggested at some point. Well, there's STDs. Do you also want PSTD and DSTD numbers? Such a change would be acceptable to me - although it might take a while to build up the distribution system that already exists for RFCs. Using STD/DSTD/PSTD would just be additional numbers. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqqbLsACgkQE5f5cImnZrv5WwCg58JSLLQTkOPBJWZzkNx8HyDJ ahkAn2O/m6u2U6jUTxybaR1myDUEwscm =2c62 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Sullivan wrote: On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote: First, you lack empirical data to substantiate your assessment of the perception. Well, Wikipedia (which IMO is primarily useful as a repository for finding out what everyone knows) has this first sentence in its description of the RFC series: It's certainly *not* what everybody knows; it's more like what everybody's being told. If you don't like a Wikipedia definition, change it. ;-) Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqqbTMACgkQE5f5cImnZruATgCePexWhxGHNJR2ygAU1iig4Smk EaQAn110fNjgej7dQhiF+XKxXvmOY7w0 =4tjN -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Olaf, Let me suggest tuning this a bit, with the understanding that what I'm about to suggest lies well within current procedures, RFC 5620, etc. --On Wednesday, September 09, 2009 09:11 +0200 Olaf Kolkman o...@nlnetlabs.nl wrote: ... But there is a nugget in the introduction of a last call: I think that the ISE has a very hard time explaining to the RSE that a note that has backing of IESG consensus will not be published. (I am assuming the use of the appeal procedure as described in RFC5620, which I think is appropriate for a difference of opinion between RFC entities such as the ISE and the IESG). If in such conflict the RSE would choose sides of the ISE then I am pretty sure something is severely broken and the appearance of a note is the least of our problems. I would not assume that unless you assume that there is some part of the model that somehow prevents the IESG from getting out of control. If there is not, then, to be orderly, one has to assume that it is fully as possible that the IESG (as the IETF stream-approver) is out of control as it is that the ISE (as the Independent Submission stream approver) is out of control. I also imagine that the IESG could, if so inclined, issue a Last Call that would be so stated as to produce a confirming result, especially if comments from those who do not believe that there should be an Independent Stream were counted along with those who actually understood the particular issues and confirmed the importance of the note. Also remember that the IESG does the counting and, to refer back to an earlier comment on the list, figures out what the consensus is even when it is not obvious. The particular case I would be most concerned about would involve a document that was highly critical of an IETF Standard, but that was extremely clear that it was a critique, that documented the disagreement in a balanced way, etc. -- in other words, where there was a dissent from an IETF standards-track document and no possibility of confusion with one. I could easily imagine the IESG disagreeing with such a document and wanting to get the last word in with a don't pay any attention to this note. If they are permitted to do that, with or without a claim of IETF consensus, then there is no Independent Stream, only an independent as long as documents are reasonably supportive of IETF views and political correctness one. Were that situation to arise, I would expect the RSE to do a balanced evaluation and the IAB, if it got involved, to do so too, with both paying a lot of attention to the differences among note needed to ensure clarity about what the document is, note to warn against a diagnosed danger to the Internet posed by the suggestions in the document, and IESG wants to get the last word in. And, again, my personal view is that the first two represent flaws in the document that ought to get resolved, without add-on text, before the ISE agrees to publish and that the third is not acceptable. Put differently, I think we have a problem any time the ISE (or other stream entity) chooses to ignore, or reject without good reason, input about changes to a document to make its status, or issues with its suggested technology, clear. So in other words what I am saying is don't invent process but follow existing pieces: - put a note in front of the ISE o if the ISE pushes back - last call the note in the IETF, to make sure the IESG actually represents IETF consensus --whereby the consensus is called by the IESG following normal process and appeal--, and go back to the ISE telling that the note has IETF backing. o if the ISE pushes back - consider this a disagreement between stream entities and follow RFC 5620 appeal process. I think whether or not to do that Last Call should be up to the IESG. Nothing prevents them from invoking the disagreement between stream entities procedures on their own remit, although their position would certainly be stronger with clear IETF backing. o if the RSE chooses sides with the ISE the note gets published but the IAB, the IESG, and the RSE have some serious talking to do because something is severely broken elsewhere than just the note. The RFC will most probably be published without the note but the IESG has the possibility to publish a This RFC sucks for this reason RFC while the real problems are being addressed And we should operate on the guideline that, if the IESG simply wants to dissent from a particular document, the mechanism is publication of such an RFC, not attachment of notes. But, again, I believe that any situation in which a note is perceived to be needed is a failure in the publication model _and_, if we think notes are an appropriate way to resolve problems, that any of the other streams should be able to ask the ISE to attach notes of their choosing to IETF Stream documents, doing so as soon as the Document Action or Protocol Action appears. Obviously publication of the document
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi Robert, On 9/9/09 8:54 AM, Robert Elz k...@munnari.oz.au wrote: Date:Wed, 09 Sep 2009 07:17:50 -0400 From:Sam Hartman hartmans-i...@mit.edu Message-ID: tsl7hw89xk1@mit.edu | Right; I think I made it fairly clear in my reply to John Klensin that | I disagreed fairly strongly with that and argued why I believed that | the IETF needs a special role to attach a note to something. No | discussion prior or since has changed my mind. Ask yourself if you'd have the same opinion if the IETF was publishing its output in IEEE Transactions on Networking (or any similar publication), or even something like the NY Times. IMHO, the RFC series (as comprised by the four document streams) is not similar to IEEE Transactions on Networking or the NY Times. I am not sure that there is really a close analog out there. Would you still expect the IESG to be able to tell the editor of that publication what they are required to do? Then note that this is exactly the same ralationship that the RFC editor should have with the IETF. The better question is, if IEEE was distributing the output of the IETF in its series of standards publications and the IETF work was in conflict with their own standards, would it be appropriate to publish without a note from the IEEE explaining the incongruity? And are we really helping anyone by not clarifying the relationship between the document and other RFCs? Shouldn't we provide this information as a service to the reader? Tim In any case, if the editor is failing to perform adequately, the correct response is to replace the editor - there is no rational consittuency here in which to seek consensus (no matter who does the seeking) and no-one rational to handle appeals, so I'm not in favour of John K's compromise proposal. Simply allow the editor the discretion to make his/her own decisions (in this case, it will become the ISE with co-ordination from the RFC editor) and then if they're failing (which mostly means, not getting things published, but might also mean sub-standad publications), then replace them with someone who can do better. Nothing more than that is needed. kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 9/9/09 11:09 AM, Robert Elz k...@munnari.oz.au wrote: Date:Wed, 9 Sep 2009 09:53:42 -0400 From:Polk, William T. william.p...@nist.gov Message-ID: c6cd2ba6.1483b%tim.p...@nist.gov | IMHO, the RFC series (as comprised by the four document streams) is not | similar to IEEE Transactions on Networking or the NY Times. I am not sure | that there is really a close analog out there. It is an independent publisher publishing material submitted to it - the NY Times analogy isn't close, as they create much of their own material, which neither IEEE Transactions, nor the RFC editor do (or not much of, indexes and stuff like that excepted), but aside from that, there shouldn't be a lot of difference. Yes, but everything that IEEE Transactions produces is similar in nature. It is all personal submissions. My point is that the RFC series is shared by different communities with different submission policies. I don't think the analogy fits. There is a completely different balancing act required. | The better question is, if IEEE was distributing the output of the IETF in | its series of standards publications You're operating under the mistaken impression that the RFC series is IETF standards - it isn't - some of he RFCs are IETF standards, others are other IETF publications, and others have nothing to do with the IETF at all. It is just a document series that the IETF happens to use as a place to publish its output. If there was a document series and publisher that was exclusively for IETF standards, then we wouldn't be publishing anything else there at all, and the question of notes would be irrelevant - that would be closer to the way IEEE and ISO standards are published - but that is not what the RFC series is now, or ever has been. I am not suggesting that the RFC series is IETF standards only, or should be. The streams coexist because they all provide services to the same community. | And are we really helping anyone by not clarifying the relationship between | the document and other RFCs? Shouldn't we provide this information as a | service to the reader? Many times that is reasonable, probably, and no-one is suggesting that the RFC editor always refuse to publish IESG notes (though some of us don't believe the IESG should very often, if at all, request one) - the question isn't what happens when an IESG note is appropriate, the question is what happens when it isn't - and who gets to decide. I believe that when a requested IESG note is not appropriate, the RFC Editor will push back and the IETF community will support that position. If the IESG is appropriate, but the RFC Editor pushes back, I believe the community will make the right decision there. Essentially, I trust that the IETF community will ensure that the IESG does not abuse their position. The energy on this thread would seem to support my expectations... Tim kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 2009-09-10 03:53, Noel Chiappa wrote: From: Donald Eastlake d3e...@gmail.com The burden of proof rests on those ... who wish to change the independent stream from a respected independent publishing channel to something subservient to the Area Directors, a change which seems entirely gratuitous without any historically demonstrated need. A most concise and incisive summary of the situation. And hereby hangs a problem. The person who is charged with judging consensus on this conversation is an Area Director. I fear that he has a dilemma: if he reaches the conclusion that the consensus is to change the historical practice (that the IESG merely requests notes to be included in independent submissions), that conclusion would immediately be suspect, and I'd guess would be appealed in very short order. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote: Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. Sam, the underlying point of my question is that the streams are independent and that the IETF (stream) has no say about the other streams. IETF consensus or not. I am not even sure the IAB has a roll in calling the consensus. But there is a nugget in the introduction of a last call: I think that the ISE has a very hard time explaining to the RSE that a note that has backing of IESG consensus will not be published. (I am assuming the use of the appeal procedure as described in RFC5620, which I think is appropriate for a difference of opinion between RFC entities such as the ISE and the IESG). If in such conflict the RSE would choose sides of the ISE then I am pretty sure something is severely broken and the appearance of a note is the least of our problems. So in other words what I am saying is don't invent process but follow existing pieces: - put a note in front of the ISE o if the ISE pushes back - last call the note in the IETF, to make sure the IESG actually represents IETF consensus --whereby the consensus is called by the IESG following normal process and appeal--, and go back to the ISE telling that the note has IETF backing. o if the ISE pushes back - consider this a disagreement between stream entities and follow RFC 5620 appeal process. o if the RSE chooses sides with the ISE the note gets published but the IAB, the IESG, and the RSE have some serious talking to do because something is severely broken elsewhere than just the note. The RFC will most probably be published without the note but the IESG has the possibility to publish a This RFC sucks for this reason RFC while the real problems are being addressed Obviously publication of the document should be delayed on request from the IESG while the above is sorted out in a timely manner. -- Olaf 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Olaf == Olaf Kolkman o...@nlnetlabs.nl writes: Olaf On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote: Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. Olaf Sam, Olaf the underlying point of my question is that the streams are Olaf independent and that the IETF (stream) has no say about the Olaf other streams. IETF consensus or not. Right; I think I made it fairly clear in my reply to John Klensin that I disagreed fairly strongly with that and argued why I believed that the IETF needs a special role to attach a note to something. No discussion prior or since has changed my mind. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Date:Wed, 09 Sep 2009 07:17:50 -0400 From:Sam Hartman hartmans-i...@mit.edu Message-ID: tsl7hw89xk1@mit.edu | Right; I think I made it fairly clear in my reply to John Klensin that | I disagreed fairly strongly with that and argued why I believed that | the IETF needs a special role to attach a note to something. No | discussion prior or since has changed my mind. Ask yourself if you'd have the same opinion if the IETF was publishing its output in IEEE Transactions on Networking (or any similar publication), or even something like the NY Times. Would you still expect the IESG to be able to tell the editor of that publication what they are required to do? Then note that this is exactly the same ralationship that the RFC editor should have with the IETF. In any case, if the editor is failing to perform adequately, the correct response is to replace the editor - there is no rational consittuency here in which to seek consensus (no matter who does the seeking) and no-one rational to handle appeals, so I'm not in favour of John K's compromise proposal. Simply allow the editor the discretion to make his/her own decisions (in this case, it will become the ISE with co-ordination from the RFC editor) and then if they're failing (which mostly means, not getting things published, but might also mean sub-standad publications), then replace them with someone who can do better. Nothing more than that is needed. kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Robert == Robert Elz k...@munnari.oz.au writes: Robert Then note that this is exactly the same ralationship that Robert the RFC editor should have with the IETF. I disagree for reasons I have previously stated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Sam, The burden of proof rests on those like you who wish to change the independent stream from a respected independent publishing channel to something subservient to the Area Directors, a change which seems entirely gratuitous without any historically demonstrated need. Donald On Wed, Sep 9, 2009 at 9:22 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Robert == Robert Elz k...@munnari.oz.au writes: Robert Then note that this is exactly the same ralationship that Robert the RFC editor should have with the IETF. I disagree for reasons I have previously stated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Date:Wed, 9 Sep 2009 09:53:42 -0400 From:Polk, William T. william.p...@nist.gov Message-ID: c6cd2ba6.1483b%tim.p...@nist.gov | IMHO, the RFC series (as comprised by the four document streams) is not | similar to IEEE Transactions on Networking or the NY Times. I am not sure | that there is really a close analog out there. It is an independent publisher publishing material submitted to it - the NY Times analogy isn't close, as they create much of their own material, which neither IEEE Transactions, nor the RFC editor do (or not much of, indexes and stuff like that excepted), but aside from that, there shouldn't be a lot of difference. | The better question is, if IEEE was distributing the output of the IETF in | its series of standards publications You're operating under the mistaken impression that the RFC series is IETF standards - it isn't - some of he RFCs are IETF standards, others are other IETF publications, and others have nothing to do with the IETF at all. It is just a document series that the IETF happens to use as a place to publish its output. If there was a document series and publisher that was exclusively for IETF standards, then we wouldn't be publishing anything else there at all, and the question of notes would be irrelevant - that would be closer to the way IEEE and ISO standards are published - but that is not what the RFC series is now, or ever has been. | And are we really helping anyone by not clarifying the relationship between | the document and other RFCs? Shouldn't we provide this information as a | service to the reader? Many times that is reasonable, probably, and no-one is suggesting that the RFC editor always refuse to publish IESG notes (though some of us don't believe the IESG should very often, if at all, request one) - the question isn't what happens when an IESG note is appropriate, the question is what happens when it isn't - and who gets to decide. kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Robert Elz wrote: | The better question is, if IEEE was distributing the output of the IETF in | its series of standards publications You're operating under the mistaken impression that the RFC series is IETF standards - it isn't - some of he RFCs are IETF standards, others are other IETF publications, and others have nothing to do with the IETF at all. It is just a document series that the IETF happens to use as a place to publish its output. This is the core point. Some folk want to re-cast the RFC series as structly subservient to the IETF. But that's not how it has operated for 40 years. Yes, folks, 4 decades. There is a fundamental difference between having a strong relationship versus being subservient. In order to make such a basic change, there needs to be a compelling statement of need for which there is strong community consensus. None has yet been offered, except the same one that gets repeated every few years, for at least 20 years, namely that some folk don't understand the RFC series. Sigh. Yes, folks, this thread is the same as has been repeated many, many times, including the consistent lack of demonstrated damage from the current arrangement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: Donald Eastlake d3e...@gmail.com The burden of proof rests on those ... who wish to change the independent stream from a respected independent publishing channel to something subservient to the Area Directors, a change which seems entirely gratuitous without any historically demonstrated need. A most concise and incisive summary of the situation. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi, As it has been pointed out here often, the RFC series is more than just the document numbering scheme for IETF standards. However, if you attend a marketing gathering, a random CS conference, a non-IETF standardization meeting, or even the IETF plenary, a majority of people (probably a large majority) would answer the question what are RFCs with standards set by the IETF, or something thereabouts. This *perception* is important. And changing it means changing the *perception* of a large number of people, for very little value except honoring a 40 year old institution. That's not a value proposition I can easily support. If the IETF is *perceived* as the owner and/or sole contributor to the IETF series, it should have influence up to veto power regarding the content of that series, through its chosen management structure---that is, AFAIK and in this case, the IESG. Otherwise, it cannot stop the publication of documents against its interest. It's pretty clear now that the IESG is not going to get the tools I consider required to influence the RFC editor, due to historical facts and the independence of the RFC editor and its support functions. Is it time that the IETF considers publishing its material elsewhere? Regards, Stephan On 9/9/09 8:32 AM, Dave CROCKER d...@dcrocker.net wrote: Robert Elz wrote: | The better question is, if IEEE was distributing the output of the IETF in | its series of standards publications You're operating under the mistaken impression that the RFC series is IETF standards - it isn't - some of he RFCs are IETF standards, others are other IETF publications, and others have nothing to do with the IETF at all. It is just a document series that the IETF happens to use as a place to publish its output. This is the core point. Some folk want to re-cast the RFC series as structly subservient to the IETF. But that's not how it has operated for 40 years. Yes, folks, 4 decades. There is a fundamental difference between having a strong relationship versus being subservient. In order to make such a basic change, there needs to be a compelling statement of need for which there is strong community consensus. None has yet been offered, except the same one that gets repeated every few years, for at least 20 years, namely that some folk don't understand the RFC series. Sigh. Yes, folks, this thread is the same as has been repeated many, many times, including the consistent lack of demonstrated damage from the current arrangement. d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Stephan Wenger wrote: This *perception* is important. And changing it means changing the *perception* of a large number of people, for very little value except honoring a 40 year old institution. That's not a value proposition I can easily support. If the IETF is *perceived* as the owner and/or sole contributor to the IETF series, Stephen, First, you lack empirical data to substantiate your assessment of the perception. Second, you lack empirical data that it is causing a pragmatic problem. That is what ought to be the lesson of having repeated this thread every few years for 20 years ought to be. Make a change when you have a demonstrable, real and damaging problem, not just something you don't like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote: First, you lack empirical data to substantiate your assessment of the perception. Well, Wikipedia (which IMO is primarily useful as a repository for finding out what everyone knows) has this first sentence in its description of the RFC series: In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems. The fourth link from Google in response to, What is an RFC? says RFC is an acronym for Request for Comments and official documents from the Internet Engineering Task Force (IETF) with an unlimited distribution. RFC's are numbered in a series and are referred to by numbers. So even if those pages go on to refine their statements, I don't think it preposterous to suggest that people think the RFC series is from the IETF. I am totally unwilling to have an opinion on whether anyone ought to try to do anything about this, but I don't think we should pretend that the world is otherwise than it is. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi Dave, I agree with your second observation. It may well be that the current RFC editor model has not *yet* caused a pragmatic problem. I stand to my first assessment, as originally formulated. The main issue is: should the IETF be pro-active on these matters, or not. For the IETF as an organization, I see no value beyond traditions in staying with the RFC publication model. (The marketing value of using the RFC series is IMHO contradicted by the lack of control of the IETF over the RFC series). If there were indeed no value beyond traditions, why run any risk, no matter how small? Certainly there must be some risk in giving the RFC editor, rather than the duly appointed IETF officials, the last say in publishing documents that are perceived as IETF documents. I could follow an argument that changing the publication mechanism is large enough a pain to best avoid it, for the small pragmatic gains we may get. Regards, Stephan On 9/9/09 9:19 AM, Dave CROCKER d...@dcrocker.net wrote: Stephan Wenger wrote: This *perception* is important. And changing it means changing the *perception* of a large number of people, for very little value except honoring a 40 year old institution. That's not a value proposition I can easily support. If the IETF is *perceived* as the owner and/or sole contributor to the IETF series, Stephen, First, you lack empirical data to substantiate your assessment of the perception. Second, you lack empirical data that it is causing a pragmatic problem. That is what ought to be the lesson of having repeated this thread every few years for 20 years ought to be. Make a change when you have a demonstrable, real and damaging problem, not just something you don't like. d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: Stephan Wenger st...@stewe.org For the IETF as an organization, I see no value beyond traditions in staying with the RFC publication model. (The marketing value of using the RFC series is IMHO contradicted by the lack of control of the IETF over the RFC series). If I understand you correctly, you're suggesting creating a new document series for use by the IETF, for its standards documents? If so, I don't recall this possibility being discussed before, although I can't believe it hasn't been suggested at some point. Such a change would be acceptable to me - although it might take a while to build up the distribution system that already exists for RFCs. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Andrew Sullivan wrote: On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote: First, you lack empirical data to substantiate your assessment of the perception. Well, Wikipedia ... The fourth link from Google in response to, What is an RFC? says ... So even if those pages go on to refine their statements, I don't think it preposterous to suggest that people think the RFC series is from the IETF. Andrew (and Stephen), Thank you for exploring the question of empirical data, as well as demonstrating how methodologically challenged discussion in the IETF tends to be, particularly with respect to anything involving or implying statistics... The original comment was about universality of perception. Particular examples were cited at the beginning of Stephen's note, but they morphed into a statement of universality by the end of it. Your own note cited the first and fourth google listings but left out, for example, the second and third. Based on that latter set, I could claim that THE perception is that the RFC series is the working notes of the Internet research and development community and a formal mechanism used to describe communications standards for the Internet and systems (like USENET) that are closely tied to it. That's quite a different characterization of the RFC series and besides being more accurate, it has the same empirical basis being put forth as the perception of the series as what you are citing. But, of course, this is all about the first of two challenges I offered and empirical data for the latter is what justifies considering a change. Stephen just posted the view that we should be proactive, but does not seem to understand that we missed that opportunity 20 years ago. Whatever problem we need to anticipate has failed to materialize for two decades. But the real crux of this debate is represented by the difference between my second challenge and Stephen's alternative challenge: If there were indeed no value beyond traditions, why run any risk, no matter how small? First, it means that we need to be clearer about the intended benefit behind having the Independent stream. (For any activity, it's always a good idea to have an explicit and visible value proposition...) Second, it misses the practical implication of making changes due to imagined risks, particularly since there is always an infinite set of them to choose from. Third, it ignores the operations rule that all change is, itself, risk, and that therefore no change is justified unless there is a solid basis for expecting very, very substantial benefits. (For any activity, it's always a good idea to have an explicit and visible value proposition...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote: for example, the second and third. Based on that latter set, I could claim that THE perception is that the RFC series is I am at the best of times uneasy with universal quantifiers, and certainly when talking about THE belief of THE Internet, I feel pretty uneasy. Also, I haven't followed this discussion much, partly because I fully agree with the observation that most of it has been hashed so much, and warmed over so many times, that it's now turned into a form of American breakfast potato. But it doesn't seem to me to be doing favours to anyone to deny the obvious point that there's at least a substantial community of people who regard the label RFC as bespeaking an IETF document and also Internet standard. Claiming that it's not true by pointing to examples of careful and clueful definitions (one of which is practically a sockpuppet for the IETF pages themselves) does not clarify this matter. Even organizations involved in the administration of the Internet apparently rely on something being an RFC as somehow implying an _imprimatur_ or at least _nihil obstat_ (if anyone wants evidence of that matter, I think the archives of agreements found at ICANN will be instructive). Again, I wish to emphasise that this is completely distinct from the question of whether anyone ought to do anything about the state of affairs. I refuse to take a position on that, or even consider it as a topic for a conversation in which I'll be involved. There are enough windmills around without us throwing up new ones at which we can tilt. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Andrew Sullivan wrote: Again, I wish to emphasise that this is completely distinct from the question of whether anyone ought to do anything about the state of affairs. I refuse to take a position on that, or even consider it as a topic for a conversation in which I'll be involved. There are enough windmills around without us throwing up new ones at which we can tilt. That's a shame. The standards world is looking for someone who can tilt at the windmills that are the entrenched habits of our day. Who wants to be the hero of that novel? I'm being serious. I agree with you that there is much unhelpful confusion about RFCs. /Larry Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 Cell: 707-478-8932 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew Sullivan Sent: Wednesday, September 09, 2009 11:20 AM To: ietf@ietf.org Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote: for example, the second and third. Based on that latter set, I could claim that THE perception is that the RFC series is I am at the best of times uneasy with universal quantifiers, and certainly when talking about THE belief of THE Internet, I feel pretty uneasy. Also, I haven't followed this discussion much, partly because I fully agree with the observation that most of it has been hashed so much, and warmed over so many times, that it's now turned into a form of American breakfast potato. But it doesn't seem to me to be doing favours to anyone to deny the obvious point that there's at least a substantial community of people who regard the label RFC as bespeaking an IETF document and also Internet standard. Claiming that it's not true by pointing to examples of careful and clueful definitions (one of which is practically a sockpuppet for the IETF pages themselves) does not clarify this matter. Even organizations involved in the administration of the Internet apparently rely on something being an RFC as somehow implying an _imprimatur_ or at least _nihil obstat_ (if anyone wants evidence of that matter, I think the archives of agreements found at ICANN will be instructive). Again, I wish to emphasise that this is completely distinct from the question of whether anyone ought to do anything about the state of affairs. I refuse to take a position on that, or even consider it as a topic for a conversation in which I'll be involved. There are enough windmills around without us throwing up new ones at which we can tilt. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote: I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. Which community, The IETF community or the wider RFC community? And who calls the consensus? --Olaf 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Tuesday, September 08, 2009 16:36 +0200 Olaf Kolkman o...@nlnetlabs.nl wrote: On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote: I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. Which community, The IETF community or the wider RFC community? And who calls the consensus? Also, please remember, again, that the IESG _always_ has the right and opportunity to publish a dissent as a separate RFC in the IETF Track. If that dissent is wildly out of line with the wishes of the IETF community, the IETF community presumably has ways to deal with that. Anything sufficiently controversial to justify the procedure above almost certainly justifies that treatment because a separate RFC can document reasoning and context, while any plausible note (and all such notes so far, including the texts specified in 3932) merely provide a statement of conclusions. The main argument I've heard against that approach is that the IESG doesn't have the time. But, if it doesn't, then a full community review as described above, with the inevitable community fine-tuning of text, is certainly going to equally time-consuming. The issue justifying comment is either important or it is not, and allowing the IESG to impose a note by a cryptic comment (whether intentionally so or not) in minutes and/or the tracker doesn't serve either the community nor the separation of streams well. Perhaps we should be discussing supplementing Obsoletes and Updates in RFC headers and the index with Dissents from, Heaps abuse upon, and/or Ridicules to make the intended relationships among document more clear, but... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
In my opinion, 3932bis is internally inconsistent about IESG notes. This document expressly directs the IESG to reserve IESG notes for exceptional cases, but then leaves the decision on whether the note should be included to the RFC Editor: In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG may request that the RFC Editor include an IESG note to clarify the relationship of the document to the IETF standards process, such a note is likely to include pointers to related IETF RFCs. Personally, I think that the relationship is unclear in many cases, but it is all a question of degree. I interpret this text as directing the IESG to reserve such notes for cases where serious conflicts exist and it is particularly important to clarify the relationship and identify the documents that represent community consensus. In such a case, I would not want to see the RFC Editor ignore the request or modify the note without IESG agreement. The current text of 3932bis seems to permit either. I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. Tim Polk On 9/2/09 12:38 PM, Sam Hartman hartmans-i...@mit.edu wrote: I'd also be happy with a mechanism where the IESG could propose a note, and the RFC editor had the option of accepting the note or asking the IESG to last-call its note within the IETF community. I would not consider it acceptable if the note were purely advisory. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Olaf, I meant the IETF community. Since the note would exist to clarify the relationship with documents developed by the IETF community, that seems the right one to evaluate whether a note is needed. As to who calls the consensus, that is a tricky one. How about the IAB chair? Tim On 9/8/09 10:36 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote: I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. Which community, The IETF community or the wider RFC community? And who calls the consensus? --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. I'm not thrilled with the appeals process starting with the IAB and only going to the ISOC BOT in case there is no adequate process (6.5.3 in RFC 2026). However I could live with that. I suspect this may be one of those cases where we know we've gotten a good compromise because no one is happy with it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Polk, William T. wrote: I believe Sam's suggestion offers a good compromise position: if the IESG and RFC Editor do not come to an agreement, we should last call the proposed IESG Note and let the community determine whether (1) this is an exceptional case meriting a note and (2) if the text accurately clarifies the relationship. On its face, this is certainly a reasonable path to follow. However it has three practical problems. One is effort and delay. Adding more layers of decision-making and negotiation imposes non-trivial cost. The more barriers we place in the way of independent submission, the less it will get used. Worse, that's a stated goal for some folk. The second is that it has become nearly impossible to find anything that looks like classic rough consensus on the IETF list. The diversity of understanding, commitment and goals of participants on the IETF list has become far too diverse. So as a mechanism for discerning how to resolve an impasse, it isn't likely to be very helpful. The third is that it creates a negative incentive for the RFC Editor to act as an independent agency. When it presses a point and finds a wall of hassle to deal with, this has a chilling effect on its likelihood of pressing. They come to see such matters of principle as not worth the effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
SM sm at resistor dot net wrote: Some people interpret RFCs as Internet Standards even though the document contains It does not specify an Internet standard of any kind. The document also says Request for Comments, which is not even remotely true -- it represents the end of a long reviewing and commenting and evaluating process, not the beginning -- and it also says Network Working Group, when there are over 100 active WGs but none with that name. The more boilerplate takes over a document, the less readers will be inclined to interpret any of it literally. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: Richard Barnes rbar...@bbn.com What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. This may be true, but it's also basically irrelevant to the point at hand. Even if we stopped using the RFC series for non-standards documents, and started a new series for indepedendent, IRTF, etc documents, (which we might call the CFR series, with the letters reversed - it has a nice un-official expansion, 'Can't xxx Read', in honour of those who would make it necessary) the question of 'what authority, if any, the IESG should have over documents in that document series' remains. Simply not providing a dissemination path for such non-IETF document is not, IMO, an option that's even worth discussing at any length. We need one, and the question will remain over how much, if any, authority the IESG will have over it. (Temporarily reverting to your point about the series name, the problem of the world thinking that 'RFC'=='Standard' has been with us for a long time, and a number of things have been tried to fix it, with varying degrees of success - the STD numbers, Internet-Drafts, etc. I generally don't put a lot of weight on people who aren't up to speed on the details, just like I'm not bothered by the many network users for whom 'the Internet' == 'the Web' - I don't see any value in renaming things there, in line with their muddled and/or simplistic model, either.) it's not clear to me why the independent stream exists at all, other than for historical reasons. As a place for the networking community to publish things in a way which is guaranteed to have universal, easy, ubiquitous and free access - something which publishing in a journal does _not_ accomplish. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, Your suggestion would largely address my concerns related to the timely appeal path. Best regards, Pasi -Original Message- From: ext John C Klensin [mailto:john-i...@jck.com] Sent: 02 September, 2009 20:20 To: Eronen Pasi (Nokia-NRC/Helsinki); j...@joelhalpern.com; b...@estacado.net Cc: i...@ietf.org; ietf@ietf.org Subject: RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes --On Tuesday, September 01, 2009 09:55 +0200 pasi.ero...@nokia.com wrote: Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Pasi, A comment and then a suggested middle position. I've been watching what we now call the Independent Submission Process for far longer than there has been an IETF. I've seen it as an insider for a large fraction of two decades -- as an AD, an IAB member and then chair, as an editorial board member, and now as an IAB member again. During that period, I've never seen an RFC Editor abuse the process by ignoring legitimate input. Bob Braden may be able to provide an inside view --not in his present role of RFC Editor but as the very-long-time IAB Exec Director -- of what happened before 1992, but my educated guess is that instances of RFC Editor ignores input during that time were also about zero. During the same period, I'd seen behavior I consider abusive from ADs or the IESG many times -- attempting to prevent publication of documents with which they had personal/ emotional disagreements that they were unwilling or unable to explain in public, asking for publication holds on documents for multiples of years, insisting that the RFC Editor not move forward until the IESG responds in some way and then not responding for months and months, demanding changes that would significantly weaken the document or change its meaning, and so on. Many of those problems have been resolved by negotiation, but some have not. RFC 3932, and its limitation on technical review, was a huge improvement over its predecessors in that regard, but we've heard multiple ADs over the years claim that they can redefine any disagreement about a document into either a technical issue or a technical one (whichever is needed) if they care enough and especially if they can define the boundary (which they also have insisted that the IESG has the unilateral right to do). In principle, the IAB could appoint a new ISE to take over in January who would adopt a policy of abusiveness. But I think I can speak for the ACEF membership and the IAB if I say that we don't intend to do that... and that the IAB would expect the RSE to move fairly quickly, with the IAB's backing, to correct the attitudes involved if it occurred anyway. So trying to make IESG notes mandatory on documents originating in another stream for the reasons you cite above is solving a problem we've never had at the risk of making a problem worse that we've had several times. That strikes me as bad engineering at best. And insisting that the RFC Editor invoke a formal appeals procedure in case of disagreement with the IESG about an Independent Submission would, as Olaf points out, largely undo the efforts of the last few years to clearly separate the different streams. It would be as sensible to say that IESG notes should be sufficiently exceptional that the IESG would need to consult the IAB and get permission before sending any such note-request to the ISE. I suspect that such a provision would not make either the IESG or the IAB very happy. However, if your concern is really to make sure that there is a timely appeal path, I have a suggestion that might be acceptable to everyone without causing unfortunate side-effects. We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Sep 2, 2009, at 7:20 PM, John C Klensin wrote: We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a reasonable period of time for the IESG to respond. If it felt it were necessary, the IESG could then open a further discussion, ask the RSE to mediate, or launch a formal request for IAB review. Consistent with other provisions in RFC 4846, either the IESG or the ISE could, at their discretion, make the correspondence (the request and response) public. I think it is more than reasonable to expect documented communication if a request from the IESG is not honored by the ISE. I also think it is reasonable to expect such decision to be appealable/reviewable and that all the communication is timely. So yes, I support this, in fact I take this for granted. I believe that difference of technical opinion follows RFC 4846 sect 5 (which is about publishing or not publishing). The denial of a note from the IESG is a dispute between streams that follows RFC 5620 4.2.1. I can see that there could be some argument about which procedure to follow but in the end the RFC Editor (the RSE in this case) will make the final decisions based on various recommendations (that is how both 4846 and 5820 are written). --Olaf (no hats) --Olaf 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, we've had repeated examples over the years of the IESG and/or individual ADs abusing the independent submission process and/or the RFC Editor and zero examples of the RFC Editor handling a request from the IESG unreasonably or arbitrarily. I don't want to open a discussion about who is more evil, particularly when opinions about any particular case probably differ. All I want to say about that is that as long as I have been looking, the score has been zero and zero on both sides. In particular, when I have been an AD it has always been a pleasure to work with the RFC Editor, and they have always made exactly the right decisions. In my honest opinion of course. But I did want to bring up a couple of other angles. First of all, all the streams get their share of garbage. And sometimes the right decision is to publish the document despite it having some faults, or at least differences of opinion to established IETF practice. However, in such cases the notes that we are talking about really can be necessary (e.g., when a document redefines RADIUS Access-Reject as Access-Accept, to cite one real example from a few years back). The second point was that in general, human organizations are prone to occasional failures. I at least prefer designs that are inherently capable of dealing with such failures (e.g., appeals path, way to fix a bad decision). However, I still want to see the RFC Editor as a simple journal-like function; please don't take my comment as an indication that board members should be selected by Nomcom, publication decisions should have public last calls or anything like that. We already have the IETF which runs in a community driven manner. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi Richard, At 20:31 02-09-2009, Richard Barnes wrote: Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Some people interpret RFCs as Internet Standards even though the document contains It does not specify an Internet standard of any kind. on the first page. One of the differences between the IETF Stream and the Independent Stream is that the former is reviewed by the IETF Community. The IETF Community is small part of the Internet community. This discussion is about a specific type of IESG Note where the IESG is supposed to only check for conflicts between the work of the IETF and the documents submitted. That sounds fairly simple. This discussion highlights there may be divergent views even for simple questions. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. The Independent Stream offers you a path to publish your document if the IESG does not find it suitable for publication. If you are using that path to bypass an IETF Working Group, the IESG Note under discussion comes into play. Some people find the IETF path too expensive as it seems that you have to be an insider to get your document published. The important point here is that you are offering a workable alternative to people to publish their work even though the IETF does not agree with the contents of the document, i.e. diverse views are not suppressed. It's more than a check and balance. Having this stream also allows the IETF to assess the effectiveness of its processes and document quality. In other words, if it is faster to publish through the Independent Stream and the output of that stream is better, the IETF can find out whether there is a problem with its stream. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The second point is not represented in the current process by the IESG Note under discussion. That note does not mean that the Internet community has concerns. It means that it is the opinion of the IESG that the document fulfills one of the five conditions in Section 3. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. The ISE is not speaking on behalf of the IETF Community. I don't know whether you would agree to me as to whether the RFC Editor has been able to ensure the consistency of the RFC Series over the years. I encourage you to read some of the notes from Bob Braden and the RFC Editor team about the RFC Editor. Some of them may be historical in nature but they also spell out a constant line of thinking. The decisions taken are not done lightly and they are still relevant after all these years. Consistency also means that it is highly unlikely the RFC Editor will drop an IESG Note based on a whim. At 14:23 02-09-2009, Russ Housley wrote: Please, let's try to answer this one question on this thread: When the IESG performs review of an Independent stream or IRTF stream document and provides an IESG Note, does the RFC Editor have the authority (without a request for reconsideration or an appeal) to publish the document without the IESG Note? It would be better to define the problem. As I see it, the problem is that the RFC Editor might drop the IESG Note and publish the document as a RFC. Once that is done, there is no way to revert back. With the forthcoming changes to the RFC Editor, the IETF Community and/or the IESG are facing an unknown. I suggest following John's proposal. A formal notification from the ISE and delay in the publication
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Thursday, September 03, 2009 11:55 +0300 Jari Arkko jari.ar...@piuha.net wrote: ... In particular, when I have been an AD it has always been a pleasure to work with the RFC Editor, and they have always made exactly the right decisions. In my honest opinion of course. And I'd rather count on that and think about ways to deal with any patterns of deviation if they should occur than start devising ways for one stream to tell another one what it must do. But I did want to bring up a couple of other angles. First of all, all the streams get their share of garbage. And sometimes the right decision is to publish the document despite it having some faults, or at least differences of opinion to established IETF practice. However, in such cases the notes that we are talking about really can be necessary (e.g., when a document redefines RADIUS Access-Reject as Access-Accept, to cite one real example from a few years back). And that is perhaps exactly an example for the other side. First, it is at the very margin between the procedural review for conflicts with ongoing IETF work that both 3932 and 4846 call for and the technical review that both documents more or less indicate should be handled on an individual review basis. I suggest that it is not so much a conflict with the ongoing work of an IETF WG, but a flat technical error. The right solution for such errors is to fix them, or at least ask the authors to include a detailed discussion of why the terminology needs to be different, not a note... especially, IMO, one that, per the current interpretations of the current RFC 3932, is closer to nah, nah, we don't like this than a useful explanation that identifies the specific problem. I believe that, if an ISE were to ignore reviews/input on a subject like that, or fail to push the authors very hard after getting it, we would have a very serious problem on our hands... whether that review came from the IESG, from a single AD, from within some relevant WG, or from a moderately random IETF participant or onlooker. So I don't see that notes are the right solution to that problem. At worst, they become a crutch that reduces the ISE's belief that it is the responsibility of the authors and the RFC Editor function to actually get these documents right. The second point was that in general, human organizations are prone to occasional failures. I at least prefer designs that are inherently capable of dealing with such failures (e.g., appeals path, way to fix a bad decision). We agree about that, which is one of the reasons why institutionalizing the current practice of telling the IESG why comments are being rejected (if that happens) strikes me as a good idea. But, to paraphrase (I think) Joel, I'll prefer to see things work in a way that gets documents improved rather than ones that drop cross-stream notes into them (mandatory or not). And that is especially so after many decades of experience in watching people's eyes glaze over as they notice what appears to be boilerplate and skip it... getting the text right, or getting it to clearly note that there are dissenting views and why, is just a much better way to get the point across than note-inserting. However, I still want to see the RFC Editor as a simple journal-like function; please don't take my comment as an indication that board members should be selected by Nomcom, publication decisions should have public last calls or anything like that. We already have the IETF which runs in a community driven manner. Good. And thanks. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, I suggest that it is not so much a conflict with the ongoing work of an IETF WG, but a flat technical error. And I would in general agree with you, but in this case the stuff was already deployed very widely, and the purpose of the publication was to document existing practice. I agreed that the draft had to be published as it was. Of course, a clean design would have been different, but what do you do? Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: pasi.ero...@nokia.com Your suggestion would largely address my concerns related to the timely appeal path. I agree - this proposal: if the ISE receives input from the IESG requesting specific changes to a document ... and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a reasonable period of time for the IESG to respond. If it felt it were necessary, the IESG could then open a further discussion, ask the RSE to mediate, or launch a formal request for IAB review. is in line with the open 'checks and balances' I like to see, while not adding additional process to almost all of what the RFC Editor does. From: Jari Arkko jari.ar...@piuha.net I still want to see the RFC Editor as a simple journal-like function Exactly. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Richard Barnes wrote: What is clearly going on here is that our branding is out of sync with the expectations of our customers. One of the historical items of note is that this supposed problem has been present for about 20 years. In other words, nothing has changed. For example, it prompted RFC 1796, Not All RFCs are Standards almost 15 years ago. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. To whatever extent it is true now, it's been true for decades and it hasn't caused any real-world problems that have been documented. Let me repeat: we have no documentation that, to whatever extent there is confusion amongst RFC readers about the status of different RFCs, it causes meaningful problems. Moreover, the core implication of your assessment is that we should shut down the Independent Stream entirely. And indeed, you indicate that that would be your preference. However, please note that you are creating a new distinction in this area of discussion: reviewed and approved by the Internet community versus IETF Standard. Again, there is no evidence that the broader community understands the subtlety of that distinction, so perhaps we should really require that all RFCs be standards? I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. That's your real question. And absent an understanding of its reason for being, how is it possible to state a preference for how it should be handled? On the other hand, your clear statement that you believe the stream should not exist substantiates the concern that allowing the IESG to mandate content of an Independent document effectively brings that stream under the control of the IESG. So Independent won't be. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are The IESG is not The Internet Community. It is a tiny group of folk, with the usual array of expertise and biases. Why should it be allowed to mandate the content of documents that it has no involvement in and that are intended to be independent of IESG control. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, Really? This presumes that folk would know to expect an IESG Note. Given the other things we know they don't know about the RFC series, they aren't likely to know about this possibility. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Thursday, September 03, 2009 12:48 +0300 Jari Arkko jari.ar...@piuha.net wrote: John, I suggest that it is not so much a conflict with the ongoing work of an IETF WG, but a flat technical error. And I would in general agree with you, but in this case the stuff was already deployed very widely, and the purpose of the publication was to document existing practice. I agreed that the draft had to be published as it was. Of course, a clean design would have been different, but what do you do? It is hard to argue against an accurate description of deployed existing practice, even if it is conflicting or otherwise terrible. I think that the process should have caught the terminology discrepancy and that the authors should have been required to describe it, and the problems it could cause, very carefully. Again, I think we are fairly closely aligned about the principle here. I just think that notes -- especially non-specific ones that are, or appear to be, boilerplate-- are rarely a desirable solution and that authors should be forced into careful description of issues and/or critical reviews of differences as a better alternative. The job of doing the forcing is that of the RFC Editor/ ISE, not the IESG, but I'd be very concerned about any ISE who didn't take the responsibility for ensuring that documents are not confusing wrt IETF (and other identifiable) work were not clarified to the point that a reader would have no trouble telling from context was was going on. It may amuse you to know that I've been pushing the theme that independent submissions that even vaguely overlap with IETF work should both show an awareness of that situation and include critical reviews of the differences for many years, enough years to have repeatedly made the comment to the previous RFC Editor as well as the current one (and probably persistently enough to occasionally irritate both). I've also suggested from time to time that, if someone can read an independent submission (non-April-1) RFC that overlaps with IETF work with reasonable care and not emerge with a clear understanding of the relationship, the RFC Editor has not done their job. I'm sort of an extremist on the topic, even though the pragmatics of getting useful documents posted have often caused me to not get exactly what I've asked for. But, again, I see the primary responsibility for making sure that Independent submission documents are clear about what they are lies with the authors and RFC Editor(ISE), that the considerable improvements in Headers and Boilerplates will play a major role in helping with that, and that qualifying notes, regardless of source, are a very poor choice, to be used cautiously, selectively, with careful relationship to context, and only if the issues cannot be resolved in any other way. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Mon, Aug 31, 2009 at 2:29 PM, Adam Roacha...@nostrum.com wrote: Joel M. Halpern wrote: ... Remember also that in terms of the text being a recommendation, this is not a change in practice. This is the practice we have had for more than the last 15 years. If, for Independent Submissions, it is that big a problem, I would expect ot have heard of it. Perhaps I'm just unclear on the frequency of independent submissions -- but can you find me an RFC that came from a source other than the IETF that does not include a prominent note indicating that fact? I believe that the Independent Stream should continue to exist and that IESG notes should be recommendations, rather than mandatory. Here are some of RFCs of which I was an author that were Independent Stream submissions, with notes: RFC1898 CyberCash Credit Card Protocol Version 0.8 This RFC documents a propriety protocol, making the protocol public. The document internally makes it pretty clear that it came from CyberCash, Inc., but I wouldn't say there is a prominent note to that effect. It contains statements that could easily be categorized as marketing. One effect of publishing this RFC was to preclude later patent claims for the ideas it contained. RFC2706 ECML v1: Field Names for E-Commerce This one has an IESG note commenting on its source and noting technical deficiencies in internationalization. I'm not sure what the policy was at the time but the IESG was, in effect, doing technical reviews of such submissions. As an author, I had no objection to the IESG note as I basically agreed with it. It was obsoleted by: RFC 3106 ECML v1.1: Field Specifications for E-Commerce I believe this was also an independent submission. It's IESG note points out the non-IETF source for these documents and that this work was moving into the IETF where an IETF working group was working on a v2. This v2 was later published as RFC 4112 as a Proposed Standard. Thus, in this case, the independent stream provided a convenient means to provide some continuity in the publication of work which was transitioning into the IETF. RFC 4144 How to Gain Prominence and Influence in Standards Organizations I submitted this to the IESG, it was assigned to the IETF Chair who, after reviewing, decided that it was inappropriate for anything but the Independent Submission stream. See: https://datatracker.ietf.org/idtracker/draft-eastlake-prominence/comment/28295/ Hopefully the above examples give some idea of the range of items published in the Independent Stream. Thanks, Donald I'm under the distinct impression that historical practice tagged all (or almost all) such documents with a prominent note. The proposed procedure tries to make this an extreme exception, not the norm. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi John - I'm convinced we (the internet community) still need an true independent submissions path. I'm no longer convinced that the path should or can lead through the RFC editor. In the far past, the RFC Editor was a true independent entity - part of the internet community, participating and part of the IAB, but with its own funding source and a mandate to do the right thing. The RFC Editor was a both a technical and stylistic reviewer and final arbiter of what got published - but that wasn't a very heavy burden for the community. Over the years that independence has waned - with the cessation of independent funding, with Jon Postel's death, with the termination of the IETF's CNRI relationship, and most recently with the competition of the RFC Editor function. Control has been centralized and the RFC Editor's editorial independence has all but been eliminated. At this point, it appears to be about who gets to decide. And that goes back to the golden rule. It's too easy for those who control the funding to control the publication, especially since the RFC editor function has mostly been reduced to stylistics without the ability (either contractually or technically) to act as a fair and independent decider. I may be overstating the case, but I can't see how it could be any different given what I've read in the solicitations. I can't see any way to provide an objective set of publication rules that can be implemented by rote by the editor. Which right now throws the subjective decisions over to the IESG which can have a conflict of interest with respect to certain submissions - hence the whole set of discussions about notes. I fear the problem is intractable without reference to an editorial/publication decision function that is completely independent of the IESG. Mike ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
All, I value the independence of the Independent Submission stream and IRTF Stream from the IETF (including the IESG). Indeed, both the RFC series and the acceptance of independent RFCs long pre-date even the existence of the IETF. I prefer that the IESG NOT have or assert the authority to mandate additions to Independent Stream or IRTF Stream documents. The existing approach where the IESG MAY request an IESG note is more than sufficient for cases where a non-IETF document is making an end-run around the IETF standards activities. We have lots of operational experience that this works well enough, so there is no obvious reason for the current approach to change. Robert Elz's notes from earlier today on this topic seem sensible, as do Joel Halpern's notes on this topic over the past several days. Yours, Ran Atkinson r...@extremenetworks.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Tuesday, September 01, 2009 16:37 +0300 Jari Arkko jari.ar...@piuha.net wrote: Robert, the IESG should not be making any kind of technical review of independent submissions Right, and we are not. - the reason the review was even permitted ... was to allow work that was submitted independently but which was directly in the same area as IETF work to be merged, and all considered together. That is indeed the primary goal of the 3932 and 3932bis. I.e., promote independent work, but allow a check in the exceptional case that it collides with IETF work. And that is, again, the answer to the question you raised. In the context of Headers and Boilerplates, the stream is identified. Many will pay attention or learn to do so. Others will not, but, for them (regardless of their motivation), there is no evidence that notices in obvious front-matter boilerplate will be noticed either. If members of the IESG have technical issues with a document, let them raise them as interested, skilled, and persuasive individuals as both the current and proposed revised versions of 3932, and your comment above indicate that they should. If they have major philosophical disagreements, let them write critical commentary, with explanations and details, and see if they can get them published as RFCs. Independent of their ability to use the IETF Track to self-publish, I have never, in the history of the RFC Series, seen the RFC Editor turn down a competently written and clear criticism of another document -- IMO, in the last decade or two, there have been far too few such submissions. Conversely, independent of technical substance, if the document is not clear enough about what it is --from the text-- tell the RFC Editor (ISE) and thereby promote a discussion with the authors about changes to make the document more clear. If the ISE ignores that advice, we quite frankly have a more serious problem. But I've never, and I mean never, seen that happen. To rephrase what others have said, attaching derogatory notes without explanations or specific attribution is the act of lazy people who either cannot or will not take responsibility for making document-specific comments that can either be attributed to those making them or that have been through enough process to represent IETF consensus. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Russ, I think that it is absolutely critical that the IETF be able to attach a note to an RFC and that this note not simply be a recommendation. We can believe all we want that the IETF stream is just one stream and that all other streams are independent. However, the RFC process is very tightly tied to the IETF, and I think it is reasonable for the IESG to be able to raise a note in an exceptional circumstance. I believe that this serves as an important check on the independent stream, just as the independent stream is supposed to serve as an important check on the IETF stream. Part of my thinking is motivated by my belief that the IETF has more structures in place and a broader community of people reviewing its work than the independent stream. I fully understand that there are people who are involved/interested in the independent stream who are not involved in the IETF. I believe that independent+ietf is a broader community than IETF alone. (We assume that it is a significantly broader community; I've never been given data to back up that assumption, but I'm happy to hold it for the moment.) However I doubt that community is sufficiently broader that it should be able to overrule the IETF. Even if the community was sufficiently broader, I'm still not sure that I would be comfortable with it being able to overrule the IETF of a comment that the IETF wanted to place on an independent stream document. However, the IESG is not the IETF. I'd personally be happy to ignore that and assume it would all work out. I'd also be happy with a mechanism where the IESG could propose a note, and the RFC editor had the option of accepting the note or asking the IESG to last-call its note within the IETF community. I would not consider it acceptable if the note were purely advisory. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Tuesday, September 01, 2009 09:55 +0200 pasi.ero...@nokia.com wrote: Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Pasi, A comment and then a suggested middle position. I've been watching what we now call the Independent Submission Process for far longer than there has been an IETF. I've seen it as an insider for a large fraction of two decades -- as an AD, an IAB member and then chair, as an editorial board member, and now as an IAB member again. During that period, I've never seen an RFC Editor abuse the process by ignoring legitimate input. Bob Braden may be able to provide an inside view --not in his present role of RFC Editor but as the very-long-time IAB Exec Director -- of what happened before 1992, but my educated guess is that instances of RFC Editor ignores input during that time were also about zero. During the same period, I'd seen behavior I consider abusive from ADs or the IESG many times -- attempting to prevent publication of documents with which they had personal/ emotional disagreements that they were unwilling or unable to explain in public, asking for publication holds on documents for multiples of years, insisting that the RFC Editor not move forward until the IESG responds in some way and then not responding for months and months, demanding changes that would significantly weaken the document or change its meaning, and so on. Many of those problems have been resolved by negotiation, but some have not. RFC 3932, and its limitation on technical review, was a huge improvement over its predecessors in that regard, but we've heard multiple ADs over the years claim that they can redefine any disagreement about a document into either a technical issue or a technical one (whichever is needed) if they care enough and especially if they can define the boundary (which they also have insisted that the IESG has the unilateral right to do). In principle, the IAB could appoint a new ISE to take over in January who would adopt a policy of abusiveness. But I think I can speak for the ACEF membership and the IAB if I say that we don't intend to do that... and that the IAB would expect the RSE to move fairly quickly, with the IAB's backing, to correct the attitudes involved if it occurred anyway. So trying to make IESG notes mandatory on documents originating in another stream for the reasons you cite above is solving a problem we've never had at the risk of making a problem worse that we've had several times. That strikes me as bad engineering at best. And insisting that the RFC Editor invoke a formal appeals procedure in case of disagreement with the IESG about an Independent Submission would, as Olaf points out, largely undo the efforts of the last few years to clearly separate the different streams. It would be as sensible to say that IESG notes should be sufficiently exceptional that the IESG would need to consult the IAB and get permission before sending any such note-request to the ISE. I suspect that such a provision would not make either the IESG or the IAB very happy. However, if your concern is really to make sure that there is a timely appeal path, I have a suggestion that might be acceptable to everyone without causing unfortunate side-effects. We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a reasonable period of time for the IESG to respond. If it felt it were necessary, the IESG could then open a further discussion, ask the RSE to mediate, or launch a formal request for IAB review. Consistent with other provisions in RFC 4846, either the IESG or the ISE could, at their discretion, make the correspondence (the request and response) public. The one restriction I'd impose on this is that reasonable time not be more than a few weeks... again, there has been abuse in that area in the past and re-enabling such abuse
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John == John C Klensin john-i...@jck.com writes: John However, if your concern is really to make sure that there John is a timely appeal path, I have a suggestion that might be John acceptable to everyone without causing unfortunate John side-effects. We simply require that, if the ISE receives John input from the IESG requesting specific changes to a John document (specific changes including, but not limited to, John so-called IESG Notes) and the ISE and authors decide to John not incorporate those proposed changes, the ISE is required John to explain to the IESG, in writing, why not and allow a John reasonable period of time for the IESG to respond. If it John felt it were necessary, the IESG could then open a further John discussion, ask the RSE to mediate, or launch a formal John request for IAB review. Consistent with other provisions in John RFC 4846, either the IESG or the ISE could, at their John discretion, make the correspondence (the request and John response) public. John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. Sam, If you have a specific complaint about the functioning of the RFC Editor, please bring it out on the rfc-interest list. I don't know what kind of abuse you think we are open to, but I would certainly like to hear it. Bob Braden I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
RFC 5620 calls for the appointment of an RFC Series Advisory Group, to be appointed by the IAB, and a Independent Submissions Stream Editorial Board (ISSEB for now), which serves at the pleasure of the ISE. This was reviewed and approved by the community. I presume with cognizance of the existing rules about the authority over the Streams. I presume you are concerned about the membership of the ISSEB. Given that this stream is specifically not an IETF stream, I do not see why it would make sense for the membership to be appointed by the IETF community, through its nomcom designates. With regard to appeals, are you asking for an ability to appeal an IAB decision about the RFC Editor? Presumably, a procedural appeal could be made to the ISoC Board of Trustees, if the IAB had not followed documented procedures. But otherwise, we are back to the issue of undermining the Independence of the Independent Stream. Remember, all of these documents are Experimental or Informational. Yours, Joel Sam Hartman wrote: John == John C Klensin john-i...@jck.com writes: John However, if your concern is really to make sure that there John is a timely appeal path, I have a suggestion that might be John acceptable to everyone without causing unfortunate John side-effects. We simply require that, if the ISE receives John input from the IESG requesting specific changes to a John document (specific changes including, but not limited to, John so-called IESG Notes) and the ISE and authors decide to John not incorporate those proposed changes, the ISE is required John to explain to the IESG, in writing, why not and allow a John reasonable period of time for the IESG to respond. If it John felt it were necessary, the IESG could then open a further John discussion, ask the RSE to mediate, or launch a formal John request for IAB review. Consistent with other provisions in John RFC 4846, either the IESG or the ISE could, at their John discretion, make the correspondence (the request and John response) public. John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Sam, On 2009-09-03 05:53, Sam Hartman wrote: ... 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole I'm certainly in favour of transparency in the process of setting up the Independent stream's editorial board. I could see value in an open call for nominations. However, you're asking for it to be set up in way that's very different from the typical editorial board for a scholarly journal or the typical technical programme committee for a scholarly conference. It seems to me that the editor needs to have the final say in the membership, because s/he needs to be able to work well with all the board members. Also, I have no idea how to define the community for the Independent stream. ISOC members? RIR members? ICANN community? ACM? BCS? IEEE? Where would it end? Brian N.B. I am a member of the current RFC Editorial Board, by invitation from the current RFC Editor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
I'd like to keep this discussion focused on the question that Jari asked. While changes to the Independent Stream can be discussed, that seems like rfc4846bis, not this document ... Several people have said that the RFC Editor already has the authority we are discussing here. Sadly, it is not that simple. The words cited below from RFC 3932 cloud this issue. I think they conflict with the words in the RFCs cited by John. RFC 3932 says: The IESG may return five different responses, any of which may be accompanied by an IESG note to be put on the document if the RFC Editor wishes to publish. I think that ... to be put on the document if the RFC Editor wishes to publish is the heart of the matter. RFC 3932 leaves the RFC Editor with the final say on publication, but if the document is published, the note must be included. Sam and Pasi have already pointed out that the RFC Editor can appeal the action taken by the IESG if they think the note is off base. In practice, the RFC Editor has asked the IESG to reconsider the text of one note, and the IESG has done so. There have not been any appeals on this topic since the publication of RFC 3932. The rfc3932bis-08 text provides greater flexibility to the RFC Editor, making the IESG note a recommendation to the RFC Editor. The is the flexibility that several people have claimed the RFC Editor has had all along based on other documents. Please, let's try to answer this one question on this thread: When the IESG performs review of an Independent stream or IRTF stream document and provides an IESG Note, does the RFC Editor have the authority (without a request for reconsideration or an appeal) to publish the document without the IESG Note? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Wednesday, September 02, 2009 13:53 -0400 Sam Hartman hartmans-i...@mit.edu wrote: John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. Sam, Brian and Joel covered most of what I would have said had I gotten to your note earlier. I would add only three things to their remarks: (1) Checks and balances against what? I trust the answer is not publication of high-quality articles which contain content with which some AD happens to disagree because that is the only thing that has been at issue in the past. On other matters, the RFC Editor has _voluntarily_ deferred to the IESG, often going well beyond what the current procedures require. Remember that RFC Editor acceptance of an IESG Note is voluntary today, regardless of what the IESG might believe, _and_ that the written notice procedure I suggested has been followed, as a professional courtesy, for years, without any such requirement being written down anywhere. Put differently, what is the threat model against which you are trying to defend? (2) If I have to make a choice, I prefer to design systems to deal with real and identified threats rather than purely theoretical ones. As I pointed out, we've had repeated examples over the years of the IESG and/or individual ADs abusing the independent submission process and/or the RFC Editor and zero examples of the RFC Editor handling a request from the IESG unreasonably or arbitrarily. So why do you believe we need more protection against the possibility of RFC Editor abuse than we do against IESG abuse or, from a different perspective, believe that the wider community would be better served by tilting the balance even further toward the IESG? (3) As Dave Crocker is fond of pointing out, the Nomcom cannot be expected to make good appointments in areas that are outside the expertise of most of its members... there is just no foundation on which a Nomcom without that expertise can evaluate candidates. Given that, why do you believe that the Nomcom could select an effective editorial board, with or without a broader selection process? Neither democracy nor randomness seem to me to be guarantees of competence. And, again, what real problem do you think that would solve? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Sam Hartman wrote: Russ, I think that it is absolutely critical ... Sam, However, the IESG is not the IETF. This is the single-most important statement in your note. Absolutely critical is strong language, but is not warranted by 20 years of experience or any other empirical basis. We need to be very careful not to confuse mathematical possibility with operational reality and we need to be careful to consider real costs, along with theoretical benefits. The RFC Editor is also part of the IETF, with plenty of its own accountability, and it has established a history of highly professional and responsible performance, including over the last 10 years, while under new management. The IESG is not, and must not be, the sole repository for responsible decision-making in the IETF, yet that really seems to be at the core of your view. There is no legitimate reason to allow the IESG to mandate language in an Independent RFC, and there is very good reason /not/ to allow it to. For example, it then wouldn't be Independent... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: Dave CROCKER d...@dcrocker.net The IESG is not, and must not be, the sole repository for responsible decision-making in the IETF Couldn't agree more. A division of powers, with checks and balances, are a critical part of any organizational system, IMO. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Being a relatively short-term IETF participant, I lack the history that many on this list have, but since Jari asked for comments, I'll provide some. Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and others that it makes sense to have IESG notes be mandatory for the ISE to include in independent stream RFCs. Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. So I agree with Jari's option (b), that IESG notes should be something that is always applied to the published RFC. --Richard Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
In fact, I do not think the presence or absence of a note means what you describe. First, remember the Independent Submission do get reviewed. They do not get IETF review. But they do get technical review by senior technical participants in this community. This review can be thought of, as another note pointed out, as being comparable to the peer review required for scholarly journals. Secondly, given that one of the points of the stream is to provide a mechanism for informed critique of our work, it is unsurprising that the IESG has objected to such critiques. Third, it should be remembered that the IESG review being discussed is not a technical review. It is a review for the relationship between this work and the IETF work. If the IESG finds that there is a relevant relationship, and provides a reasonable note saying so, then the ISE is going to publish it. (There may be negotiation about the wording, but the editors responsibility to be factually accurate means that such accurate notes will be published.) If IESG members in reading the document find technical problems, then they should tell the ISE, just the way any other reviewer would. Next, given that the review is not technical, and given that the review is done by a small number of people, I would not want a reader to draw conclusions about technical competence based on the presence or absence of an IESG note. Such conclusions should be based on reading the document. And let's be careful about asserting that IESG review is an assurance of quality. There have been plenty of marginal documents that the IESG has approved over the years. Sometimes they approved them for very good reasons. Note that even 15 years ago the IESG was under interesting publication pressures some of the time. I am sure it still is. If you want to abolish the Independent Stream, then we can have a discussion (separately from this one) about who would get to do that, and whether that would mean that the IETF would have to find a different outlet, or the Independent Stream. The mix of history, practice, and branding would make for a very confusing situation. Personally, I think the Independent Stream is valuable. (That's why I help review them.) So I do not want that stream or its independence weakened. Also, remember that there are actually 4 streams. I presume that no one is trying to suggest that the IESG should get to put IESG warning notes on IAB documents or IRTF documents? Yet IRTF documents are actually sometimes less reviewed than Independent Stream documents. It is not uncommon for an IRTF Working group to produce multiple reports when the group can not come to agreement. (Note, I do not think that the degree of review correlates with the degree of quality. That is a further confusion about these notes.) Yours, Joel M. Halpern Richard Barnes wrote: Being a relatively short-term IETF participant, I lack the history that many on this list have, but since Jari asked for comments, I'll provide some. Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and others that it makes sense to have IESG notes be mandatory for the ISE to include in independent stream RFCs. Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. So I agree with
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi, On 2009-8-31, at 18:34, Adam Roach wrote: In particular, when a user accesses a document at a url of the form http://www.ietf.org/rfc/rfc.txt, there is going to be a strong presumption on their part that the document was produced by the IETF. In the cases that this presumption is incorrect, it seems tantamount to deception to tuck the distinction between IETF and non-IETF documents away in an obscure header field. I agree with you. This is exactly why I had originally proposed to stick the words NOT AN INTERNET STANDARD into the top left corner on the first page (where it currently says Network Working Group) for all non-standards-track documents in all streams. That proposal got shot down with the (paraphrased) argument we should label RFCs with what they are rather with what they are not. I still disagree with this, because the #1 question what looking at any RFC should be is this an Internet standard or not? Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 2009-8-31, at 19:24, Joel M. Halpern wrote: But the same could be said all our experimental and informational RFCs. Should we insist that all experimental and informational RFC, even from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD. FWIW, this was exactly what I proposed a while ago. The current way we label RFCs requires folks to understand the intricacies of the different streams. Few in the broader industry do. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Adam, So, to be clear, the question you have raised has to do with the difference between: The IESG may choose to add an IESG note to an Independent Submission... and: The IESG may choose to request the addition of an IESG note to an Independent Submission... Right? Yes. This has nothing to do with the text: In exceptional cases, when the relationship of the document to the IETF standards process might be unclear... ? Right. The exceptional vs. always-on question is another issue. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Aug 31, 2009, at 3:29 PM, Jari Arkko wrote: And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. I am happy to see the document being reverted so that an IESG note is exceptional. Over the last years I've started to appreciate the fact that the RFC Series is not exclusively an IETF series. On the other hand I am sensitive to the argument that most consumers of RFCs do not see the fine distinction between standards track and non-standards track RFCs, let alone the difference between non-standards track from various streams. Headers and Boilerplates tried to address that and hopefully helps to clarify the fact that not every RFC is an IETF Standards Track document. However, the whole RFC streams framework has been build with complete independence of the various stream in mind. In my opinion that makes sense. The IAB should not be able to force notes on IETF stream documents, the IRTF should not be able to put them on IAB stream documents, and the IESG should not be able to force them on IRTF, IAB and Independent documents. In other words it is not clear to me why the combination IESG and the Independent stream should have a special status. And, as other mentioned, deciding about that special status is not a matter that rests solely with the IESG/IETF stream. I do think that in essence this is a fairly theoretical discussion. I believe that in general notes from the IESG will have merit and recommendations will in general be followed, specifically since they are likely to be exceptional. In the case that the judgement, by the IESG and ISE, of merit conflicts, there is a procedure in RFC 5620. I'm for (a). --Olaf (no hats) 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Date:Mon, 31 Aug 2009 16:29:26 +0300 From:Jari Arkko jari.ar...@piuha.net Message-ID: 4a9bd036.1000...@piuha.net | And now back to the input that I wanted to hear. I would like to get a | sense from the list whether you prefer (a) that any exceptional IESG | note is just a recommendation to the RFC Editor or (b) something that is | always applied to the published RFC. Definitely (a) - the reasons for this have already been made by many others and I won't repeat them. But, I'd also change the target of the recommendation - the IESG shouldn't be asking or instructing the editor (whichever form of editor, RFC or ISE or ...) in any way, rather they should be suggesting to the author of a document that it would likely be more acceptable if it included some extra particular text. The editor would then, of course, take the author's response to that request into account when deciding whether or not to publish the author's document. Lastly, as has been stated already, but this time I will restate it for emphasis, the IESG should not be making any kind of technical review of independent submissions - the reason the review was even permitted (remember previously independent submissions went directly to the RFC editor who simply published them, or declined) was to allow work that was submitted independently but which was directly in the same area as IETF work to be merged, and all considered together.That is, the IESG is just supposed to determine whether there is (or perhaps should be) a WG to work on the same topic, and if so, invite the author to submit the document to that WG for further review (and even possibly elevation into the standards track). Beyond that, the IESG should be leaving independent submissions alone. kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Robert, the IESG should not be making any kind of technical review of independent submissions Right, and we are not. - the reason the review was even permitted ... was to allow work that was submitted independently but which was directly in the same area as IETF work to be merged, and all considered together. That is indeed the primary goal of the 3932 and 3932bis. I.e., promote independent work, but allow a check in the exceptional case that it collides with IETF work. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Date:Tue, 01 Sep 2009 16:37:31 +0300 From:Jari Arkko jari.ar...@piuha.net Message-ID: 4a9d239b.7070...@piuha.net | Right, and we are not. That is very good to hear. I haven't been watching much of recent IETF happenings (last few years) so I explicitly make no comment about anything that has happened recently. In the past however, back when I was more involved, there were occasions when that was certainly not the case - there were cases where the IESG decided that a proposal (an independent submission) would really be bad for the internet, and requested (and perhaps even published) notes with comments along the lines of how insecure, unscalable, and generally horrid some document was, and strongly advising the world to ignore it. That's all technical discussion, and none of that should ever be a part of an IESG note requested to be added to a doc. Given that, what's left for an IESG note pretty much amounts to this does not represent IETF consensus or Readers should also see RFC for an alternative solution - neither of which are very likely to be ignored by the editor - or in fact, by the doc author if requested of him or her - so there should be no need for mandatory addition of notes, just a request should be enough (ie: if one ever is refused, the chances are really pretty good that it should never have been requested.) One final note, none of this, of course, prevents anyone, including IESG members, writing their own independent submission, criticising some other proposal (in a different RFC) - such a thing could even be made an IETF consensus doc if desired - that's all reasonable,but of course takes more effort, and real considered and supported arguments, an IESG note to the same effect is just the lazy way out, and should never be used (and to repeat my opening comment, I am not claimimg that it has any time recently, I simply have no idea.) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Monday, August 31, 2009 16:29 +0300 Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. ... And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. Jari, I've said this before, but not during the recent Last Call, so, to get a note on the record... Any IESG note or comment, exceptional or otherwise, has always (always == since the IESG was created and long before it started writing notes) been an recommendation to the RFC Editor. That position is reflected in long-term precedent, in RFC 4844, and in the new RFC Editor Model document. Under the new model, should the RFC Editor decide to not accept a proposed IESG note, the IESG can raise the issue with the RSE and, if necessary, with the IAB, presumably causing a wider community review of the proposed note itself. That level of protection (which goes beyond that historically available) should be both necessary and sufficient for the IESG's purposes. Procedurally, should the IESG wish to change that position, I believe it would require the approval of the IAB (because it changes the RFC Editor role and relationship) and a review of the Headers and Boilerplates document, the RFC Editor Model document, and perhaps some of the statements of work associated with the new RFC Editor contracts and appointments. I have reason to believe that the IAB would insist on community review before granting such approval, so trying to change things in this area at this late date is not consistent with rapid progress and may be inconsistent with having a fully-functional RFC Editor function in place at the beginning of January. More broadly, as the community has discussed extensively, the IESG should not have the right to deprecate or denigrate the contents of any document from another stream without broad community consensus. Nothing in any community-approved IETF procedural document from RFC 2026 forward gives the IESG such authority (or authority for doing much of anything else other than steering/managing) without community approval and consensus. Even the claim in the original version of 3932 that a document has not been reviewed in the IETF is inappropriate unless such review has actually not occurred (whether or not consensus was reached). So I believe that your clarifying change was, in fact, editorial and that it should remain. ... regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Following a request to look at this document, and with only a cursory look at the archives, I'm confused. The note is always intended to be included in the document itself, right? Is this change designed to compel, as opposed to request, the RFC Editor to include the note? If the answer to those is yes, then I support the change. The RFC Editor is not selected to make judgments on whether a note from the IESG should, or should not be included in a document. It's not an editorial judgment, it's is a technical concern. However, I think some form of appeal is needed, perhaps to the IAB, that would allow authors some measure of control of what goes in their document. Brian On 8/31/09 9:29 AM, Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Monday, August 31, 2009 10:59 -0400 Brian Rosen b...@brianrosen.net wrote: Following a request to look at this document, and with only a cursory look at the archives, I'm confused. The note is always intended to be included in the document itself, right? Is this change designed to compel, as opposed to request, the RFC Editor to include the note? If the answer to those is yes, then I support the change. The RFC Editor is not selected to make judgments on whether a note from the IESG should, or should not be included in a document. It's not an editorial judgment, it's is a technical concern. Brian, Remember that 3932bis applies to the Independent Submission stream, not to IETF documents of any flavor. These are, in general, documents that have not been formally reviewed in the IETF (although many of them have been extensively discussed). They are not IETF Stream documents, about which, subject to push-back from WGs and the community, the IESG can do pretty much as it likes. For these documents, there is no IETF Last Call. If the IESG creates a note, that note reflects the individual judgments of the ADs (and presumably IESG review and approval of those judgments) and not the rough consensus of the IETF community. Given that, while it may be a technical concern (or at least reflective of a technical preference), it is a concern from (at most) a group of individuals who happen to be on the IESG; there is no requirement that it represent a technical concern from the IETF community. In that context, what you are really asking for is that the preferences or concerns of that group of individuals -- preferences that they could not get the RFC Editor or document authors to accept through normal review channels -- override the decision-making process and approval of a non-IETF stream. Especially since we expect documents in the Independent Submission stream that would carefully criticize or provide alternatives to IETF-approved approaches (see RFC 4846), giving the IESG that much authority, especially without consulting the IETF Community and determining consensus, does not seem sensible or consistent to me. Indeed, it seems like a mechanism for permitting only authorized dissent. ... YMMD. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, Jari - I was one of the folks expressing the concern Jari points to below, and it's a small facet of a larger worry I have about a potential (and I think likely) unintended consequence of the header/boilerplate changes. To capture that in this thread (with apologies for walking through old discussions) : specifically, I think we're making it even harder for people who are not deeply steeped in IETF arcana to tell the difference between the output of a working group (or any other IETF product) and the output of an individual. By downplaying that distinction, we are also making it easier for people with the motivation to champion technologies that compete with IETF products to convince those non IETF-arcana-steeped folks around them to follow. But, that's water under the headers and boilerplate consensus building bridge. I think it should be more _routine_ than we are making it for _some_ body representing IETF consensus to shine a light on that distinction when necessary. The escalation process you point to is a fairly high bar and it puts providing the required energy on the wrong parties. I'm sensitive to the 'how it has always been' argument, but we are exactly in the process of changing to a new RFC-editor model. I've also been asking a few regular contributors and some chairs what they thought about this, and am very frustrated with how little attention the entire change this small conversation is part of appears to have received in the greater community. I don't know what to do to improve that beyond what we're doing now (through calls like this and through individual prodding). RjS On Aug 31, 2009, at 9:37 AM, John C Klensin wrote: --On Monday, August 31, 2009 16:29 +0300 Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. ... And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. Jari, I've said this before, but not during the recent Last Call, so, to get a note on the record... Any IESG note or comment, exceptional or otherwise, has always (always == since the IESG was created and long before it started writing notes) been an recommendation to the RFC Editor. That position is reflected in long-term precedent, in RFC 4844, and in the new RFC Editor Model document. Under the new model, should the RFC Editor decide to not accept a proposed IESG note, the IESG can raise the issue with the RSE and, if necessary, with the IAB, presumably causing a wider community review of the proposed note itself. That level of protection (which goes beyond that historically available) should be both necessary and sufficient for the IESG's purposes. Procedurally, should the IESG wish to change that position, I believe it would require the approval of the IAB (because it changes the RFC Editor role and relationship) and a review of the Headers and Boilerplates document, the RFC Editor Model document, and perhaps some of the statements of work associated with the new RFC Editor contracts and appointments. I have reason to believe that the IAB would insist on community review before granting such approval, so trying to change things in this area at this late date is not consistent with rapid progress and may be inconsistent with having a fully-functional RFC Editor function in place at the beginning of January. More broadly, as the community has discussed extensively, the IESG should not have the right to deprecate or denigrate the contents of any document from another stream without broad community consensus. Nothing in any community-approved IETF procedural document from RFC 2026 forward gives the IESG such authority (or authority for doing much of anything else other than steering/managing) without community approval and consensus. Even the claim in the original version of 3932 that a document has not been reviewed in the IETF is inappropriate unless such review has actually not occurred (whether or not consensus was reached). So I believe that your clarifying change was, in fact, editorial and that it should remain. ... regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
I have a serious concern about the impact of this decision and the perception of RFCs by the community that uses the output of the IETF. The IETF process has a number of very strong safeguards in place to ensure that the protocols we publish have certain levels of quality and safety built in, and the Internet community at large has grown to associate that level of quality with the RFC series. While the presence of alternate streams of publication doesn't bother me, I think they need to be automatically and prominently marked as being something other than an IETF document. In particular, when a user accesses a document at a url of the form http://www.ietf.org/rfc/rfc.txt, there is going to be a strong presumption on their part that the document was produced by the IETF. In the cases that this presumption is incorrect, it seems tantamount to deception to tuck the distinction between IETF and non-IETF documents away in an obscure header field. /a Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Before commenting on the question, I wish to comment slightly on the exposition. While I understand that some IESG members were surprised that the text brought to them treated IESG notes as a recommendation to the RFC Editor, such surprise gap in historical information rather than a change. That text was not a change in practice. The documented rules and practice has long been that with regard to Independent Submissions the IESG notes are a request / recommendation to the RFC Editor (soon to be ISE), not a statement of what will be included in the result. Based on having seen a number of IESG notes, and reading the resulting text and its inherent tone, I would strongly prefer that IESG notes be an exception. Also, I believe that the stream identification and associated indications are quite sufficient for the normal case. Unless we wish to deliberately denigrate the Independent Submissions tream, we should not be putting extra notes on the front of them. I consider the Independent Stream to be an important source of information and commentary that helps the overall internet process, and would be very unhappy to see it denigrated. Thus, I strongly prefer (a). I prefer that such notes be rare, and that they remain recommendations to the ISE. Even if the IAB were to agree that such notes should be common, I would strongly recommend that the tone and content of such notes remain at the discretion of the ISE. Otherwise, there is no true Independent series. Yours, Joel M. Halpern Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: Thus, I strongly prefer (a). I prefer that such notes be rare, and that they remain recommendations to the ISE. +1 to that, S. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
If I understand your note properly, your primary concern is that folks will think that Independent submission are IETF products. This is a fair concern. But the same could be said all our experimental and informational RFCs. Should we insist that all experimental and informational RFC, even from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD. Repeated multiple times to make sure folks do not miss it? (remember, Independent Submissions are never standards track documents.) Wed try very hard to make it clear to folks that there is a difference between standards track documents and non-standards track documents. Independent Stream documents are not standards track documents. While it is important to note when experimental or informational documents have had community review, and when they haven't, I do not see that the distinction, for these documents, warrants denigrating outside comment and input. Remember also that in terms of the text being a recommendation, this is not a change in practice. This is the practice we have had for more than the last 15 years. If, for Independent Submissions, it is that big a problem, I would expect ot have heard of it. Also, to pick up a comment from Robert, and reinforce and answer from John, in providing an IESG note for an Independent Submission, the IESG is not shining the light of IETF consensus (rough or otherwise) on the document. While I strongly respect the IESG judgment, and want them to keep using and applying that judgment, I do not think it fair to conflate that with reflecting IETF consensus on something where there no source for such consensus. (For clarity, I do want the IESG to have the opportunity to make their recommendation, and I want it taken serious by the ISE / RSE. This is because they do have a view of the IETF activity picture, and can provide necessary perspective and judgment about the relationships among the moving parts. But let us not induce confusion by assigning that judgment inappropriate grounding.) Yours, Joel Adam Roach wrote: I have a serious concern about the impact of this decision and the perception of RFCs by the community that uses the output of the IETF. The IETF process has a number of very strong safeguards in place to ensure that the protocols we publish have certain levels of quality and safety built in, and the Internet community at large has grown to associate that level of quality with the RFC series. While the presence of alternate streams of publication doesn't bother me, I think they need to be automatically and prominently marked as being something other than an IETF document. In particular, when a user accesses a document at a url of the form http://www.ietf.org/rfc/rfc.txt, there is going to be a strong presumption on their part that the document was produced by the IETF. In the cases that this presumption is incorrect, it seems tantamount to deception to tuck the distinction between IETF and non-IETF documents away in an obscure header field. /a Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: The documented rules and practice has long been that with regard to Independent Submissions the IESG notes are a request / recommendation to the RFC Editor (soon to be ISE), not a statement of what will be included in the result. ... Based on having seen a number of IESG notes, and reading the resulting text and its inherent tone, I would strongly prefer that IESG notes be an exception. ... Thus, I strongly prefer (a). I prefer that such notes be rare, and that they remain recommendations to the ISE. +1. It might help folks to understand the independent relationship, between the IETF/IESG and these other RFC streams, if the title of this draft were changed from Handling of to Assisting with. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. Brian On 8/31/09 11:25 AM, John C Klensin john-i...@jck.com wrote: Brian, Remember that 3932bis applies to the Independent Submission stream, not to IETF documents of any flavor. These are, in general, documents that have not been formally reviewed in the IETF (although many of them have been extensively discussed). They are not IETF Stream documents, about which, subject to push-back from WGs and the community, the IESG can do pretty much as it likes. For these documents, there is no IETF Last Call. If the IESG creates a note, that note reflects the individual judgments of the ADs (and presumably IESG review and approval of those judgments) and not the rough consensus of the IETF community. Given that, while it may be a technical concern (or at least reflective of a technical preference), it is a concern from (at most) a group of individuals who happen to be on the IESG; there is no requirement that it represent a technical concern from the IETF community. In that context, what you are really asking for is that the preferences or concerns of that group of individuals -- preferences that they could not get the RFC Editor or document authors to accept through normal review channels -- override the decision-making process and approval of a non-IETF stream. Especially since we expect documents in the Independent Submission stream that would carefully criticize or provide alternatives to IETF-approved approaches (see RFC 4846), giving the IESG that much authority, especially without consulting the IETF Community and determining consensus, does not seem sensible or consistent to me. Indeed, it seems like a mechanism for permitting only authorized dissent. ... YMMD. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. It seems important to begin a discussion with true facts, and the statement immediately above is false. To quote Harald's words from RFC 3932: In March 2004, the IESG decided to make a major change in this review model. The new review model will have the IESG take responsibility ONLY for checking for conflicts between the work of the IETF and the documents submitted; soliciting technical review is deemed to be the responsibility of the RFC Editor. If an individual IESG member chooses to review the technical content of the document and finds issues, that member will communicate these issues to the RFC Editor, and they will be treated the same way as comments on the documents from other sources. Sigh. I suppose this message is a derivative work. Bob Braden' ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. +1 , including the IETF consensus call part. (...and to venture into the water under the consensus bridge part of the discussion...) Joel wrote: If I understand your note properly, your primary concern is that folks will think that Independent submission are IETF products. This is a fair concern. But the same could be said all our experimental and informational RFCs. Should we insist that all experimental and informational RFC, even from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD. Repeated multiple times to make sure folks do not miss it? (remember, Independent Submissions are never standards track documents.) Wed try very hard to make it clear to folks that there is a difference between standards track documents and non-standards track documents. Independent Stream documents are not standards track documents. And we fail miserably in those cases too. Since I first started contributing in the IETF, I have on countless occasions had to explain to people who don't participate that some given RFC is not a standard. To most of the world, RFC==standard. Maybe putting THIS IS NOT AN IETF STANDARD all over the place would help, but I'm not sure about even that. Even worse, I have personally seen multiple instances of marketing people intentionally introducing FUD by talking about compliancy to some non standards-track RFC. (or even an ID that had been actively deprecated by the relevant working group.) Personally, I think our first mistake was using the same document name prefix for the different streams. I am most particularly concerned about the case where a draft that was presented to a work group that selected not to publish it, and then later gets published in the independent stream. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: And given that these are Independent Submissions, they aren't supposed to be subject to community review. Given this fact, why is there pushback on the idea that we would prominently mark the documents to indicate that they have not been subjected to community review? It seems like the kind of thing that is of extreme relevance to the reader. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Monday, August 31, 2009 10:30 -0700 Bob Braden bra...@isi.edu wrote: Your argument seems to me to be the latest version of the 30-year old discussion about whether all RFCs are standards. ... Not quite 30 years, because it took us a while to start using terms like standard, and even longer to get the IETF into existence into existence. But, as part of that long argument it is worth reminding those those think that non-standards RFCs should be published in a different series that the IETF, after it was created, decided to publish its standards-track documents in the RFC Series. It isn't as if the other documents were somehow grafted on -- it is the IETF standards-track materials that were grafted on to what was previously an almost-all-independent-submissions situation (there were a few IANA and IAB documents in the series too). I know you know that, but others seem to forget, and to do so fairly regularly. The Headers Boilerplate document is supposed to help with the identification situation by explicitly identifying the streams and the role of each. If those warnings are not sufficient, it is not clear to me that boilerplate notes, of the variety that RFC 3932 has been read as calling for, will help much. ... And even documents in the IETF stream (which includes individual submission, by the way) very considerably in quality and safety. Hmm. I have a counter-proposal to those IESG members who believe in their right to include negative-sounding comments about independent submission documents without explaining the reasons for their objections (or, often, even the objections themselves) or taking responsibility for those objections by signing their names or at least putting explicit information into the tracker. The current RFC Editorial Board contains significant expertise and does review the Independent Submission documents for technical adequacy. If IESG membership is a special qualification, it is worth noting that the Editorial Board's membership includes several former ADs and even two former IETF Chairs. How about we start Editorial Board review of all IETF Stream documents arriving from the IESG and, where the Editorial Board deems it appropriate, attaches notes that reflect on the quality and/or safety of the ideas suggested. I imagine that the Editorial Board would at least be willing to be specific about objections and to sign specific notes, unlike, at times, the IESG. Let the second-guessing begin! No, not really it is a terrible idea and I can't imagine most Editorial Board members having time, but perhaps it makes the point. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: Wed try very hard to make it clear to folks that there is a difference between standards track documents and non-standards track documents. Independent Stream documents are not standards track documents. And I agree that there is an issue of the community not distinguishing among standards-track, informational, and experimental documents. But that's a separable problem that is, in my opinion, of much smaller consequence. I assert that the distinction between these classes of documents is much, much smaller than the distinction between IETF-reviewed documents and independent stream documents. Remember also that in terms of the text being a recommendation, this is not a change in practice. This is the practice we have had for more than the last 15 years. If, for Independent Submissions, it is that big a problem, I would expect ot have heard of it. Perhaps I'm just unclear on the frequency of independent submissions -- but can you find me an RFC that came from a source other than the IETF that does not include a prominent note indicating that fact? I'm under the distinct impression that historical practice tagged all (or almost all) such documents with a prominent note. The proposed procedure tries to make this an extreme exception, not the norm. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
If every document needs this marking, then that is a matter for headers and boilerplates. I can understand arguing about how we mark documents. If our headers and boilerplate are not sufficient, then we should renegotiate them. I personally think that they are about as good as we can get. But the IESG review is for checking for conflicts with IETF work. It is for reporting such conflicts. It is not a general review for does the IETF like this work. Yours, Joel Adam Roach wrote: Joel M. Halpern wrote: And given that these are Independent Submissions, they aren't supposed to be subject to community review. Given this fact, why is there pushback on the idea that we would prominently mark the documents to indicate that they have not been subjected to community review? It seems like the kind of thing that is of extreme relevance to the reader. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Monday, August 31, 2009 13:20 -0500 Adam Roach a...@nostrum.com wrote: Joel M. Halpern wrote: And given that these are Independent Submissions, they aren't supposed to be subject to community review. Given this fact, why is there pushback on the idea that we would prominently mark the documents to indicate that they have not been subjected to community review? It seems like the kind of thing that is of extreme relevance to the reader. Because the statement this has not been subjected to community review is often factually incorrect and because there are multiple communities out there. Some of these documents are actually more intensively reviewed, by more experts, than some things the IETF puts on the standards track. If the IESG were inclined to quiz the RFC Editor as to what review had occurred and then jointly identify each document, including IETF Stream documents, with the precise type of review that had occurred, we would be having a different discussion. Headers and Boilerplates provides for some of that type of annotation without requiring any IESG notes. Alternately, if the IESG wanted to subject every Independent Submission document to IETF Last Call, review the results of that Last Call, and on that basis, sometimes generate a note and subject it to IETF Last Call, I'd have no problem at all introducing a section into Independent Submission Track RFCs containing the IETF's opinion of the document, identified as such. For lots of good reasons, I don't expect that to happen and do not consider vague text that may be false (e.g., claiming that no review within the IETF community occurred when, in fact, it might have) to be helpful in this regard. I also believe that having the IESG tell lies that can easily be tested and exposed as such does not contribute positively to the reputation of the IETF. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
If we really feel that the current approach does not make non-standards clear enough, then we should address that for all experimental or informational documents. It is basically unrelated to the Independent Stream issue. With regard to documents that are alternatives to existing IETF work, the RFC Editor has always required, as is appropriate for any academic work, a description of the relationship to existing work. Reviewers who know the area and work are selected. Thus, the document, in its text, is expected to explain why it is different from the standard. Which also requires it to be clear that it is different from the standard. Handling such discrepancies in the document is both clearer, more effective, and fairer to the authors than trying to solve the problem by slapping a note on the front of the document. And before someone says but the ISE is not requrie to do that, note that the ISE is required to maintain the quality of the stream. That includes ensuring that there is suitable description of the relationship to existing work. So not only is this the current practice, but it is part of what we can reasonably expect. I guess this relates to a lot of my problem with this whole mandatory IESG notes approach. If there is a real problem with the document, then the document should address the problem. If the IESG does not like the light the document puts the IETF into, then we probably made a mistake earlier, and this is not the place to fix it. And given that these are Independent Submissions, they aren't supposed to be subject to community review. Yours, Joel Ben Campbell wrote: On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. +1 , including the IETF consensus call part. (...and to venture into the water under the consensus bridge part of the discussion...) Joel wrote: If I understand your note properly, your primary concern is that folks will think that Independent submission are IETF products. This is a fair concern. But the same could be said all our experimental and informational RFCs. Should we insist that all experimental and informational RFC, even from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD. Repeated multiple times to make sure folks do not miss it? (remember, Independent Submissions are never standards track documents.) Wed try very hard to make it clear to folks that there is a difference between standards track documents and non-standards track documents. Independent Stream documents are not standards track documents. And we fail miserably in those cases too. Since I first started contributing in the IETF, I have on countless occasions had to explain to people who don't participate that some given RFC is not a standard. To most of the world, RFC==standard. Maybe putting THIS IS NOT AN IETF STANDARD all over the place would help, but I'm not sure about even that. Even worse, I have personally seen multiple instances of marketing people intentionally introducing FUD by talking about compliancy to some non standards-track RFC. (or even an ID that had been actively deprecated by the relevant working group.) Personally, I think our first mistake was using the same document name prefix for the different streams. I am most particularly concerned about the case where a draft that was presented to a work group that selected not to publish it, and then later gets published in the independent stream.___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Adam Roach wrote: While the presence of alternate streams of publication doesn't bother me, I think they need to be automatically and prominently marked as being something other than an IETF document. In particular, when a user accesses a document at a url of the form http://www.ietf.org/rfc/rfc.txt, there is going to be a strong presumption on their part that the document was produced by the IETF. In the cases that this presumption is incorrect, it seems tantamount to deception to tuck the distinction between IETF and non-IETF documents away in an obscure header field. /a Your argument seems to me to be the latest version of the 30-year old discussion about whether all RFCs are standards. They are not. And even documents in the IETF stream (which includes individual submission, by the way) very considerably in quality and safety. Bob Braden Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: If every document needs this marking, ... If this line of discussion needs to happen, it needs to happen on a separate thread, because I believe it has nothing to do with the current text, proposal, or concern. As noted, it is opening a very old -- and I believe very different -- basic concern. The current question is about IESG Notes. We ought to restrict postings on this thread to that question. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Dave, The current question is about IESG Notes. We ought to restrict postings on this thread to that question. Yes. As always, before a draft is actually approved we appreciate getting all kinds of feedback on it. Particularly if there's a serious problem somewhere. Of course, when a Last Call period is over, we do not re-open a document lightly even if it hasn't been approved yet. However, in this case: if you have a general comment on 3932bis, please post to the Last Call thread. If you want to answer my specific question about the optional/mandatory nature of the IESG note, please respond to this thread. My current plan is NOT to reopen other aspects of the document, though I understand that some of them may have to be discussed to provide context for the specific question. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Jari Arkko wrote: However, in this case: if you have a general comment on 3932bis, please post to the Last Call thread. If you want to answer my specific question about the optional/mandatory nature of the IESG note, please respond to this thread. So, to be clear, the question you have raised has to do with the difference between: The IESG may choose to add an IESG note to an Independent Submission... and: The IESG may choose to request the addition of an IESG note to an Independent Submission... Right? This has nothing to do with the text: In exceptional cases, when the relationship of the document to the IETF standards process might be unclear... ? /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
+1 to Dave's suggestion below regarding the name of the draft, as well as Joel's and John's responses to Jari's original question (i.e., retain existing practice regarding IESG notes). Cheers, Andy On Mon, Aug 31, 2009 at 12:27 PM, Dave CROCKERd...@dcrocker.net wrote: Joel M. Halpern wrote: The documented rules and practice has long been that with regard to Independent Submissions the IESG notes are a request / recommendation to the RFC Editor (soon to be ISE), not a statement of what will be included in the result. ... Based on having seen a number of IESG notes, and reading the resulting text and its inherent tone, I would strongly prefer that IESG notes be an exception. ... Thus, I strongly prefer (a). I prefer that such notes be rare, and that they remain recommendations to the ISE. +1. It might help folks to understand the independent relationship, between the IETF/IESG and these other RFC streams, if the title of this draft were changed from Handling of to Assisting with. d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi Jari, At 06:29 31-08-2009, Jari Arkko wrote: And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. I prefer option (a); the IESG note is just a recommendation to the RFC Editor. If the IESG wants the IESG Note to always be applied, it is determining the RFC Editor policy and that's the role of the IAB according to Section 5. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Monday, August 31, 2009 16:29 +0300 Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. ... And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. Jari, I've said this before, but not during the recent Last Call, so, to get a note on the record... Any IESG note or comment, exceptional or otherwise, has always (always == since the IESG was created and long before it started writing notes) been an recommendation to the RFC Editor. That position is reflected in long-term precedent, in RFC 4844, and in the new RFC Editor Model document. Under the new model, should the RFC Editor decide to not accept a proposed IESG note, the IESG can raise the issue with the RSE and, if necessary, with the IAB, presumably causing a wider community review of the proposed note itself. That level of protection (which goes beyond that historically available) should be both necessary and sufficient for the IESG's purposes. Procedurally, should the IESG wish to change that position, I believe it would require the approval of the IAB (because it changes the RFC Editor role and relationship) and a review of the Headers and Boilerplates document, the RFC Editor Model document, and perhaps some of the statements of work associated with the new RFC Editor contracts and appointments. I have reason to believe that the IAB would insist on community review before granting such approval, so trying to change things in this area at this late date is not consistent with rapid progress and may be inconsistent with having a fully-functional RFC Editor function in place at the beginning of January. More broadly, as the community has discussed extensively, the IESG should not have the right to deprecate or denigrate the contents of any document from another stream without broad community consensus. Nothing in any community-approved IETF procedural document from RFC 2026 forward gives the IESG such authority (or authority for doing much of anything else other than steering/managing) without community approval and consensus. Even the claim in the original version of 3932 that a document has not been reviewed in the IETF is inappropriate unless such review has actually not occurred (whether or not consensus was reached). So I believe that your clarifying change was, in fact, editorial and that it should remain. ... regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 2009-09-01 05:56, Ben Campbell wrote: On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. +1 , including the IETF consensus call part. I don't understand how IETF consensus is relevant to a non-IETF document. In fact the answer to Jari's question appears to be a matter of logic, not of opinion. The IESG, which acts for the IETF, logically cannot determine anything about the contents of a non-IETF document. So the inclusion of an IESG note can only be a request. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel, I agree that IESG notes should be rare, but primarily because independent stream submissions should be rare :-). Long ago, when I served on the IAB, we grappled with this problem, and failed to find a good solution. Despite what we say about RFC status and origin markings, the public sees RFCs as carrying the imprimatur of the IETF (not just that of the RFC Editor). When Jon Postel was the RFC editor, we were pretty comfortable with his judgement on these matters, this was less of an issue. However, time have changed and I would be happy to see inclusion of an IESG note be mandatory, contrary to historical practice. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote: On 2009-09-01 05:56, Ben Campbell wrote: On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. +1 , including the IETF consensus call part. I don't understand how IETF consensus is relevant to a non-IETF document. Can't the IETF can have a consensus that a non-IETF document relates to other IETF work in some way? In fact the answer to Jari's question appears to be a matter of logic, not of opinion. The IESG, which acts for the IETF, logically cannot determine anything about the contents of a non-IETF document. So the inclusion of an IESG note can only be a request. How would you expect the RFC editor to evaluate such a request? Under what circumstances would it be reasonable to refuse to include it? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On 2009-09-01 13:14, Ben Campbell wrote: On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote: On 2009-09-01 05:56, Ben Campbell wrote: On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote: Yes, I understand, this only applies to the Independent Submission stream. We ask the IESG to review these documents, and that review is technical. I don't think it is appropriate for an editor to make a judgment of whether a technical note is, or is not appropriate to be included in a document. I think the presumption should be that it is appropriate, and the authors have a way to object. While I understand the role of the ISE is somewhat different from the RFC Editor, I understand the role to be primarily editorial and we are not choosing the ISE with regard to their ability to make judgments like whether the IESG note is appropriate or not. I think it would be okay to have the note go through an IETF consensus call. +1 , including the IETF consensus call part. I don't understand how IETF consensus is relevant to a non-IETF document. Can't the IETF can have a consensus that a non-IETF document relates to other IETF work in some way? Well, yes, but that's a decision we have historically chosen to trust the IESG to take. I see no evidence that that has been a problem, and I didn't think Jari was reopening that aspect. In fact the answer to Jari's question appears to be a matter of logic, not of opinion. The IESG, which acts for the IETF, logically cannot determine anything about the contents of a non-IETF document. So the inclusion of an IESG note can only be a request. How would you expect the RFC editor to evaluate such a request? Under what circumstances would it be reasonable to refuse to include it? Well, in the future it will be the Independent Series Editor. I would expect him/her to take such a decision just like an academic journal editor would decide how to deal with a critical review. I'd expect that in the large majority of cases, the ISE would agree to the request, and would only consider refusing it if he/she concluded that the IESG was showing unreasonable bias. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote: [...] +1 , including the IETF consensus call part. I don't understand how IETF consensus is relevant to a non-IETF document. Can't the IETF can have a consensus that a non-IETF document relates to other IETF work in some way? Well, yes, but that's a decision we have historically chosen to trust the IESG to take. I see no evidence that that has been a problem, and I didn't think Jari was reopening that aspect. Ah, sorry, I was agreeing with Brian Rosen statement that a concensus call was okay. I didn't mean (and I doubt he did, but he can speak for himself) that I think we _needed_ one, only that if that were the only way we could make an IESG request binding, then it was okay. If we feel we can trust the IESG on this, I'm okay with it :-) In fact the answer to Jari's question appears to be a matter of logic, not of opinion. The IESG, which acts for the IETF, logically cannot determine anything about the contents of a non-IETF document. So the inclusion of an IESG note can only be a request. How would you expect the RFC editor to evaluate such a request? Under what circumstances would it be reasonable to refuse to include it? Well, in the future it will be the Independent Series Editor. I would expect him/her to take such a decision just like an academic journal editor would decide how to deal with a critical review. I'd expect that in the large majority of cases, the ISE would agree to the request, and would only consider refusing it if he/she concluded that the IESG was showing unreasonable bias. I assume an ISE could also who bias. It seems to me this all converges on deciding who has to appeal in a dispute. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Making the IESG note mandatory, even if that required IETF agreement, would essentially give the IETf veto over the Independent stream. The IESG would simply propose a note so extreme that no author would accept it on their document. Given that I have seen proposed notes almost that bad in the past, I see no reason to believe it will not happen in the future. Unless we wish to gut the Independent Stream of its right and important role of providing critical review of ongoing ideas, I would strongly recommend that the IAB not accept any procedure by which this would occur. Remember, the IETF did not create the Independent Stream. It arguably predates the existence of standards track documents. Yours, Joel Ben Campbell wrote: On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote: [...] +1 , including the IETF consensus call part. I don't understand how IETF consensus is relevant to a non-IETF document. Can't the IETF can have a consensus that a non-IETF document relates to other IETF work in some way? Well, yes, but that's a decision we have historically chosen to trust the IESG to take. I see no evidence that that has been a problem, and I didn't think Jari was reopening that aspect. Ah, sorry, I was agreeing with Brian Rosen statement that a concensus call was okay. I didn't mean (and I doubt he did, but he can speak for himself) that I think we _needed_ one, only that if that were the only way we could make an IESG request binding, then it was okay. If we feel we can trust the IESG on this, I'm okay with it :-) In fact the answer to Jari's question appears to be a matter of logic, not of opinion. The IESG, which acts for the IETF, logically cannot determine anything about the contents of a non-IETF document. So the inclusion of an IESG note can only be a request. How would you expect the RFC editor to evaluate such a request? Under what circumstances would it be reasonable to refuse to include it? Well, in the future it will be the Independent Series Editor. I would expect him/her to take such a decision just like an academic journal editor would decide how to deal with a critical review. I'd expect that in the large majority of cases, the ISE would agree to the request, and would only consider refusing it if he/she concluded that the IESG was showing unreasonable bias. I assume an ISE could also who bias. It seems to me this all converges on deciding who has to appeal in a dispute. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
