Hi Benoit, et al, I couldn't agree more. The IETF has much more exigent issues with respect to YANG models and the attendant protocol infrastructure than whether IANA might go away in the future. Thanks, Acee
On 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" <[email protected] on behalf of [email protected]> wrote: Martin, I'm wonder whether this is really an important optimization, worth changing now, in the hypothetical case that IANA is not called IANA any longer in the future? Right now, "iana" n the YANG module name correctly states what this is about https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml => "maintained by IANA" I agree with Jürgen that documenting this in 6087bis is the right way forward. Regards, Benoit. > Hello > > As part of a recent IESG review (of draft-bfd-yang) a point came up on > the use of "iana" in yang modules' name/namespace/prefix. > This is typically used in the case where the module refers to an IANA > maintained registry. However, the point raised was that the name of > the registry operator might not always be IANA, and that using that > name might not put modules on the most stable deployment footing under > all possible circumstances. > > On top of that, as far as I can tell, the use of "iana" is an > undocumented convention. > > So, I wanted to collect views: > on whether a convention should be documented, > and, with regards to the point raised in IESG, on whether that keyword > should be changed going forward. In that context, what about "reg" > (for registry) or "regop" (for registry operator)? Other proposals are > welcome. > > Thanks > -m > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > . > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
