This is not my circus, but on one point ... On Apr 15, 2017 05:49, "Adrian Farrel" <[email protected]> wrote:
Hello Mirja, Thanks for continuing to discuss this issue. > 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. The IESG needs to be aware of a persistent problem: by this stage in the publication process most authors will do whatever it takes to get the document published. They are not going to dig in their heals over "editorial matters" and will simply roll over. You are, therefore, getting false data. The situation is made "worse" by the fact that by the time a document reaches the IESG, the discussion has been had - with the chairs, who have good experience of what is necessary to get through the IESG) - with the responsible AD (who has that experience and also their own views) > 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. Surely. I think it would be very helpful for the IESG to consider the document series again and to indicate clearly indicate how an author determines whether the document they are writing is Informational or Standards Track. > 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. So let's assume we have a terminology document in our hands. Clearly (?) you can't use terms from that document without a reference to it. Is that reference normative or not? Probably it is normative because how can the reader of a protocol spec know what is being discussed if they don't know the terms? Now more to an architecture document. This document describes the components and interfaces. It indicates what the senders and receivers of a protocol message are and what they are doing. Maybe in a very dry protocol spec you can avoid making a reference to the architecture normative, but probably not. And what about a problem statement document that introduces terms and architecture? Isn't that document going to need to be referenced, and because the protocol specs rely on those terms and that architecture, isn't that reference normative? [Please note that I do not personally make such claims for the document in hand, but I believe the authors and WG do make those claims.] > 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. Actually I agree. BUT that means that the work on downward references really needs to be sorted out, made clearer, and made easier. Essentially, we could dispense with this discussion if we could stop it being any type of issue to have a normative reference to an Informational RFC. So, here's where I'm getting stuck. Standards-track and BCP drafts require 2/3rds of the IESG to ballot Yes or No Objection (with no Discusses), while Informational, Experimental, and Historic drafts require only one Yes (and no Discusses). All this, per https://www.ietf.org/iesg/voting-procedures.html. So my question is, if a terminology or architecture draft is going to be foundational for Standards-track or BCP drafts, is it OK that the foundational draft requires less review than the drafts that are building on it? If that's not a problem, with some plausible reasoning why not(*), I'd be fine with allowing Normative references to Informational RFCs, with no special attention. (*) I'm not suggesting this is plausible reasoning, but it's worth noting that most of the Informational documents we process are balloted by more than half the IESG, even though one Yes is sufficient, and most go though reviews from multiple review teams before they appear on a telechat agenda. So maybe this is a distinction without a difference, and that is sufficient to justify allowing Normative references to Informational RFCs. It's also worth noting that working group charters also require only one Yes (and no Blocks), and one might think charters are at least as foundational as terminology or architecture drafts. If those aren't a good enough alibis, maybe someone could come up with another one ;-) Spencer > 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! I should point you at https://www.ietf.org/iesg/stat ement/normative-informative.html This says that | Normative references specify documents that must be read to understand or | implement the technology in the new RFC, or whose technology must be | present for the technology in the new RFC to work. The crunch is "understand the technology". That makes the line hard to draw. > > 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. OK. We are both taking the same approach :-) But I am wondering (out loud) whether we could do better by pushing the information that feeds the final decision down the stack a little. Why should we be "guessing" and getting the answer from our superiors? Why should we not know how to make the right decision? > 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. Well, I think I addressed your second part above. As to "should *this* document be one thing or another" I suspect no-one responsible for the production actually cares. They simply want the document published. But they are also wary of a road crash later. So what I am doing (in case it was not obvious) is gathering a paper trail that will allow the chairs to say to a future IESG, "Tough! This is what we were told to do and so the [future] document cannot be held up by this situation." Of course, I'd be happy to not have to do this on a document-by-document basis. So some clearer direction from the IESG would always be welcome. Thanks, Adrian
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
