Michael Richardson <mcr+ietf@xxxxxxxxxxxx> writes:
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.
As Petr pointed out in his DNSOP mailing list message, the purpose
of such an RFC is to provide a starting revision of the YANG
module, plus instructions for IANA about how to reflect the
registry changes in the module.
The experience with other similar YANG modules indicates that the
process can actually work, see for example
https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml
For users of such modules, it is important to grab the latest
revision from IANA rather than use the initial revision that
appeared in the RFC. Perhaps this could be more strongly
emphasized in the kick-off RFCs.
While we can think about other procedures and mechanisms, I'd
suggest that we stick to the current procedure, until something
better is available.
Lada
>> 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 [
--
Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
