[saag] Re: draft update on discussion on crypto practices at IETF

Eliot Lear <[email protected]> Thu, 23 Jan 2025 14:37:19 +0100

Newsgroups	gmane.ietf.saag
Message-ID	<[email protected]>

I think this thread is a bit lost.  This, to me at least, isn't 
necessarily about RFCs but simply what defines a stable reference.  
Also, is the specification pointed to by that stable reference itself 
stable.  There is no current mechanism for an observer to determine that 
a draft is in its terminal state (e.g., no more updates needed).  That's 
where a few of us ended up the last time this debate ran saag into the 
ground. Rather than do all of that over again, I propose that we simply 
state that a stable reference is required, and that either working 
groups or appropriate designated experts may make that determination. 
This leaves things a bit up in the air for now on that one front, but 
lets the rest of the draft proceed without a whole lot of fur flying.

On 23.01.2025 14:13, Carsten Bormann wrote:
> On 2025-01-23, at 13:55, Stephen Farrell<[email protected]> wrote:
>> For the example in question, there's a difference between
>> the perspectives of the sender and recipient of the message
>> though: if the author of the I-D is constantly told "an I-D
>> is sufficient" when that author wants the I-D to become an
>> RFC, the effect is the same as if they'd heard "an RFC MUST
>> NOT be produced.”
> If there was no other reason to produce an RFC than that the code point is not pointing to an RFC as its specification (and there is no other preferential treatment that the registry gives to RFC-allocated code points), that is indeed “an RFC MUST NOT be produced”, according to the general (but registry-unrelated) rule:
>
> An RFC must not be produced for no reason.
> (Vanity alone is not a reason.)
>
> But putting out a point in the sense of having a code point allocated in an I-D creates a formal blockage for its evolution to an RFC: no.
> (It may reduce motivation to do that work, but that is, again, a different issue.  One reason to produce an RFCs may be to document consensus, and it is usually more work to demonstrate consensus than for most registries (*) to allocate a code-point.)
>
> Grüße, Carsten
>
> (*) Those where code-points are not scarce.
> We need terms for these things!
>
> _______________________________________________
> saag mailing list [email protected]
> To unsubscribe send an email [email protected]
>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]

OpenPGP_0x87B66B46D9D27A33.asc (application/pgp-keys, 2.6 KB)

OpenPGP_signature.asc (application/pgp-signature, 495 B)