Re: [saag] SSH & Ntruprime

[John C Klensin <[e-mail]>]

--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