Subject: [netmod] yang usage: temporary URI issue

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 16:35:05 -0700

Hi,

The actual format of the temporary contents of the namespace statement
needs to be finalized.

  - there may be more than 1 module in the I-D
  - it is useful to identify the document revision,
    in case early implementations actually exist.
  - a valid URI scheme is needed

The current draft suggests the I-D name, without the revision or file suffix.

The slide in the NETMOD meeting suggested the module name:

 module foo {
   namespace "file://foo.yang";
   prefix foo;
   ...
 }

*** New Proposed Solution: add the I-D version to the module name
*** Also add 'tbd-assigned-by-IANA-tbd/' to path to make it more
*** clear that this value will be replaced in the RFC version

 module foo {
   // note to IANA: replace this string with real namespace URI
   namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang";
   prefix foo;
   ...
 }

Any objections to this change?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 29 Jul 2009 20:12:56 -0400

>   namespace "file://tbd-assigned-by-IANA-tbd/foo-02.yang";

file:// seems bad.  Consider instead a URN-based approach:

   namespace unn:ietf:params:xml:ns:yang:draft:<module>-<rev>.txt

This is consisent with the namespaces of NETCONF and YANG.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 17:52:24 -0700

> This is consisent with the namespaces of NETCONF and YANG.

IMO this is too consistent.
It looks very close to the real one that will be assigned later.
It looks like we need to get IANA approval for the temporary namespace.

We have some MIB experience that suggests that these temporary 'MIB roots'
stick around way longer than originally anticipated.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 18:00:14 -0700

> file:// seems bad.  Consider instead a URN-based approach:

Why does the 'file' scheme seem bad?
It is clearly not an IANA-controlled scheme,
so it will not cause confusion with the real
URI assigned by IANA.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 29 Jul 2009 22:52:24 -0400

>It looks like we need to get IANA approval for the temporary namespace.

We can ask them to delegate the leading string to drafts.

>stick around way longer than originally anticipated.

Well, that's to be expected, right?  If I implement a draft in
JUNOS, I will be shipping support for it for a long long time.  When
the final rfc appears, I'll add that.  Customer disapprove when ou
remove things that used to work, even when they know they are drafts.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2009 07:39:29 +0200

> This is consisent with the namespaces of NETCONF and YANG.

Two little improvements and a bug fix:

a) s/.txt//

b) s/draft/DRAFT/

c) s/unn/urn  ;-)

/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: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 02:34:20 -0700

> Two little improvements and a bug fix:

the problem with these cryptic strings is that it is
so easy to get them wrong.   3 bugs on the first try?
I'm not impressed, but if this is the string people want to
hunt down in existing drafts and cut-and-paste for years to come,
then fine.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2009 12:35:16 +0200

> hunt down in existing drafts and cut-and-paste for years to come,

I guess not every YANG module will be written in the middle of the
night on a Wednesday evening at an IETF week. I think Phil was doing
actually quite well. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 15:34:35 -0700

> night on a Wednesday evening at an IETF week. I think Phil was doing

OK, we have a winner:

   namespace urn:ietf:params:xml:ns:yang:DRAFT:<module-name>-<draft-rev>

   e.g.:

    namespace urn:ietf:params:xml:ns:yang:DRAFT:foo-03
    namespace urn:ietf:params:xml:ns:yang:DRAFT:foo-04
    namespace urn:ietf:params:xml:ns:yang:DRAFT:bar-00

Is the IANA request for a registry for temporary namespace URIs
(so they are never reissued), along with the template for all
registry entries, supposed to go in this Informational RFC?
Or will the co-chairs make a separate request?

Uh-oh, another detail:  Should 'yang' really be 'netmod'?  IMO, yes.
The naming authority is the NETMOD WG, not the YANG language.

    namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-03
    namespace urn:ietf:params:xml:ns:netmod:DRAFT:foo-04
    namespace urn:ietf:params:xml:ns:netmod:DRAFT:bar-00

So what is a real YANG module URN supposed to look like?

    namespace urn:ietf:params:xml:ns:netmod:RFC5991:foo
    namespace urn:ietf:params:xml:ns:netmod:RFC6210:foo
    namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar

Where is this registry and template defined?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Jul 2009 19:28:30 -0400

>Uh-oh, another detail:  Should 'yang' really be 'netmod'?  IMO, yes.

I'd rather stick with "yang".  These are "yang" modules, not "metnod"
nodules, and the naming authority isn't the NETMOD WG, since the
modules will be defined in their appropriate WG, not in ours.

>    namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar

s/RFC/rfc/

DRAFT is caps to catch your eye.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 16:54:59 +0200 (CEST)

>     namespace urn:ietf:params:xml:ns:netmod:RFC5991:bar

Do not put the rfc number there - we use the revision parameter to
indicate revision.  When the ipfix model version 2 is published with
only minor corrections, we don't want to change its namespace URI and
break old clients.

I don't really understand why we need all the extra characters in this
uri, when e.g.

   urn:ietf:yang:ietf-foo

would be enough (since all ietf module names are unique).  But I guess
it would be too simple.  People might even remember them :)

/martin