[saag] Re: [Ext] draft-paulwh-crypto-components-02

On Feb 11, 2025, at 14:15, Stephen Farrell <[email protected]> wrote:
> 
> 
> Hiya,
> 
> On 11/02/2025 21:33, Paul Hoffman wrote:
>> More reviews are welcome.
> 
> I think section 3.4 needs a bit more work.
> 
> The IRTF (mostly CFRG) fairly frequently creates registries
> which is sorta mentioned here, but also ignored some, e.g. in
> the first para, 2nd sentence, which is a bit misleading given
> that that RG does not need IETF consensus.
> 
> I guess CFRG could publish an RFC with a registry that requires
> an RFC, which isn't really covered here. (Not sure if it's worth
> a mention.) And of course, while it'd be pretty odd, CFRG could
> create an initially empty registry that calls for IETF consensus
> for adding entries. (Or maybe even not initially empty?)
> 
> I don't think it'd be worthwhile trying to figure out how to
> "govern" creation of IANA registries by CFRG along the lines
> above, but I do think it'd be good to spend time to figure out
> how to hand-over work from CFRG to the IETF, when that's what
> really should happen. RFC9180 is the main example I have in
> mind but there're probably more cases, where it was a fine
> plan to do initial work in CFRG but where subsequently moving
> maintenance to the IETF would be an even better plan. The reason
> to mention this is that if such an improved understanding between
> the IETF SEC area and CFRG could be reached, then I figure that
> would result in changes to this text. (And well, it's also a
> thing that's overdue, given the workload and latency involved
> in CFRG work, which isn't really conducive to maintenance
> activities.)

Good call. We'll make a much better differentiation about the CFRG and standards status.

> As a near-nit: the new bit of text saying IETF consensus is
> good for 'anything other than "MAY"' needs to be reworded - the
> relevant TLS registries have Y/N values. SSH does have a column
> with MAY or SHOULD or MUST values, which is currently a thing
> generating debate so I'm not sure adding that now is so good an
> idea, but I'm not objecting. (FWIW, while I don't agree with the
> 'anything other than MAY' recommendation myself, the surrounding
> text clarifying that everything here can and likely will see
> relatively common exceptions, makes that kinda harmless, so it's
> ok, even if not what I'd write.)

Sorry, yes. We were thinking about the way that DNSSEC is going with their update, and didn't think widely enough. Will fix.

--Paul Hoffman

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