Kent Watsen <kent+ietf@xxxxxxxxxx> wrote:
>> I believe strongly that the method of referencing the registries that
>> the i2nsf document does is preferable over the method of the dnsop
>> document.
> While this may be true, it would be helpful if you could reply to
> Petr's message [1] in the dnsop thread you started. In particular, if
> IANA itself updates the YANG modules directly, at the same time as
> updating the base registry (i.e., without the initial RFC itself being
> updated), what issues remain?
I think that I'm okay if IANA generated YANG modules from the protocol registries.
That shouldn't be in an RFC though. I don't know how this will work with
systems that generate code from a YANG module, but I know nothing about that usage.
>> https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-10
>>
>> is a document that does nothing other than what you describe as wrong.
> True, and worse, that draft hasn't yet switched the YANG module to
> being a collection of IANA-maintained modules, as has been discussed on
> the list. This change hasn't been made yet only because there is an
> even larger issue (i.e., lack of a universal crypto algorithm type
> registry) that needs to be resolved first.
It just won't happen that way.
>> I haven't been able to convince the authors that this is a bad thing.
> This is an interesting and somewhat overreaching characterization of
> past interactions.
okay :-)
Let me say: "I haven't received communication from the authors about how they feel"
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
