Hi Adrian, first of all I have to say that deciding between standards track and informational did not occur to me as persistent problem. I believe there was only one other case in the last year (that was less clear than this case), and maybe one more case where the IESG decided to change from information to standards tracks. Both cases were simple to handle with not much discussion and were both less clear cases than this one.
Regarding the IESG statement, for me it was an implicit assumption that these documents are informational anyway. I guess we could spell this out if that helps. See more comments inline. > Am 12.04.2017 um 14:03 schrieb Adrian Farrel <[email protected]>: > > Thanks For the pointer, Alissa. I think I was aware of this IESG statement > and I believe it was factored into the working group's discussions (per its > charter milestone) of which documents to pursue to publication and which not. > > But, as I believe Kathleen has just noted, this statement does not comment on > the positioning on so-called support documents as Informative or Normative. > This is the first point in Mirja's Discuss and the question I was asking. > > A lot of the issue comes down to how the RFC Editor defines a Normative > reference, but maybe some of it resolves to the IESG's own definitions of > downward references. Consider, if you will, the most extreme case which is a > set of requirements. Such documents (often using 2119 language) do not > contain protocol specifications and are not what you would normally expect to > see end up as an Internet Standard. But (clearly?) you will want to reference > the requirements as part of the protocol specification that follows. So what I really don’t understand is why you need to refer these requirements or other support documents normatively. You can alway reference them informatively and I would assume that’s fine. A normative reference means, you have to read those documents as well to be able understand the spec/implement it correctly. I don’t think any background information and motivation or reasoning falls into that category. Further the status of a document should foremost be decided based on its content and not on the question how it could or could not be referenced in future. I know that these points are sometimes part of the discussion but usually for documents where there are also other reasons to maybe have it as standards track. > The question is: when stating that the protocol widget is shaped a particular > way in order to satisfy a particular requirement, do you need to make > normative or informative reference to that requirement, and so should the > reference be Standards Track or downwards-referenced Informational. Again informative references are fine! > > (Some history that no longer applies... Once upon a time the MoU with the > ITU-T stated that they could only reference an RFC on the Standards Track. > This meant that, for example, to get them to develop a protocol spec that was > based on IETF requirements it was necessary to publish the requirements in a > Standards Track RFC. We fixed this by re-writing the MoU and this particular > shard of the problem has gone way.) Here the right solution is (which I believe was done) to explain to an informational document is an as stable reference as the standards track and can be referred without concerns, and not changing the status. > > Why is this question important? > The working groups spend a lot of cycles trying to decide what track to put > documents on. Cycles cost money and ruin lives. My approach now is to have a > quick guess and punt to the IESG. > But it is apparent that the IESG is also burning cycles. > Maybe a clear directive would allow everyone to get on with their lives and > spend time writing code. Again, I wasn’t aware of this kind of confusion. Yes, there are a lot of discussions about the right status but there is also existing documentation about what the different cases mean. For some document it’s sometimes also not that clear but usually my advise as AD is to make some choice and then wait for further feedback in the IESG evaluation and IETF last call. However, in your case, it’s actually very clear to me that this document must be informational and as I said in my discuss I really don’t even see the point about future references because informative references are fine anyway. > > > [And a side comment on the IESG statement and subsequent Abstains. If the > so-called support documents receive no wider review than within the WG, and > if the subsequent protocol specs then attract review comments along the lines > of "why are you supporting this function?" or even " there is absolutely no > need for this function" then we have set ourselves up for confrontation with > the WG which will feel that it has done good work based on its own view of > the use cases or requirements, and the reviewer who did not comment at the > right time in the process. Who knows whether this will happen and how it will > be resolved?] So I think this can happen no matter if you have published any support document or not because very often these kind of document are less well reviewed in IETF last call. However, the questions you raise above are explicitly mentioned as not beginning discuss-worthy in https://www.ietf.org/iesg/statement/discuss-criteria.html so that should not hold up publication anyway. Also it is fully okay to integrate some background information on requirements or use case in the appendix of the actual protocol spec, as mentioned in the IESG statement. If the wg feels that useful, that can be done. Otherwise sneaking a requirements document through the process to have a handle later to undermine some discussion, seems also just not the right thing to do. I know this is phrased a little to exaggerated but my point is, while I really, really know that discussion can be very length and annoying in the IETF, usually there is a valid core that is worth having the discussion when it comes up. Mirja > > Ciao, > Adrian > > From: Alissa Cooper [mailto:[email protected]] > Sent: 11 April 2017 19:51 > To: [email protected] > Cc: Mirja Kühlewind; IESG; [email protected]; > [email protected]; [email protected] > Subject: Re: Mirja Kühlewind's Discuss on > draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) > > Hi Adrian, > >> On Apr 11, 2017, at 2:34 PM, Adrian Farrel <[email protected]> wrote: >> >> Thanks Mirja, >> I think it is best that you discuss this topic with the rest of the IESG and >> then we can be told what to do. >> >> (FWIW, I heard this conversation about 6 times in the 6 years I was on the >> IESG and the opinion swung back and forth. The IESG I was on never managed >> to get a clear position set down to guide the authors of future documents. >> Perhaps you could write one?) > > We did, last year: > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > > Alissa > > > > Cheers, > Adrian > > > -----Original Message----- > From: Mirja Kühlewind [mailto:[email protected]] > Sent: 11 April 2017 19:26 > To: The IESG > Cc: [email protected]; Adrian Farrel; i2nsf- > [email protected]; [email protected]; [email protected] > Subject: Mirja Kühlewind's Discuss on > draft-ietf-i2nsf-problem-and-use-cases-12: > (with DISCUSS and COMMENT) > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document should be informational. I don't see any reason that this > document must be cited normatively by all following document of this wg > (as indicated in the shepherd write-up) and even if so that does not > justify publication as Standards track if the information in the document > is only informational. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As soon as my discuss is resolved I will change to 'Abstain' as I don't > see value in the publication of this document. I can see that this > document was useful for discussion in the working group but I don't know > why it needs to be published as RFC. Also there is quite some redundancy > everywhere in the document aa well as between the problem statement and > use case part. Spelling out requirements for the protocol design based on > the analysis of these problems and use cases (which was already a bit > attempted from time to time in the doc) would have been more useful but > does still not have an archivable value that justifies publication as RFC > in the IETF stream (indicating IETF consensus). _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
