--On Monday, March 25, 2024 15:53 -0700 Randy Presuhn <randy_presuhn@xxxxxxxxxxxxxxxxxxx> wrote: > Hi - > > On 2024-03-25 3:23 PM, John C Klensin wrote: >> >> >> --On Monday, March 25, 2024 14:02 -0700 Randy Presuhn >> <randy_presuhn@xxxxxxxxxxxxxxxxxxx> wrote: >> >>> Hi - >>> >>> On 2024-03-25 1:51 PM, S Moonesamy wrote: >>>> Hi Randy, >>>> At 01:19 PM 25-03-2024, Randy Presuhn wrote: >>>>> What is the conflict you see? The text you cited seems to >>>>> me to present no conflict. A posted Internet-Draft >>>>> certainly seems to fit within the realm of "a document >>>>> published outside of the RFC path, including informal >>>>> documentation." >>>> >>>> This takes the discussion to what Mike pointed out at >>>> https://mailarchive.ietf.org/arch/msg/ietf/FqmdAQY_C7jOGh_K >>>> V- HkC5MP7Xs >>>> >>>> I also mentioned "formal public specification". If I am >>>> not mistaken, that would include standards from other >>>> bodies or national standards for which a code point is >>>> required. >>> >>> If it's ok to cite an I-D as "work in progress," how is that >>> different from "informal documentation" in any meaningful >>> way? >> >> If it is being used as part of the definition for an entry in >> an IANA registry, that makes it "reference material", not >> just a work in progress. In addition, if it were actually a >> work in progress, that would make it unsuitable for part of >> the definition for a registry entry because it would be an odd >> indeed to have a registration of a moving target rather than a >> stable definition. >> >> I think that may be just a different way to express Mike's >> concern. > > The same criticisms might be leveled against any sort of > "informal > documentation." The question really needs to be whether the > document has sufficient information to support the > registration - > and that, in turn, depends on the uses envisioned for that > registry > at the time it was carved out, not every possible tweak that > the > document might subsequently experience. I think concerns about > stability are well-founded, but obsessing about them opens a > massive > can of worms. Think back to the various incarnations of ASN.1 > since > the 1980s, or even the question of what "SNMP" has meant at > various > points in time. Randy, Yes, but... (1) Your examples actually support my concerns. If I am using "ASN.1" or "SNMP" in a context where the incarnation makes a difference, good practice is to attach a note or citation of some sort that tells the reader what I'm talking about. I don't just leave that to the reader's imagination. For the I-D case, I'd be far less concerned about a reference in an IANA registry to draft-ietf-foo-bar-13 and an associated date than to draft-ietf-foo-bar. The former is a specific reference; the latter a moving target with no information about which version is being referred to and no controls over the changes that might be made (even fewer controls than applied to SNMP or ASN.1). (2) Others have pointed this out, but, if we are going to reference an I-D (even with a version number), we assume some obligation to be sure that document is available for the very long term. If someone references some other sort of informal document, they should take responsibility for ensuring its availability. If they fail and the document disappears, that would be unfortunate, but it seems to me that, for I-Ds and and an IETF-maintained repository, we have at least a moral responsibility to keep documents that are referenced as normative around and, in the process, to set a good example. (3) And, while it is not strictly necessary (and I agree with your comment about obsessing over details of stability), we may be in need of some text that distinguishes between I-Ds of a given name (independent of a sequence number) as being a collection that together constitute a "work in progress" and any particular numbered draft, which is a static snapshot of that evolving work but that does not, itself, evolve or change. In a way, that may make draft-ietf-foo-bar-13 a more stable reference, with less hair-splitting, than some current discussions propose to make RFCs. john
