On Tue, Apr 18, 2017 at 9:06 PM, Mirja Kuehlewind (IETF) <[email protected]> wrote: > One more point: I’ve noticed your point that at some point people just want > to get their document through the process. I’m aware of this ‚problem‘. On > the one hand, I think that actually good: I’m happy if people are sure about > the content and see no problem in letting the IESG figure out the actual less > important questions about processing. On the other hand, I agree that we > should of course try to avoid any kind of confusion people may have. However, > in this case I (still) don’t understand well where this confusion is coming > from and as such, at least I, don’t know how to clarify. I’m pretty sure we > will further discuss this at the up-coming retreat though.
Yes, I agree that we should discuss these types of documents and our published guidance on them to assist working groups at the retreat. Adrian raised some important points I would bet many in the IESG didn't read since this was just on the thread for your ballot. It would be more fair to WGs if we could update the guidance. If there will be a number of abstains on this type of document, then informational is the only way they will get published. Adrian raised a number of very good points that should get considered prior to any such update IMO. I've always been fine with supporting what the WG decides is best for them to accomplish their work goals, so I do support publishing support documents. Thank you both for the discussion. > > Mirja > > >> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) <[email protected]>: >> >> Hi Adrian, >> >> again I, as AD and also as chair and contributor, didn’t notice this to be >> such a big problem. Yes there are over and over again discussions about what >> the right intented status is but often these are between standards track and >> experimental or BCP and informational… >> >> Anyway to your questions below. >> >>> Am 15.04.2017 um 12:49 schrieb Adrian Farrel <[email protected]>: >>> >>> 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? >> >> Often terminology does not need a normative reference; it’s rather a "if you >> are not sure, please see these documents for better definitions". So the >> approach that is often taken is, to list the terms and give an informational >> reference to the document where they are specified. I think that’s a good >> approach. >> >> If that’s not good enough, you may also copy all or some of the terminology >> section (usually less preferred by at least this IESG) into the protocol >> spec itself or, of course, it still is possible to have a down-ref if that >> seems useful in a specific case. >> >>> >>> 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. >> >> Architecture documents may be different and that's one of the cases where >> the situation may be sometimes less clear. However, there are also protocols >> that can be correctly implemented without understanding all architectural >> consideration that lead to the final design. My general advise would be to >> have architecture documents as informational and potentially briefly >> summarize anything that may be important to know to understand the protocol >> spec in the protocol spec itself. However, this might be different from case >> to case. >> >>> >>> 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? >> >> See above; keep the reference informational and briefly summarize if really >> needed. >> >> Mirja >> >> >> >> > -- Best regards, Kathleen _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
