Subject: [netmod] update on "rdns" URN for enterprise YANG models

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Fri, 15 Apr 2016 14:59:30 +0000

Hello,

At IETF94 in Yokohama,  I presented an idea to allow enterprise YANG models
to easily generate globally unique namespaces
(https://datatracker.ietf.org/doc/draft-chen-netmod-enterprise-yang-namespace/) .

The topic was also discussed on the mailing list:
https://mailarchive.ietf.org/arch/msg/netmod/JQmD8yrUeuAwuHpBnqZV_mcuveU
https://mailarchive.ietf.org/arch/msg/netmod/GSz_1dp2R3FPlMmu2_HF3ZIwrsY
https://mailarchive.ietf.org/arch/msg/netmod/tJDZPI9PV1-SjZm2c608OQu41ws
https://mailarchive.ietf.org/arch/msg/netmod/RCYhzKvMd0BATTtxaE69nbvcj7g

As promised, I started the process of registering the top-level "rdns" namespace.
Following RFC 3406, I wrote https://datatracker.ietf.org/doc/draft-chen-rdns-urn/
and completed the review on [email-masked] .  For the review on [email-masked] ,
please see the following messages.

The final message stating the review is complete is here:
https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs

The review in its entirety is here:
https://mailarchive.ietf.org/arch/msg/urn-nid/N3Md2evqFPE2o7figeGcyqT4BsY
https://mailarchive.ietf.org/arch/msg/urn-nid/wEIRTDvf4vPJPW9ORw6lkK6St2A
https://mailarchive.ietf.org/arch/msg/urn-nid/btXpEnmt7LHL4ZeCUvxYLQPUps4
https://mailarchive.ietf.org/arch/msg/urn-nid/52U72G2qzuqEwfSVIkD9YE-Pv3c
https://mailarchive.ietf.org/arch/msg/urn-nid/_AHANMEp_uq9ZFI7bHzf7lVvpoM
https://mailarchive.ietf.org/arch/msg/urn-nid/UgfKVlPS87x-1j2juHI8jLHdmAY
https://mailarchive.ietf.org/arch/msg/urn-nid/fFjwJMup43-P4mGQ4GMnG5DsrdM
https://mailarchive.ietf.org/arch/msg/urn-nid/sRpdhqpw-t4t0A15svbM_eywGj8
https://mailarchive.ietf.org/arch/msg/urn-nid/pibno5XNyXvAhuJ9bW6lKJjDA0w
https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs

Thanks,
Helen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Apr 2016 17:23:17 +0200

Hi Helen,

can you explain why

  urn:rdns:de:jacobs-university:foo

is from a technical perspective significantly better than

  http://jacobs-university.de/foo

also considering that domain names are not stable identifiers but
subject to changing ownerships or limited lifetimes (and hence a URN
embedding domain names has the same stability properties)?

/js

On Fri, Apr 15, 2016 at 02:59:30PM +0000, Ing-Wher (Helen) Chen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Fri, 15 Apr 2016 15:53:04 +0000

Section 4 of the draft <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4> 
documents why a URN is better than  URL as a namespace.  While a URL is globally
unique, a URL is also a resource locator, providing access information.  For an enterprise
that does not wish to publish the access information of its YANG models, a URN is a better
choice.

As required by RFC 3406, Section 3 of the draft, at the bottom of page 5
<https://tools.ietf.org/html/draft-chen-rdns-urn-06#page-5> under "Identifier Persistence
Considerations", addresses the question of identifier persistence.  The main concern
for "identifier persistence" is in the case where an identifier is used for global resolution.
Because YANG model namespaces do not provide global resolutions (actually YANG
model namespaces are only used to uniquely identify a model within a device),
the identifier persistence consideration is not as crucial.  (Please see RFC 3406
top of page 13 <https://tools.ietf.org/html/rfc3406#page-13> for the identifier
persistence discussion.)

Thanks,
Helen

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, April 15, 2016 11:23 AM
> To: Ing-Wher (Helen) Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
> 
> Hi Helen,
> 
> can you explain why
> 
> also considering that domain names are not stable identifiers but subject to
> changing ownerships or limited lifetimes (and hence a URN embedding
> domain names has the same stability properties)?
> 
> /js
> 
> > At IETF94 in Yokohama,  I presented an idea to allow enterprise YANG
> > models to easily generate globally unique namespaces
> https://mailarchive.ietf.org/arch/msg/netmod/JQmD8yrUeuAwuHpBnqZV_
> mcuv
> > eU
> >
> https://mailarchive.ietf.org/arch/msg/netmod/GSz_1dp2R3FPlMmu2_HF3ZI
> wr
> > sY
> > https://mailarchive.ietf.org/arch/msg/netmod/tJDZPI9PV1-
> SjZm2c608OQu41
> > ws
> >
> https://mailarchive.ietf.org/arch/msg/netmod/RCYhzKvMd0BATTtxaE69nbv
> cj
> > 7g
> >
> > Following RFC 3406, I wrote
> > https://datatracker.ietf.org/doc/draft-chen-rdns-urn/
> > and completed the review on [email-masked] .  For the review on
> > [email-masked] , please see the following messages.
> >
> > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-
> eTA4ONNiwaJhUP
> > mcs
> >
> > https://mailarchive.ietf.org/arch/msg/urn-
> nid/N3Md2evqFPE2o7figeGcyqT4
> > BsY
> > https://mailarchive.ietf.org/arch/msg/urn-
> nid/wEIRTDvf4vPJPW9ORw6lkK6S
> > t2A
> > https://mailarchive.ietf.org/arch/msg/urn-
> nid/btXpEnmt7LHL4ZeCUvxYLQPU
> > ps4
> > https://mailarchive.ietf.org/arch/msg/urn-nid/52U72G2qzuqEwfSVIkD9YE-
> P
> > v3c
> > https://mailarchive.ietf.org/arch/msg/urn-
> nid/_AHANMEp_uq9ZFI7bHzf7lVv
> > poM
> > https://mailarchive.ietf.org/arch/msg/urn-nid/fFjwJMup43-
> P4mGQ4GMnG5Ds
> > rdM
> > https://mailarchive.ietf.org/arch/msg/urn-nid/sRpdhqpw-
> t4t0A15svbM_eyw
> > Gj8
> > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-
> eTA4ONNiwaJhUP
> > mcs
> >
> > Thanks,
> > Helen
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Apr 2016 01:42:38 +0200

> that does not wish to publish the access information of its YANG models, a URN is a better

Continuing as devil's advocate...

The YANG specifications (both 1.0 and 1.1) has a normative reference to

  https://www.w3.org/TR/2009/REC-xml-names-20091208/

which states in section 3:

  [...] The namespace name, to serve its intended purpose, SHOULD
  have the characteristics of uniqueness and persistence. It is not a
  goal that it be directly usable for retrieval of a schema (if any
  exists). Uniform Resource Names [RFC2141] is an example of a syntax
  that is designed with these goals in mind. However, it should be
  noted that ordinary URLs can be managed in such a way as to achieve
  these same goals.

Do we have evidence that managing ordinary URLs in such a way as to
achieve these same goals (of uniqueness and persistence) is a problem?
If so, why does this only apply to YANG modules (only one of many uses
of XML namespaces)?

> top of page 13 <https://tools.ietf.org/html/rfc3406#page-13> for the identifier

I am not sure I agree that the scope of a YANG namespace is limited to
a device. There is nothing that prevents some random device to
implement some random YANG model. If the org currently owning bar.foo
publishes a module using urn:rdns:com:foo:bar as a namespace then
other orgs can implement this module as well if they think this is a
good idea.

I read:

     In practice, an administrator consciously installs YANG modules in
     a device.  Thus, in the unlikely event that there is a collision
     due to changing domain names, the administrator can detect the
     collision and rectify the situation by requesting that the
     offending organization republish its YANG modules with the correct
     "rdns" URNs.

Who is the 'administrator' that consciously installs YANG modules in a
device here? Administrator of what - the namespace or the device? In
case you mean the administrator of the namespace then what happens in
the case where this role changes because some other org took over the
domain name?

If a module uses urn:rdns:com:foo:bar and I later buy the domain
bar.foo than do I get change control of the YANG module using this
particular namespace as a side effect?

[...break...]

Taking a step back, we do have the tension between XML namespaces
(that are identified by URIs and used in the XML encoding) and 'JSON
namespaces' identified by module names (and used in the JSON
encoding). The former is relying on the uniqueness of a URI while the
later is relying on the uniqueness of the YANG module name. So from
this perspective, assuming the YANG module name is already
sufficiently unique, perhaps the right thing to do is to simply use

   urn:yang:<modulename>

for all XML namespaces and to essentially get rid of the namespace
declaration in YANG (which then defaults to urn:yang:<modulename>).

Now I need a break to think about this...

/js

---

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Tue, 19 Apr 2016 16:23:51 +0000

I'm not an expert on XML namespaces and I'm a little confused by some of
the questions, so I apologize if my response below does not quite answer the
questions.  I'd like to point out that the request for "rdns" URN is not to prevent
the use of URLs. The request for "rdns" URN is to allow an enterprise to easily
create a URN namespace, if the enterprise happens to prefer to use URN as a
YANG module namespace.  I also think that the problems that arise when a
YANG module uses a URN based on an enterprise's domain name are the same
problems that arise when a YANG module uses a URL based on an enterprise's
domain name.  (Of course, this is not an excuse to fix the problems that should
be fixed.)

> Sent: Friday, April 15, 2016 7:43 PM
> > Section 4 of the draft
> > <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4>
> > documents why a URN is better than  URL as a namespace.  While a URL
> > is globally unique, a URL is also a resource locator, providing access
> > information.  For an enterprise that does not wish to publish the
> > access information of its YANG models, a URN is a better choice.
> 
> If so, why does this only apply to YANG modules (only one of many uses of
> XML namespaces)?

I found some XML namespaces that are URLs,
e.g. http://www.w3.org/1999/XSL/Transform , that look like they're centrally
managed and should have uniqueness and persistence characteristics.  There
are also examples of URLs that do not have a centralized authority to manage
URLs and results in URLs not being persistence, e.g. confluence wiki pages create
URLs based on web page titles and so the wiki page URLs can change at random,
even though the page contents don't change.  (However, confluence wiki pages'
URLs are not used as XML namespaces, and so the lack of persistence is not an
issue.)  So, it seems that it's all about how URLs are managed---in particular,
centrally managed URLs can have uniqueness and persistence characteristics.
I think that this type of centralized management might be problematic for
enterprise YANG modules, which have no centralized authority.

> 
> > As required by RFC 3406, Section 3 of the draft, at the bottom of page
> > 5 <https://tools.ietf.org/html/draft-chen-rdns-urn-06#page-5> under
> > "Identifier Persistence Considerations", addresses the question of
> > identifier persistence.  The main concern for "identifier persistence" is in
> the case where an identifier is used for global resolution.
> > Because YANG model namespaces do not provide global resolutions
> > (actually YANG model namespaces are only used to uniquely identify a
> > model within a device), the identifier persistence consideration is
> > not as crucial.  (Please see RFC 3406 top of page 13
> > <https://tools.ietf.org/html/rfc3406#page-13> for the identifier
> > persistence discussion.)
> 
> I am not sure I agree that the scope of a YANG namespace is limited to a
> device. There is nothing that prevents some random device to implement
> some random YANG model. If the org currently owning bar.foo publishes a
> module using urn:rdns:com:foo:bar as a namespace then other orgs can
> implement this module as well if they think this is a good idea.

I'd like to flesh out this example to illustrate what I had in mind when I wrote
that YANG model namespaces are only used to uniquely identify a model within
a device.

Assume that device "R" currently implements/installs YANG module "ospf"
from company "A" which, at time T, owns domain "bar.foo", i.e. company "A's"
"ospf" YANG module's namespace is "urn:rdns:foo:bar:ospf".  At time T+delta,
company "A" gives up "bar.foo" and company B buys "bar.foo".  For whatever
reason, company "B" creates some other module "ospf", i.e. company "B's"
new "ospf" YANG module's namespace is also assigned "urn:rdns:foo:bar:ospf",
though this module presumably has contents different from company "A's"
"ospf" YANG modules.  If device "R" decides to implement module "ospf" from
company "A" and module "ospf" from company "B", then there is a collision on
this device "R".  When a NETCONF client attempts to manage device "R" and uses
"urn:rdns:foo:bar:ospf" to identify an "ospf" module, there is a problem, because
device "R" doesn't know which "urn:rdns:foo:bar:ospf" the client is referring to.
If some other device "Q" only implements one single "ospf" module (regardless
of whether the "ospf" module is from company "A" or from company "B"), then
the namespace "urn:rdns:foo:bar:ospf" identifies the one "ospf" module installed
on device "Q", and there are no ambiguities in the event that a NETCONF client
attempts to reference the module identified by "urn:rdns:foo:bar:ospf" on device "Q".
So, the problem of non-unique YANG module namespaces only manifests within
a device.

> Who is the 'administrator' that consciously installs YANG modules in a device
> here? Administrator of what - the namespace or the device? In case you
> mean the administrator of the namespace then what happens in the case
> where this role changes because some other org took over the domain
> name?
> 
> If a module uses urn:rdns:com:foo:bar and I later buy the domain bar.foo
> than do I get change control of the YANG module using this particular
> namespace as a side effect?

By "administrator", I meant the administrator of the device.

Using the example I fleshed out above, where company "A" initially owns
domain "bar.foo" and creates module "ospf" with namespace
"urn:rdns:foo:bar:ospf", but company "B" later purchases domain "bar.foo"
and also creates its own module "ospf" and gives it namespace
"urn:rdns:foo:bar:ospf". 

While it's true that <https://datatracker.ietf.org/doc/draft-chen-rdns-urn/>
allows this situation to occur, this situation only results in a problem in the
case of device "R" above, after device "R" implements both company "A's" "ospf"
module with namespace "urn:rdns:foo:bar:ospf" and company "B's" "ospf"
module also with namespace "urn:rdns:foo:bar:ospf".  Getting device "R" to
implement both modules is not trivial.  It actually requires obtaining both
modules, installing them on device "R", and perhaps even upgrading device "R's"
software to handle the second module.  In other words, I think that the
collision resulting from non-unique namespaces on device "R" is limited within
a device, therefore the solution can also be limited to the administrator detecting
and rectifying the collision.  I also think that this example holds true in the case
where an enterprise chooses to use URLs based on domain names as YANG
module namespaces.

> 
> [...break...]
> 
> Taking a step back, we do have the tension between XML namespaces (that
> are identified by URIs and used in the XML encoding) and 'JSON namespaces'
> identified by module names (and used in the JSON encoding). The former is
> relying on the uniqueness of a URI while the later is relying on the uniqueness
> of the YANG module name. So from this perspective, assuming the YANG
> module name is already sufficiently unique, perhaps the right thing to do is to
> simply use
> 
>    urn:yang:<modulename>
> 

This approach would require registering "yang" URN and also would place
constraints on <modulename>.  These constraints might result in the same
questions that we're struggling with now, with URN/URL based on domain
names that can come and go.

Thanks,
Helen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Apr 2016 20:22:50 +0200

> domain name.  (Of course, this is not an excuse to fix the problems that should

You write "happen to prefer to use URN" - why?
 
> that YANG model namespaces are only used to uniquely identify a model within

[...]

I think a management application likely has a problem is a URI value
can mean different things on different devices unless it always
fetches the model from the devices. Anyway, this problem exists for
URNs that contain domain names in the same way as for URLs that
contain domain names. In practice, I think this scenario is rare - it
is likely more common that people rename modules and namespaces, e.g.
when a company acquires a different company. This is strictly speaking
not a problem since YANG treats such a renamed module as a new module.

> names that can come and go.

The namespace definition is used by the XML encoding, the JSON
encoding uses the YANG module name to identify a 'namespace'. The
module name generally is assumed to be unique since tools (e.g., YANG
compilers) import via module names. A urn:yang:<modulename> would have
the advantage to integrate things. In fact, the namespace statement in
YANG could become optional, if one does not define a namespace, then
the default namespace is urn:yang:<modulename> (and this would enable
round-trip conversion of namespaces between XML and JSON encoding,
something I always found a valuable property.)

Anyway, it would be good to hear opinions of other people.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Apr 2016 21:37:03 +0200 (CEST)

> Anyway, it would be good to hear opinions of other people.

I can see the value in a urn:rdns: URN.  Using 'http://' for YANG
module namespace is a bit weird.  Why not 'https://'?  Or 'gopher://'?

But I like urn:yang:<module-name> even more - and if we had this, we
wouldn't have to use the "namespace" statement.  Unfortunately that
would require a new version of YANG...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Apr 2016 13:51:32 -0700

On Tue, Apr 19, 2016 at 12:37 PM, Martin Bjorklund <[email-masked]> wrote:

> (that
I do not think the standard mechanisms are good enough to assume
YANG module names will be globally unique.  The RDNS format
needs to include the naming authority somehow.  The namespace URI
gives the author more control to make naming collisions less likely.

> /martin

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Apr 2016 13:34:02 +0200

> gives the author more control to make naming collisions less likely.

Are you saying that (a) YANG imports are broken (since they assume
unique module names) and that (b) JSON encoding is broken (since it
uses module names to define 'namespaces'?

I believe module authors will have to make sure module names are
unique; if not they will learn it the hard way. Yes, I know the
wording in 6020bis is

   Within a server, all module names MUST be unique.

since this is obviously decidable and thus enforceable but RFC 6087
should clearly advice to create module names that have a larger scope
of uniqueness. In fact, -06 still says:

   All published module names MUST be unique. [...]

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Apr 2016 13:47:53 +0200

> module namespace is a bit weird.  Why not 'https://'?  Or 'gopher://'?

The point is it does not matter. In some theory, the idea is that the
URL resolves to something useful but in practice this does not matter.
 
> would require a new version of YANG...

I think we should try to move into a direction that makes things
simpler and more consistent in the longer term. It is too late to
address this in YANG 1.1 but clearly if I would have had this idea
earlier I would have filed an issue. The urn:yang:<module-name> makes
it clear that

- we are talking about YANG URNs and
- it forces people to think carefully about their module names.

Even the IETF could in principle move to a scheme where we use

  module ietf-foo {
    version 1.1;
    namespace "urn:yang:ietf-foo";
    // ...
  }

and future versions of YANG may then even drop the namespace
definition if it matches the module name, e.g., the example
becomes just this:

  module ietf-foo {
    version 1.2;
    // ...
  }

(The XML encoding specific namespace definition is removed.)

/js

PS: In hindsight, perhaps we should have used reverse DNS names for
    module name prefixes, i.e., org-ietf-foo instead of just ietf-foo
    and so we would have a reasonably reliable mechanism in place to
    create unique names for both SDOs and other organizations.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Apr 2016 14:39:42 +0200

> On 20 Apr 2016, at 13:34, Juergen Schoenwaelder <[email-masked]> wrote:
> 

[I know we already had this discussion but …] It is unclear what "published" means - not so much in 6087bis whose scope is restricted to Standard Track RFCs. However, 6020bis provides no definition but nonetheless uses "published" in connection with 2119 keywords, e.g.

For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements.

I think this is quite problematic.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Apr 2016 06:32:39 -0700

> uses module names to define 'namespaces'?

No, I didn't say that.

>    Within a server, all module names MUST be unique.
This is obviously easy to accomplish since YANG imports cannot
possibly work with  2 modules with the same name.

>    All published module names MUST be unique. [...]

guidelines are not part of YANG.
A compiler cannot rely on that.

Andy

---

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Wed, 20 Apr 2016 14:40:50 +0000

> Sent: Tuesday, April 19, 2016 2:23 PM
> > I'm not an expert on XML namespaces and I'm a little confused by some
> > of the questions, so I apologize if my response below does not quite
> > answer the questions.  I'd like to point out that the request for
> > "rdns" URN is not to prevent the use of URLs. The request for "rdns"
> > URN is to allow an enterprise to easily create a URN namespace, if the
> > enterprise happens to prefer to use URN as a YANG module namespace.  I
> > also think that the problems that arise when a YANG module uses a URN
> > based on an enterprise's domain name are the same problems that arise
> > when a YANG module uses a URL based on an enterprise's domain name.
> > (Of course, this is not an excuse to fix the problems that should be
> > fixed.)
> 

draft-chen-rdns-urn Section 4 <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4>
discusses why an enterprise might prefer to use URN over URL.  URL provides
resource access mechanism, which might mislead a customer to request that
the YANG module be accessible at a specific location.  It's true that the device
does not care that the YANG module is not at a particular URL, but I can still
imagine getting a bug requesting that the YANG module be accessible at the URL.

Thanks,
Helen

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Apr 2016 16:47:55 +0200 (CEST)

Hi,

One comment on this draft - why is it only for YANG module namespaces?
It seems to me that it could be useful to use urn:rdns URNs for other
purposes as well.

If you really want to limit it to YANG module namespaces, maybe it
should be called urn:yang-rdns:  or something.

/martin

---

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Wed, 20 Apr 2016 15:24:25 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2016 10:48 AM
> Cc: [email-masked]; [email-masked]

There are indeed many use cases for URNs based on registered domain names,
and I believe there are registrations for top-level URN names where parts of
the URN are based on domain names.

The technical problem of generalizing is the difficulty in creating a URN based
on domain names that is also persistent.   Limiting the scope of the "rdns" URN
namespace to only YANG modules means that there is a smaller persistency
problem to solve and that it can be solved by taking advantage of properties	
specific to YANG modules.

> 
> If you really want to limit it to YANG module namespaces, maybe it should be
> called urn:yang-rdns:  or something.

Noted.

Thanks,
Helen

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Apr 2016 18:10:23 +0000

On 4/20/16, 7:47 AM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

>earlier I would have filed an issue. 

Just filed one for YANG-next: https://github.com/netmod-wg/yang-next/issues/5.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Apr 2016 11:38:54 +0200

On Wed, Apr 20, 2016 at 03:24:25PM +0000, Ing-Wher (Helen) Chen wrote:
> 
> The technical problem of generalizing is the difficulty in creating
> a URN based on domain names that is also persistent.  Limiting the
> scope of the "rdns" URN namespace to only YANG modules means that
> there is a smaller persistency problem to solve and that it can be
> solved by taking advantage of properties specific to YANG modules.
>

Can you detail which properties specific to YANG modules make the
smaller persistency problem solvable?

/js