On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF <[email protected]> wrote: > Hi, Kathleen, > > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty > <[email protected]> wrote: >> >> 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. > > > I agree. Am I adding this to > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you?
Go for it! Do you want to work together on this? I think it's important to capture Adrian's input for this discussion. Thank you, Kathleen > > Spencer > >> >> 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 >> > -- Best regards, Kathleen _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
