> 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@xxxxxxx]
> Sent: Friday, August 16, 2013 2:03 PM
> To: Black, David
> Cc: Sam Hartman; housley@xxxxxxxxxxxx; tim.polk@xxxxxxxx; Dacheng Zhang
> (zhangdacheng@xxxxxxxxxx); General Area Review Team (gen-art@xxxxxxxx);
> karp@xxxxxxxx; ietf@xxxxxxxx
> Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
>
> >>>>> "Black," == Black, David <david.black@xxxxxxx> 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.