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

Thanks Eliot,

I agree with a lot of this. This thread is going nowhere. In addition to stable, the reference should be freely available and in English. If more discussion on references is needed it should involve the whole IETF and not just SAAG.
Cheers,
John

From: Eliot Lear <[email protected]>
Date: Thursday, 23 January 2025 at 14:38
To: Carsten Bormann <[email protected]>, Stephen Farrell <[email protected]>
Cc: IETF SAAG <[email protected]>
Subject: [saag] Re: draft update on discussion on crypto practices at IETF

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]><mailto:[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]<mailto:[email protected]>

To unsubscribe send an email to [email protected]<mailto:[email protected]>

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