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? 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 > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
