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