FWIW, I largely agree with the points Rob made below. Also, on the topic of normative references, another aspect of the discussion is whether a reference is being provided, say "as an example" of one way one might do something, or whether it is being provided as _THE_ way of doing something. The former does not need to be a normatie reference, while the latter more likely is.
I assume that some of the specific IDs being mentioned are really an example of one general way to do it, but not necessary the _only_ way. Or the idea is so obvious, that a one-paragraph (or sentence?) description is enough for the reader to understand the basic approach (i.e, the type of understanding needed for this docuenmt). E.g., for something like "put the address of a DNS server into an RA", I doubt one needs to go and read a spec with the details to understand the general idea enough to talk about its pros and cons. So, to me, it's not at all clear that some of the related IDs need to be cited normatively. Indeed, one woudl hope that this document is reasonably self-contained. Thomas Rob Austein <[EMAIL PROTECTED]> writes: > At Thu, 24 Jun 2004 07:50:44 -0700, David Meyer wrote: > > > > On Thu, Jun 24, 2004 at 03:10:29PM +0900, Masataka Ohta wrote: > > >> ... > > >> However, are there any possibility that the ID become an RFC? > > >> > > >> I think it does not have to be. > > > > Seems to me that we should publish it as informational to > > capture the work that has been done. In any event, we > > should adhere to the publication standards. > Disclaimer: our area directors asked the WG to take this approach as a > way of wrapping up our work on this topic, and they can of course > speak for themselves. The following is just my opinion based on my > understanding of their thinking. > I'm pretty sure that a large part of the point of the exercise is to > publish the document in permanent form. We were not able to reach > consensus on a way forward, so we're trying to write down what we've > learned about each of the several options during the course of years > of nonterminating discussion, as fairly as possible given that we > don't have consensus on the right approach. > A well-written document of this type serves at least two purposes: > a) It's a briefing document for anybody (eg, the IESG) who might need > to make informed decisions in this space at some time in the > future. > b) It offers a relatively constructive way of breaking out of the > endless discussion loop, by providing a relatively objective > criterion by which we (or somebody) can determine whether a new > discussion on this topic is genuinely new or is just the same old > nonterminating discussion yet again. In the latter case, a good > document will at least allow us (or somebody) to cut to the chase > and ask whether anything has changed since the last time around, > rather than having to reevolve the whole line of argument, bring a > new group of participants up to speed, and so forth. > One way of looking at this is that, when an argument can't be resolved > and the participants need to resign themselves to agreeing to > disagree, it is sometimes useful to spell out in some detail precisely > what it is on which they have agreed to disagree. :) > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
