I'm somewhat uncomfortable with that sort of bar for IANA registries in
general, although I have supported it from time to time. (My discomfort
with this has grown significantly since my time as an AD). I do not
support that sort of bar for this registry.
I think we understand each other, but disagree.
I believe that is the case (we understand each other, but disagree).
The question now is whether you can gain sufficient support to show
rough consensus for a change in the document or to show that while there
was rough consensus behind the document in the KARP WG, there's a lack
of consensus on handling this issue between KARP and some other
significant segment of the IETF like the security area.
I will simply point to RFC 3365 ("Strong Security Requirements for
Internet Engineering Task Force Standard Protocols") and suggest that it
is relevant to determining what the registration procedure should be
based on how this registry is likely to be used and as an example of
reasons for the IESG to not follow the rough consensus of a WG.
I believe that a discussion of how the registry is likely to be used
in practice would be productive, although I am concerned about statements
that weak password mechanisms are intended to be in scope, even though
the draft (as I read it) excludes them, starting with the draft's title.
Thanks,
--David
-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: Friday, August 16, 2013 2:03 PM
To: Black, David
Cc: Sam Hartman; housley(_at_)vigilsec(_dot_)com;
tim(_dot_)polk(_at_)nist(_dot_)gov; Dacheng Zhang
(zhangdacheng(_at_)huawei(_dot_)com); General Area Review Team
(gen-art(_at_)ietf(_dot_)org);
karp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
"Black," == Black, David <david(_dot_)black(_at_)emc(_dot_)com> writes:
Black,> done. IMHO, we really should be setting a bar that says
Black,> that this sort of IETF imprimatur of approval of a crypto
Black,> algorithm actually means something.
Something got manged there.
I agree that publishing a standards-track document should endorce the
algorithm in question.
I'm somewhat uncomfortable with that sort of bar for IANA registries in
general, although I have supported it from time to time. (My discomfort
with this has grown significantly since my time as an AD). I do not
support that sort of bar for this registry.
I think we understand each other, but disagree.
The question now is whether you can gain sufficient support to show
rough consensus for a change in the document or to show that while there
was rough consensus behind the document in the KARP WG, there's a lack
of consensus on handling this issue between KARP and some other
significant segment of the IETF like the security area.