Re: [saag] SSH & Ntruprime

[Randy Presuhn <[e-mail]>]

Hi -

(top-posting)
I think John and I are in close to violent agreement.

The devil being in the details, the question is whether
any change is needed to current boilerplate / process /
conventions (e.g. referencing specific versions of I-Ds,
just as in referencing specific versions of standards or
other documents when necessary) or whether this can be left
to the good judgement of authors / editors / working groups.
I'm inclined toward the latter, as what we have seems to
already work well enough.

Randy

On 2024-03-25 9:10 PM, John C Klensin wrote:
> 
> 
> --On Monday, March 25, 2024 15:53 -0700 Randy Presuhn
> <[e-mail]> wrote:
> 
>> Hi -
>>
>> On 2024-03-25 3:23 PM, John C Klensin wrote:
>>>
>>>
>>> --On Monday, March 25, 2024 14:02 -0700 Randy Presuhn
>>> <[e-mail]> 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
> 
>