Re: [Last-Call] Last Call: Moving RFC 4491 to Historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Sunday, January 9, 2022 11:46 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:

> On 09-Jan-22 07:11, Salz, Rich wrote:
>>>     Will someone pick up 4491 by mistake? I hugely doubt it
>> 
>>>     I think that only part of this thread is relevant to the
>>>     ISE and the
>>      Independent Submissions Stream. That part is the
>>      progression of draft-deremin-rfc4491-bis, and I am
>>      unchanged in my opinion that that document is ready to
>>      be published as an Informational RFC in the Independent
>>      Stream
>> 
>> As someone who has been involved with implementations of
>> national crypto standards for years (I helped the GOST
>> implementors get re-sync'd with OpenSSL, and played a part in
>> getting SM2/3/4 documented in the IETF and implemented in
>> OpenSSL), I just want to say that it is my view that the
>> views of Adrian quoted above are exactly right.
> 
> Yes, but neither labelling 4491 "Historic" (rather than both
> "Historic" and "Obsoleted By", nor updating RFC 3279, solves
> the problem of how an implementor of RFC 3279 is to find the
> current list of algorithms that are valid/deprecated/forbidden.
> 
> In some ways that is an orthogonal problem, but relying on all
> implementors to be attentive readers of the relevant IETF
> mailing lists is not a solution.
> 
> Within our current practices, RFC3279bis establishing an IANA
> registry of algorithms might be one solution.

Yes.  Or, the more I think about it, the more I like the idea of
an Applicability Statement that could slightly update 3279 (or
be incorporated into an update) and, perhaps in conjunction with
such a registry, start distinguishing between things the IETF
Recommends (endorses, encourages the use of), those about which
we have little opinion but believe the community should have
information about, and those that we have looked at and believe
are obsolescent, dangerous now and going forward, etc.   It
would not be hard to write IANA Considerations or other text for
such a document that would make it easy for any national or
international standard to make it into the registry (we could
decide whether English translation was a requirement) but to
require some sort of IETf action to annotate the registry entry
with a recommendation status) 

And that would get us out of the hole we seem to be digging (and
that you and I have identified in different ways) rather than
digging ourselves in deeper).

   john

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux