RE: NETCONF protocol IANA considerations & capability URNs
"Rob Enns" <rpe@juniper.net> Tue, 13 September 2005 23:19 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFK4A-0002ih-1a for netconf-archive@megatron.ietf.org; Tue, 13 Sep 2005 19:19:54 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09459 for <netconf-archive@lists.ietf.org>; Tue, 13 Sep 2005 19:19:49 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFJu5-00083I-UD for netconf-data@psg.com; Tue, 13 Sep 2005 23:09:29 +0000
Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EFJu3-00082z-Uj for netconf@ops.ietf.org; Tue, 13 Sep 2005 23:09:27 +0000
Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 13 Sep 2005 16:09:28 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,107,1125903600"; d="scan'208"; a="482254900:sNHT23605744"
Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 16:09:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: NETCONF protocol IANA considerations & capability URNs
Date: Tue, 13 Sep 2005 16:08:28 -0700
Message-ID: <062B922B6EC55149B5A267ECE78E5D440BC4BDBA@photon.jnpr.net>
Thread-Topic: NETCONF protocol IANA considerations & capability URNs
Thread-Index: AcW4c/l2jyCj1j16RpW3fvqxwSgkNgAQ8oOA
From: Rob Enns <rpe@juniper.net>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "Netconf (E-mail)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 13 Sep 2005 23:09:27.0015 (UTC) FILETIME=[3015B770:01C5B8B8]
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
Got it, thanks. Rob > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, September 13, 2005 8:01 AM > To: Rob Enns; Netconf (E-mail) > Subject: FW: NETCONF protocol IANA considerations & capability URNs > > I had a question that I asked to one of the APPS ADs. > Here is the answer. FYI and action > > Bert > > -----Original Message----- > From: Scott Hollenbeck [mailto:sah@428cobrajet.net] > Sent: Tuesday, September 13, 2005 16:31 > To: 'Wijnen, Bert (Bert)' > Subject: RE: NETCONF protocol IANA considerations & capability URNs > > > I'm very familiar with that situation. There is no XML > associated with a > namespace -- it's identified by a URI and a URI alone. > However, some people > apparently think that an XML-formatted description of the URI in the > registry is helpful. I think it's unnecessary, but harmless. > > The text you've copied below should probably leave the first > XML field in > the template blank. It's clearly not "this document". The > second one is OK > as long as appendix B is the appropriate XML Schema, nested > between BEGIN > and END tags as described in RFC 3688. > > -Scott- > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, September 13, 2005 10:17 AM > > To: Scott Hollenbeck (E-mail) > > Subject: FW: NETCONF protocol IANA considerations & capability URNs > > > > Scott, can you check the below, if it is correct and makes sense? > > > > When I look at > > http://www.iana.org/assignments/xml-registry/ns.html > > > > I see that some do have XML, other state XML: non > > because a URI for a namespace does not have an XML spec. > > Mmm.. I need to read up more on how this works, unless > > you can help me easily. > > > > Bert > > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]On > > Behalf Of Rob Enns > > Sent: Tuesday, September 13, 2005 01:07 > > To: Netconf (E-mail) > > Subject: NETCONF protocol IANA considerations & capability URNs > > > > > > Here is a proposed IANA considerations section for the NETCONF > > protocol draft. Also, while working through the various RFCs > > 3553 and 3688 I realized that the capability URNs shown in the > > NETCONF protocol draft are incorrect. > > > > The URNs currently have the form: > > > > urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 > > > > This says that the capability is an XML namespace as defined > > by RFC 3688. Strictly speaking, that is incorrect. > > > > The capability URNs should really be a NETCONF protocol > > parameter a la RFC 3553. Something like: > > > > urn:ietf:params:netconf:capability:{name}:1.0 > > > > If the WG approves, I will make this change to the protocol draft. > > > > Here is a proposed IANA considerations section assuming the > > capabilities are expressed as shown above. Please comment. > > > > ---- > > > > 10. IANA Considerations > > > > 10.1. NETCONF XML Namespace > > > > This document requests that IANA assign a URI for the NETCONF XML > > namespace in the IETF XML registry [8]. > > > > Following the format in RFC 3688, the following registration is > > requested. > > > > URI: Please assign the URI > "urn:ietf:params:xml:ns:netconf" for use > > by the NETCONF protocol. > > > > Registrant Contact: The IESG. > > > > XML: This document. > > > > 10.2. NETCONF XML Schema > > > > This document requests that IANA assign a URI for the NETCONF XML > > namespace in the IETF XML registry [8]. > > > > Following the format in RFC 3688, the following registration is > > requested. > > > > URI: Please assign the URI > "urn:ietf:params:xml:schema:netconf" for > > use by the NETCONF protocol. > > > > Registrant Contact: The IESG. > > > > XML: Appendix B of this document. > > > > 10.3. NETCONF Capability URNs > > > > This document requests that IANA create a registry for allocating > > NETCONF capability identifiers. Allocation from the > > registry is on a > > First Come First Served Basis, but a specification is required. > > > > The initial content of the registry will be the capability URNs > > defined in Section 8. Once further experience is gained with > > NETCONF, this sub-namespace may be used for additional purposes. > > > > Following the guidelines in RFC 3553 [7], IANA is > > requested to assign > > a NETCONF sub-namespace as follows: > > > > Registry name: netconf > > > > Specification: This document. > > > > Repository: This document. > > > > Index value: The NETCONF capability name. > > > > -- > > 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/> > > > -- 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/>
- NETCONF protocol IANA considerations & capability… Rob Enns
- FW: NETCONF protocol IANA considerations & capabi… Wijnen, Bert (Bert)
- Re: NETCONF protocol IANA considerations & capabi… Andy Bierman
- RE: NETCONF protocol IANA considerations & capabi… Rob Enns
- Re: NETCONF protocol IANA considerations & capabi… Ted Goddard
- RE: NETCONF protocol IANA considerations & capabi… Rob Enns