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
