Subject: [netmod] "iana" in yang modules' name/namespace/prefix

From: Martin Vigoureux <[email-masked]>
Date: Fri, 20 Jul 2018 15:45:47 +0200

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 20 Jul 2018 14:01:05 +0000

Hi Martin, 
I would prefer not using "reg" since it will always be an abbreviation for a machine language register to me. I'd favor using "registry" in the module name and the more cryptic "reg" in the module prefix. 
Thanks,
Acee 

On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

    Hello

    
    
    Thanks
    -m
    
    _______________________________________________
    netmod mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jul 2018 16:40:06 +0200

On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
 
> 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.
> 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.
> 

iana- has the advantage that everybody knows which registry is meant.
Using registry- is perhaps more flexible in case IANA registry gets
renamed but it leaves is much more open where the module is
maintained. The first part of a module name is supposed to identify an
organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
says:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules.

Concerning documentation, perhaps we could change the above to this:

   It is suggested that a stable prefix be selected representing the
   entire organization.  All normative YANG modules published by the
   IETF MUST begin with the prefix "ietf-".  Another standards
   organization, such as the IEEE, might use the prefix "ieee-" for all
   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
   begin with the prefix "iana-".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 20 Jul 2018 15:52:31 -0400

Sent from my iPhone

> On Jul 20, 2018, at 10:40 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

+1

I agree that the prefix suggests the organization responsible for maintaining the model, something reg- or registry- does not. Two more examples that already exist are mef- and etsi-. I understand there is the possibility that that prefix changes, but we then pick a new prefix, if we know what it might be.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 22 Jul 2018 09:54:20 -0400

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.
> 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.
>
> should be changed going forward. In that context, what about "reg" 
> (for registry) or "regop" (for registry operator)? Other proposals are 
> welcome.
>
> Thanks
> -m
>
> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 22 Jul 2018 14:20:14 +0000

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-masked] on behalf of bclaise=[email-masked]> wrote:

    Martin,

    Regards, Benoit.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 22 Jul 2018 08:38:52 -0700

Hi,

A bit ironic...
We should change the name of an acronym that has been in place since 1988
in order to guard against instability.

Andy

On Sun, Jul 22, 2018 at 7:20 AM, Acee Lindem (acee) <
acee=[email-masked]> wrote:

> 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-masked] on behalf of bclaise=[email-masked]>
> wrote:
>
>     Martin,
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 22 Jul 2018 11:50:38 -0700

Same here, let’s focus on immediate problems, there are plenty of those...

Regards,
Jeff

> On Jul 22, 2018, at 07:20, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> Hi Benoit, et al,