Subject: [netmod] 6087bis namespace recommendations

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Jan 2016 10:15:26 +0100 (CET)

Hi,

Currently, 6087bis says that standards-track, published and
unpublished modules SHOULD use the URN prefix
"urn:ietf:params:xml:ns:yang:".

There are two issues with this:

  1.  We already publish experimental modules w/ this prefix.
      (ietf-netconf-time and ietf-complex-types).

      So 6087bis should remove "standards track" from this
      recommendation.

  2.  There was some discussion about recommending a different URN
      prefix for unpublished modules (i.e., modules in Internet
      Drafts).

      Should 6087bis recommend some special urn prefix for drafts,
      with a note to the RFC editor to change the namespace once it
      has been registered with IANA?

And another issue.  6087bis also has this:

OLD: 

  The following examples are for non-Standards-Track modules.
  The domain "example.com" SHOULD be used in all namespace URIs
  for example modules.

      http://example.com/ns/example-interfaces

      http://example.com/ns/example-system

First of all, the sentence about non-Standards-Track modules is
confusing.  Second, since the publication of RFC 6087, RFC 6963 has
been published, which defines a URN for examples.  I suggest we update
6087bis like this:

NEW:

  Example modules in all types of documents SHOULD use a namespace
  with either the example URN [RFC 6963] or the domain "example.com".
  For example:

      urn:example:interfaces

      http://example.com/ns/example-system

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2016 10:28:31 +0100

>       So 6087bis should remove "standards track" from this

Well, the current text is silent about non-standards-track modules, so
there is not really a conflict. While searching through 6087, I think
it is more important to clarify the usage of 'publish'. One solution
would be to use 'publishing' when we talk about the publication of
RFCs and to use 'posting' when we talk about the posting of an
Internet-Draft. But yes, this is a different can of worms.

>       has been registered with IANA?

Do we have evidence that having such a rule makes the Internet work
better?

>       http://example.com/ns/example-system

Adopting urn:example makes sense to me.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Jan 2016 11:21:43 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> Well, the current text is silent about non-standards-track modules

No, it says:

  Note that a different URN prefix string SHOULD be used for
  non-Standards-Track modules.

> so

I don't know, but apparently there can be confusion when an extracted
module from a draft is passed around.

What can we learn from the SNMP experience where the OID assignement
is done by IANA - good or bad?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2016 11:48:55 +0100

>   non-Standards-Track modules.

Well, yes, this is likely in need of a fix then.
 
> is done by IANA - good or bad?

With MIB modules, the module OID is assigned by IANA and we usually
have a placeholder (which makes the module not compile). With SNMP, we
converged to register the majority of modules below mib-2 and hence if
people pick numbers, they have a high potential for collision. With
NETCONF namespaces, the collision probability is rather low. The other
aspect is that an official assignment happens late during the process,
e.g., as part of the RFC publication process and there might be early
implementations that use a 'speculative' namespace value. In a perfect
world, we should likely use a different prefix while the module is
under development and then let IANA have the final say on the official
prefix. And if Lada is really concerned about problems caused if I-D
implementations, we could do lets say a series of

  urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
  ...
  urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20

in I-Ds and then the RFC editor finally changes things to

  urn:ietf:params:xml:ns:yang:ietf-routing

if IANA agrees to allocate this URN to the module. Of course, this
means more work for the editors involved and so far our lax handling
of this issue seems to have worked. (But so it did for MIB modules
until problems started to show up.)

/js

PS: Note that JSON encoding uses the module name and not the namespace
    and hence even if we do the above, module names in JSON won't
    signal the difference between I-D and published RFC versions of a
    module. So to be really fool proof one would have to change the
    module name also with every posted I-D. The question is at which
    point in time bureaucracy hampers productivity and perhaps what we
    do today is not perfect but a reasonable trade-off.

PS: Another option could be a YANG keyword that declares the status of
    a module, 'draft', 'published', 'experimental', 'example',
    'obsolete' and then the RFC editor would only have to toggle this
    value and tools could still distinguish the different kinds of
    YANG modules.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 11 Jan 2016 16:12:35 -0800

> On Jan 11, 2016, at 1:15 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

True.

>      So 6087bis should remove "standards track" from this

Yes. 

>      has been registered with IANA?

I am inclined to let the urn prefixes be what they will be once the document gets adopted as an RFC. There are plenty of tools and work today that extracts the module and uses it as is on an experimental basis. Having to change them every time the drafts changes or modify existing code once the module it uses becomes RFC is painful. Besides, the chances of conflict are low with the URN namespaces, so why make the process onerous.

>      http://example.com/ns/example-system <http://example.com/ns/example-system>

Agree.

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

Mahesh Jethanandani
[email-masked]

---

From: t.petch <[email-masked]>
Date: Thu, 14 Jan 2016 17:32:05 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 11, 2016 10:48 AM

> > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:

<snip>
> until problems started to show up.)

I think that, as has already been said, the much larger namespace for
urn compared to mib-2 makes collisions less likely.

I have seen collisions in SMI and they were costly to fix, one
manufacturer or the other had to agree to back off and rework their
product.

What SMI did get superbly right was setting up a branch of the tree
(.private.enterprises.), for organisations that wanted to get involved,
to register for a number, FCFS (and a process that did not involve the
costs of the IEEE equivalent:-) under which they could create their own
modules.  On a typical network box, the amount of data under that branch
would exceed, sometimes by an order of magnitude, the amount of data
under mib-2.

Originally, the intention with SMI was that development would take place
under a different branch and be converted to the allocated number at the
end, but making changes when everything was tested and working was not
too popular so that fell by the wayside.

Finally, the fashion with YANG seems to be to carve up a piece of work
into a number of (sub)modules, so there are a number of related names
which again may reflect the convenience of developers rather than
users; and the relationship may or may not be apparent from the chosen
names.   We could offer guidance here

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jan 2016 09:54:43 -0800

> names.   We could offer guidance here
I like the idea of adding DRAFT to the end of the namespace identifier
I would prefer not to put revision identifiers in the namespace.

Internet-Draft publication:

    urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT

RFC publication

I never liked the SMIv2 practice of putting XXX in the MIB module.
It means that no MIB module extracted from an I-D can be compiled without
editing it. There was never any guidance offered (over 25 years) what number
somebody should pick when changing XXX so the module will compile.
This is what led to all the problems.

Tom Petch
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jan 2016 12:39:16 +0100

>     urn:ietf:params:xml:ns:yang:ietf-routing

Does this solve any practical problem? Modules are imported based on
the module name and revision. On the other hand, it does create new problems:
namespace URIs and their mappings to prefixes may be spread in many
places in the code, and these would have to be manually edited after an
I-D -> RFC transition.

It would IMO be much better to use revision numbers rather than dates,
and adopt a convention, e.g., that modules in the I-D stage have
revisions 0.x that get bumped with each new revision of the I-D.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jan 2016 12:49:24 +0100

> revisions 0.x that get bumped with each new revision of the I-D.

Lada, this is not how our current YANG 1.0 versioning and revision
rules work and we are not going to change them in YANG 1.1 either.
The rules we have do make a distinction between published modules and
modules that are unpublished.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jan 2016 12:55:36 +0100

> On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I am not proposing it. The problem I'd like to get solved is proper module revisioning already at the I-D stage so that implementations be able to distinguish one revision from another. Appending DRAFT to the namespace URI doesn't help anything.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2016 06:10:03 -0800

On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >
> I am not proposing it. The problem I'd like to get solved is proper module
> revisioning already at the I-D stage so that implementations be able to
> distinguish one revision from another. Appending DRAFT to the namespace URI
> doesn't help anything.
>
>

Changing the module name constantly does not help.
It would be better to just keep using revision dates.

Lada

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2016 06:16:02 -0800

> places in the code, and these would have to be manually edited after an

This is an implementation detail.
Our code uses a namespace registry and does not spread out
hard-wired string comparisons in the code.

But it is OK it we do nothing about this issue other than make
sure the RFC version has a different revision date than any of the I-D
versions.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jan 2016 15:19:06 +0100

> On 15 Jan 2016, at 15:10, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

Some I-Ds don't do even that, for example acl-model uses the same revision date in subsequent I-D revisions. I checked that this actually violates a MUST in RFC 6087.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jan 2016 15:29:39 +0100

> On 15 Jan 2016, at 15:16, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> sure the RFC version has a different revision date than any of the I-D versions.

Agreed, and also each I-D revision should bump the revision date of all its modules. If YANG modules are verified as a part of idnits, then this should also be checked.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2016 06:49:19 -0800

On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka <[email-masked]> wrote:

> > I am not proposing it. The problem I'd like to get solved is proper
> module revisioning already at the I-D stage so that implementations be able
> to distinguish one revision from another. Appending DRAFT to the namespace
> URI doesn't help anything.
> >
> >
> >
> Some I-Ds don't do even that, for example acl-model uses the same revision
> date in subsequent I-D revisions. I checked that this actually violates a
> MUST in RFC 6087.
>
>

If the YANG module does not change from one I-D to the next,
then the revision date does not need to change.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Jan 2016 16:20:10 +0100

> On 15 Jan 2016, at 15:49, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

6087(bis) says:

   It is acceptable to reuse the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.

I think it is a good idea.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2016 15:38:00 +0000

> I think it is a good idea.
It also think that it is a good idea.

Since an ID is effectively superseded by any new versions, I think that 
it is useful if a module defined in an ID has a revision date that 
matches the published ID, and also a reference back to the ID version 
that defines it.  At least if someone ends up implementing that module 
they can check its provenance.  Both of these properties would also be 
verifiable by idnits.

Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2016 09:51:35 -0800

On Fri, Jan 15, 2016 at 7:38 AM, Robert Wilton <[email-masked]> wrote:

>>> Some I-Ds don't do even that, for example acl-model uses the same
>>> revision date in subsequent I-D revisions. I checked that this actually
>>> violates a MUST in RFC 6087.
>>>
>>>
>>>
> Since an ID is effectively superseded by any new versions, I think that it
> is useful if a module defined in an ID has a revision date that matches the
> published ID, and also a reference back to the ID version that defines it.
> At least if someone ends up implementing that module they can check its
> provenance.  Both of these properties would also be verifiable by idnits.
>
>
this seems like a good idea.

Rob
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 17 Jan 2016 10:52:10 +0100

> they can check its provenance.  Both of these properties would also be 

Right now, we seem in the "hey lets invent more rules mode" and
tomorrow I am sure we are again in the "hey the IETF is way to
complicated to work in" mode.

If you have a unique revision date, why is google and the like not
sufficient to find the matching I-D? Sure, the proposed rule itself
does not hurt, but an increasingly large collection of rules may start
to hurt. So please, lets try to find the minimum number of rules where
we have evidence that they avoid big problems.

/js

---

From: Robert Wilton <[email-masked]>
Date: Sun, 17 Jan 2016 22:20:44 +0000

> complicated to work in" mode.
This was the approach that I followed when posting and updating the 
drafts that I was working on, perhaps mis-understanding the statement 
"The revision statement MUST have a reference substatement. It MUST 
identify the published document that contains the module." for which I 
presumed that the "published document" also includes the version number.

> we have evidence that they avoid big problems.
I'm also against having too many rules to follow, it starts to make the 
process too laborious.

My assumption is that given the relatively slow pace that standards 
models are being formally standardized that vendors/operators are likely 
to want/need to temporarily ship with pre-standard versions of the 
models.  Hence, in this case I personally feel that the additional 
clarity that is gained by explicitly referencing both date and full 
document name outweighs the slight hassle in updating it when a new 
version of the draft is posted.

Rob