[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

URN Re: IANA considerations update for NETCONF protocol draft



TP: below

Tom Petch

----- Original Message -----
From: "Rob Enns" <rpe@juniper.net>
To: "McDonald, Ira" <imcdonald@sharplabs.com>; "Eliot Lear" <lear@cisco.com>
Cc: "Tom Petch" <nwnetworks@dial.pipex.com>; "Randy Presuhn"
<randy_presuhn@mindspring.com>; "netconf" <netconf@ops.ietf.org>
Sent: Monday, December 05, 2005 10:48 PM
Subject: RE: IANA considerations update for NETCONF protocol draft


> XML sloppily addresses this problem (in dozens of W3C, OASIS, and
other
> specs) by saying just use an enterprise URI (with the durability
problem
> that Randy complains about).

Sloppy but workable. Just about sums up XML, doesn't it? :-)

TP: sums it up beautifully:-(

> But this is not rocket science.  The NetConf spec should say that
> Enterprise Capabilities MUST be prefixed by a durable URN (not simply
> a URI) and are not going to be IANA registered.  End of problem.

How does one determine URN durability? Avoidance of DNS names for one
thing.
Is this term well known? (Googling "durable urn" leads down the wrong
path)

TP: tautology:-) as the RFC say (eg RFC1737) a key feature of a URN is
persistence, even after the resource has gone (unlike a URL).

> And I suggest that you further specify that Enterprise Capabilities
> SHOULD use the UUID URN Namespace (RFC 4122, July 2005).

This is cool, but for capability URIs does NETCONF require
this level of rigor? If an enterprise wants to add a capability to it's
product, an enterprise URI should be sufficient.

TP: I agree, I think specifying URI would be enough.  Organisations that grow by
acquisition - eg Cisco - acquire multiple Assigned Numbers in a controlled
namespace and then have to decide what to do about them, maintaining,
obsoleting, migrating etc; I often see evidence of this but it has not been a
problem for me.

Rob


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>