From owner-netconf@ops.ietf.org Thu Sep 01 15:41:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuvy-00089f-9E for netconf-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:41:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26117 for ; Thu, 1 Sep 2005 15:41:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAund-000OQ1-Ie for netconf-data@psg.com; Thu, 01 Sep 2005 19:32:37 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAunb-000OPi-Lm for netconf@ops.ietf.org; Thu, 01 Sep 2005 19:32:35 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j81JWTf8023557; Thu, 1 Sep 2005 14:32:30 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Sep 2005 21:32:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C2C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ted Goddard Cc: netconf Subject: AD review: draft-ietf-netconf-soap-05 Date: Thu, 1 Sep 2005 21:32:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hre is my AD review. Sorry that this one slipped through the cracks and took a bit longer. I have also seen the suggested changes (as per below email from Ted) and will assume such changes will be made. A lot of the SOAP/WSDL stuff is completely new for me, so pls bear with me if I ask newbee questions. But I think we should assume that others who read the documents may also be newbees, and so maybe we should at least make it all clear in the document. - I do not see in the document how a session-id gets passed from setting up a BEEP or HTTP conenction to the NetConf protocol level so that NetConf can use the session-id. Maybe it is there, but I do not see it. Pls explain and clarify in the text. - sect 3.7 - Is it OK to assume a "hypothetical location", or should we decide and/or request IANA or xmlsoap.org to define a real and approved location? - Have you (has anyone) done a SYNTAX check on the WSDL document, and if so, which tool was used? - In the WSDL document, there are www.iana.org items. for example I see: WHere is that coming from. Maybe that is to be found in the missing (i.e. TBD) text from the netconf-protocol document? Another example xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" Does that need a citation/reference? xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" Does IANA now how to create that? Or is there no IANA action needed for that? There may be other stuff. Once I understand the above I can check further and see if I have more questions. - IANA considerations Section - says "IANA will". Maybe better: "IANA is requested to" - Is the port for BEEP not already requested via the netconf-over-beep document? - Where is IANA supposed to put the WSDL definition? you say in the XML registry. WHich is the document that explains how to do that? Where is the ptr to the iana we page that contains these sort of documents? CItation/Reference issues: !! Missing citation for Normative reference: P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail !! Missing citation for Normative reference: P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail !! Missing citation for Normative reference: P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, !! Missing citation for Informative reference: P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with !! Missing citation for Informative reference: P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and R. Monzillo, "Web NITS: - Pls expand Acrionyms first time they are used. For example BEEP in the abstract. WSDL in 3rd para section 1. - Sect 2.5, last sentence. you may want to add a citation (and reference) to the RFC(s) that describes "chunking and persistent connections". - I see sometimes "Reciever" and other times "Receiver". I think it should be consistent: "Receiver" - Security COnsiderations section: s/IPSec/IPsec/ Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Ted Goddard > Sent: Tuesday, August 30, 2005 19:46 > To: netconf > Subject: proposed changes for draft-ietf-netconf-soap-06 > > > > Hi All, > > I would like to propose the following changes for the NETCONF SOAP > draft in the indicated sections: > > > Section 0 > > RFC 3978 boilerplate > > Section 2.4 BCP56: On the Use of HTTP as a Substrate > > It is also possible to respond to the concern on the re-use of > port 80. A NETCONF SOAP service SHOULD be offered over a new > standard port for NETCONF over SOAP (over HTTP) to > be defined as requested in the IANA considerations of this > document. > > Section 4 Security Considerations > > The IANA requested port SHOULD be used, as this provides a means > for efficient firewall filtering during possible > denial-of-service > attacks. > > Section 5 IANA Considerations > > The IANA is requested to assign TCP ports for NETCONF for SOAP > over HTTP and SOAP over BEEP. > > The IANA is requested to place netconf-soap_1.0.wsdl in the > IANA XML registry. > > The following indicated ID-nits appear to be in error (xml2rfc > output checked with "od -c"): > > tmp/draft-ietf-netconf-soap-05.txt(452): > Line is too long: the offending characters are 'elope"' > tmp/draft-ietf-netconf-soap-05.txt(464): > Line is too long: the offending characters are > 's:netconf:base:1.0">' > > > Thanks, > Ted. -- 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: From owner-netconf@ops.ietf.org Thu Sep 01 15:56:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAvAX-0007B9-Bc for netconf-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:56:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26815 for ; Thu, 1 Sep 2005 15:56:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAv57-0002KF-6G for netconf-data@psg.com; Thu, 01 Sep 2005 19:50:41 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAv53-0002Jh-46 for netconf@ops.ietf.org; Thu, 01 Sep 2005 19:50:37 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Thu, 1 Sep 2005 12:50:57 -0700 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C2C@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C2C@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: netconf Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: AD review: draft-ietf-netconf-soap-05 Date: Thu, 1 Sep 2005 13:50:33 -0600 To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.734) 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bert, Thanks for reviewing the SOAP draft. RFC 3688 describes the IANA XML Registry (I will add a reference to the SOAP draft for this) covering namespace and schema registration. Unfortunately it does not mention WSDL registration. Is it still appropriate to request that IANA host the NETCONF WSDL or would RFC 3688 have to be revised first? Thanks, Ted. On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: > Hre is my AD review. Sorry that this one slipped through > the cracks and took a bit longer. I have also seen > the suggested changes (as per below email from Ted) and > will assume such changes will be made. > > A lot of the SOAP/WSDL stuff is completely new for me, > so pls bear with me if I ask newbee questions. > But I think we should assume that others who read the > documents may also be newbees, and so maybe we should at > least make it all clear in the document. > > - I do not see in the document how a session-id gets > passed from setting up a BEEP or HTTP conenction > to the NetConf protocol level so that NetConf can use > the session-id. Maybe it is there, but I do not see it. > Pls explain and clarify in the text. > > - sect 3.7 > - Is it OK to assume a "hypothetical location", or should we > decide and/or request IANA or xmlsoap.org to define a > real and approved location? > - Have you (has anyone) done a SYNTAX check on the WSDL > document, and if so, which tool was used? > - In the WSDL document, there are www.iana.org items. > for example I see: > location="http://www.iana.org/assignments/xml-registry/ > schema/netconf-base_1.0.xsd"/> > WHere is that coming from. > Maybe that is to be found in the missing (i.e. TBD) text from > the netconf-protocol document? > Another example > xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" > Does that need a citation/reference? > xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" > Does IANA now how to create that? Or is there no IANA > action needed for that? > There may be other stuff. Once I understand the above I can > check further and see if I have more questions. > > - IANA considerations Section > - says "IANA will". Maybe better: "IANA is requested to" > - Is the port for BEEP not already requested via the > netconf-over-beep document? > - Where is IANA supposed to put the WSDL definition? > you say in the XML registry. WHich is the document that > explains how to do that? Where is the ptr to the iana > we page that contains these sort of documents? > > CItation/Reference issues: > > > !! Missing citation for Normative reference: > P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose > Internet Mail > > !! Missing citation for Normative reference: > P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose > Internet Mail > > !! Missing citation for Normative reference: > P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for > syslog", RFC 3195, > > !! Missing citation for Informative reference: > P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP > Messages with > > !! Missing citation for Informative reference: > P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and > R. Monzillo, "Web > > NITS: > > - Pls expand Acrionyms first time they are used. > For example BEEP in the abstract. > WSDL in 3rd para section 1. > - Sect 2.5, last sentence. > you may want to add a citation (and reference) to the RFC(s) > that describes "chunking and persistent connections". > - I see sometimes "Reciever" and other times "Receiver". > I think it should be consistent: "Receiver" > - Security COnsiderations section: s/IPSec/IPsec/ > > Bert > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner- >> netconf@ops.ietf.org]On >> Behalf Of Ted Goddard >> Sent: Tuesday, August 30, 2005 19:46 >> To: netconf >> Subject: proposed changes for draft-ietf-netconf-soap-06 >> >> >> >> Hi All, >> >> I would like to propose the following changes for the NETCONF SOAP >> draft in the indicated sections: >> >> >> Section 0 >> >> RFC 3978 boilerplate >> >> Section 2.4 BCP56: On the Use of HTTP as a Substrate >> >> It is also possible to respond to the concern on the re-use of >> port 80. A NETCONF SOAP service SHOULD be offered over a new >> standard port for NETCONF over SOAP (over HTTP) to >> be defined as requested in the IANA considerations of this >> document. >> >> Section 4 Security Considerations >> >> The IANA requested port SHOULD be used, as this provides a >> means >> for efficient firewall filtering during possible >> denial-of-service >> attacks. >> >> Section 5 IANA Considerations >> >> The IANA is requested to assign TCP ports for NETCONF for SOAP >> over HTTP and SOAP over BEEP. >> >> The IANA is requested to place netconf-soap_1.0.wsdl in the >> IANA XML registry. >> >> The following indicated ID-nits appear to be in error (xml2rfc >> output checked with "od -c"): >> >> tmp/draft-ietf-netconf-soap-05.txt(452): >> Line is too long: the offending characters are 'elope"' >> tmp/draft-ietf-netconf-soap-05.txt(464): >> Line is too long: the offending characters are >> 's:netconf:base:1.0">' >> >> >> Thanks, >> Ted. > -- 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: From owner-netconf@ops.ietf.org Thu Sep 01 17:05:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwF0-00074g-6D for netconf-archive@megatron.ietf.org; Thu, 01 Sep 2005 17:05:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29523 for ; Thu, 1 Sep 2005 17:04:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAw95-000IHS-To for netconf-data@psg.com; Thu, 01 Sep 2005 20:58:51 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAw93-000IHA-SG for netconf@ops.ietf.org; Thu, 01 Sep 2005 20:58:49 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j81KwkRi018105; Thu, 1 Sep 2005 15:58:47 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Sep 2005 22:58:46 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C3E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ted Goddard Cc: netconf Subject: RE: AD review: draft-ietf-netconf-soap-05 Date: Thu, 1 Sep 2005 22:58:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: Ted Goddard [mailto:ted.goddard@icesoft.com] > Sent: Thursday, September 01, 2005 16:51 > To: Wijnen, Bert (Bert) > Cc: netconf > Subject: Re: AD review: draft-ietf-netconf-soap-05 > > > > Hi Bert, > > Thanks for reviewing the SOAP draft. > > RFC 3688 describes the IANA XML Registry (I will add a reference > to the SOAP draft for this) covering namespace and schema > registration. OK, that helps. Do you also see that your registration reuqest must be in a predefined form as per section 4 of that RFC3688? Make sure you align with what the netconf protocol does. Because I think they also need to register things, no? Maybe they already register part of what you need. > Unfortunately it does not mention WSDL registration. > Is it still appropriate to request that IANA host the NETCONF WSDL > or would RFC 3688 have to be revised first? > No idea. Are we the first to do any WSDL definition? If so, then maybe some sort of registry needs to be set up. Sould you rather register it at the xmlsoap.org? - If the former, then a registry needs to be created and some rules need to be defined how things can be registered there. The APPS ADs may be able to help us here. - If the latter, then at least the WG needs to agree, and I further not sure how other IETFers think about us using registries at other organizations for standards that we define/approve in IETF. I guess the WG has to make up their mind. Does that help? Bert > Thanks, > Ted. > > > On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: > > > Hre is my AD review. Sorry that this one slipped through > > the cracks and took a bit longer. I have also seen > > the suggested changes (as per below email from Ted) and > > will assume such changes will be made. > > > > A lot of the SOAP/WSDL stuff is completely new for me, > > so pls bear with me if I ask newbee questions. > > But I think we should assume that others who read the > > documents may also be newbees, and so maybe we should at > > least make it all clear in the document. > > > > - I do not see in the document how a session-id gets > > passed from setting up a BEEP or HTTP conenction > > to the NetConf protocol level so that NetConf can use > > the session-id. Maybe it is there, but I do not see it. > > Pls explain and clarify in the text. > > > > - sect 3.7 > > - Is it OK to assume a "hypothetical location", or should we > > decide and/or request IANA or xmlsoap.org to define a > > real and approved location? > > - Have you (has anyone) done a SYNTAX check on the WSDL > > document, and if so, which tool was used? > > - In the WSDL document, there are www.iana.org items. > > for example I see: > > > location="http://www.iana.org/assignments/xml-registry/ > > schema/netconf-base_1.0.xsd"/> > > WHere is that coming from. > > Maybe that is to be found in the missing (i.e. TBD) text from > > the netconf-protocol document? > > Another example > > xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" > > Does that need a citation/reference? > > xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" > > Does IANA now how to create that? Or is there no IANA > > action needed for that? > > There may be other stuff. Once I understand the above I can > > check further and see if I have more questions. > > > > - IANA considerations Section > > - says "IANA will". Maybe better: "IANA is requested to" > > - Is the port for BEEP not already requested via the > > netconf-over-beep document? > > - Where is IANA supposed to put the WSDL definition? > > you say in the XML registry. WHich is the document that > > explains how to do that? Where is the ptr to the iana > > we page that contains these sort of documents? > > > > CItation/Reference issues: > > > > > > !! Missing citation for Normative reference: > > P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for > > syslog", RFC 3195, > > > > !! Missing citation for Informative reference: > > P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP > > Messages with > > > > !! Missing citation for Informative reference: > > P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and > > R. Monzillo, "Web > > > > NITS: > > > > - Pls expand Acrionyms first time they are used. > > For example BEEP in the abstract. > > WSDL in 3rd para section 1. > > - Sect 2.5, last sentence. > > you may want to add a citation (and reference) to the RFC(s) > > that describes "chunking and persistent connections". > > - I see sometimes "Reciever" and other times "Receiver". > > I think it should be consistent: "Receiver" > > - Security COnsiderations section: s/IPSec/IPsec/ > > > > Bert > > > > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org [mailto:owner- > >> netconf@ops.ietf.org]On > >> Behalf Of Ted Goddard > >> Sent: Tuesday, August 30, 2005 19:46 > >> To: netconf > >> Subject: proposed changes for draft-ietf-netconf-soap-06 > >> > >> > >> > >> Hi All, > >> > >> I would like to propose the following changes for the NETCONF SOAP > >> draft in the indicated sections: > >> > >> > >> Section 0 > >> > >> RFC 3978 boilerplate > >> > >> Section 2.4 BCP56: On the Use of HTTP as a Substrate > >> > >> It is also possible to respond to the concern on the > re-use of > >> port 80. A NETCONF SOAP service SHOULD be offered over a new > >> standard port for NETCONF over SOAP (over HTTP) to > >> be defined as requested in the IANA considerations of this > >> document. > >> > >> Section 4 Security Considerations > >> > >> The IANA requested port SHOULD be used, as this provides a > >> means > >> for efficient firewall filtering during possible > >> denial-of-service > >> attacks. > >> > >> Section 5 IANA Considerations > >> > >> The IANA is requested to assign TCP ports for > NETCONF for SOAP > >> over HTTP and SOAP over BEEP. > >> > >> The IANA is requested to place netconf-soap_1.0.wsdl in the > >> IANA XML registry. > >> > >> The following indicated ID-nits appear to be in error (xml2rfc > >> output checked with "od -c"): > >> > >> tmp/draft-ietf-netconf-soap-05.txt(452): > >> Line is too long: the offending characters are 'elope"' > >> tmp/draft-ietf-netconf-soap-05.txt(464): > >> Line is too long: the offending characters are > >> 's:netconf:base:1.0">' > >> > >> > >> Thanks, > >> Ted. > > > > -- 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: From owner-netconf@ops.ietf.org Thu Sep 01 17:05:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwFG-0007J9-1G for netconf-archive@megatron.ietf.org; Thu, 01 Sep 2005 17:05:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29529 for ; Thu, 1 Sep 2005 17:05:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAw9F-000IIb-9e for netconf-data@psg.com; Thu, 01 Sep 2005 20:59:01 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAw9B-000IHr-FO for netconf@ops.ietf.org; Thu, 01 Sep 2005 20:58:57 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j81KwnFv018144; Thu, 1 Sep 2005 15:58:50 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Sep 2005 22:58:49 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C41@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Rob Enns Cc: "Netconf (E-mail)" Subject: RE: AD review for: draft-ietf-netconf-prot-07.txt Date: Thu, 1 Sep 2005 22:58:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk OK, looking forward to new revision > -----Original Message----- > From: Rob Enns [mailto:rpe@juniper.net] > Sent: Wednesday, August 31, 2005 13:46 > To: Wijnen, Bert (Bert) > Cc: Netconf (E-mail) > Subject: RE: AD review for: draft-ietf-netconf-prot-07.txt > > > Thank you for the thorough review, Bert. Unless otherwise noted, all > edits and clarifications you raise have been made to the > protocol draft. > > > > - what is the real difference between the examples > > in sections 6.2.3 and 6.2.4? > > I think I understand the differences between containment > > and seclection nodes, but the examples confuse me instead > > of helping me, because they are exactly the same and > > even the descritive text directly following each example > > is exactly the same. > > I agree, it doesn't help much as currently written. Given that > the filtering rules and role of the containment, selection, and > content match nodes are laid out in detail in section 6.2.5, and > 6.3, I think we can clean this up a little by trimming section > 6.2.3 down and limiting it to defining what a containment > node is. The descriptive text for the example in 6.2.3 is a > bit misleading, because the selection node also controls what > is included in the output, and that's not discussed until 6.2.4 > and 6.2.5. I will clean this up. > > > - not sure I understand (1st para sect 8) what "must be able to > > process and ignore..." means. Maybe you can explain to me, maybe > > it needs clarfication? > > The peer should ignore capabilities it does not understand. > I think it would be clearer to rewrite this as "... and MUST > ignore any capability received from the other peer that it > does not require or does not understand." > > > - sect 8.9.5.1 example > > Am I missing something? I do not understand "top" in that > > example. Could be me. > > In the fictional data model used in the draft, "top" is the > uppermost (or outermost) element. > > > - sect 10. IANA Considerations. > > I see just: TBD > > Well I think there are IANA considerations. > > Like a description of the registries (namespaces) to > > be created and to be maintained by IANA. Also rules about how > > new entries/assignments can be made (see RFC2434). > > Further I think that this document makes a set of registartions > > and so they should be listed here for IANA as the initial set > > of registrations to be administered/recorded. > > I will post proposed text for the IANA Considerations section > to the WG > list. > > > - I think I would change "Author's Address" into "Editor's Address" > > on page 68. Specifically cause I get the impression that > > Rob is editor > > and that there are quite a set of contributing authors, which you > > have listed separately (good). > > Agreed, although I haven't yet figured out how to make > xml2rfc do this. > > > - Has the XML Schema been validated for correct SYNTAX? > > Can you tell me which tool you used to do so? > > XMLSpy (http://www.altova.com) was used to validate the schema > and all examples against the schema. > > thanks, > 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: From owner-netconf@ops.ietf.org Fri Sep 02 17:07:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIkX-0005zf-7Y for netconf-archive@megatron.ietf.org; Fri, 02 Sep 2005 17:07:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02753 for ; Fri, 2 Sep 2005 17:06:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBIb4-000HrC-HL for netconf-data@psg.com; Fri, 02 Sep 2005 20:57:14 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EBIb2-000Hqr-DT for netconf@ops.ietf.org; Fri, 02 Sep 2005 20:57:12 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Fri, 2 Sep 2005 13:57:32 -0700 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C2C@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C2C@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6880BBD0-648A-4974-AA47-731B0059A9A3@icesoft.com> Cc: netconf Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: AD review: draft-ietf-netconf-soap-05 Date: Fri, 2 Sep 2005 14:57:08 -0600 To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.734) 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: 7bit Comments are inline: (Bert, thanks for the review and the XML Registry clarification; I've incorporated those suggestions below as well.) On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: > Hre is my AD review. Sorry that this one slipped through > the cracks and took a bit longer. I have also seen > the suggested changes (as per below email from Ted) and > will assume such changes will be made. > > A lot of the SOAP/WSDL stuff is completely new for me, > so pls bear with me if I ask newbee questions. > But I think we should assume that others who read the > documents may also be newbees, and so maybe we should at > least make it all clear in the document. > > - I do not see in the document how a session-id gets > passed from setting up a BEEP or HTTP conenction > to the NetConf protocol level so that NetConf can use > the session-id. Maybe it is there, but I do not see it. > Pls explain and clarify in the text. This is exchanged through messages. The opening sentence in 3.3 will be revised as follows: Capabilities exchange and session ID establishment are performed through the exchange of messages. > - sect 3.7 > - Is it OK to assume a "hypothetical location", or should we > decide and/or request IANA or xmlsoap.org to define a > real and approved location? IANA should be requested to provide a location for the NETCONF schema (in netconf-prot, I believe). How should netconf-soap be revised to accommodate an IANA request in netconf-prot? > - Have you (has anyone) done a SYNTAX check on the WSDL > document, and if so, which tool was used? The WSDL has been checked with xmllint against the xmlsoap.org schemas. > - In the WSDL document, there are www.iana.org items. > for example I see: > location="http://www.iana.org/assignments/xml-registry/ > schema/netconf-base_1.0.xsd"/> > WHere is that coming from. > Maybe that is to be found in the missing (i.e. TBD) text from > the netconf-protocol document? Both the namespace and the netconf schema location should be requested from IANA in the netconf-protocol document. The netconf-soap draft will be revised to request a netconf-soap namespace. The IANA is requested to assign an XML namespace for the NETCONF over SOAP WSDL definitions. > Another example > xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" > Does that need a citation/reference? This is the standard SOAP namespace as defined in the WSDL reference. > xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" > Does IANA now how to create that? Or is there no IANA > action needed for that? IANA action is needed (request described above). > There may be other stuff. Once I understand the above I can > check further and see if I have more questions. > > - IANA considerations Section > - says "IANA will". Maybe better: "IANA is requested to" > - Is the port for BEEP not already requested via the > netconf-over-beep document? This is a different usage of BEEP. netconf-beep does not use the SOAP BEEP mapping (rfc3288bis) but rather uses BEEP directly. > - Where is IANA supposed to put the WSDL definition? > you say in the XML registry. WHich is the document that > explains how to do that? Where is the ptr to the iana > we page that contains these sort of documents? This IANA request will be removed. > CItation/Reference issues: > > > !! Missing citation for Normative reference: > P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose > Internet Mail > > !! Missing citation for Normative reference: > P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose > Internet Mail > > !! Missing citation for Normative reference: > P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for > syslog", RFC 3195, > > !! Missing citation for Informative reference: > P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP > Messages with > > !! Missing citation for Informative reference: > P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and > R. Monzillo, "Web Extraneous references removed. > NITS: > > - Pls expand Acrionyms first time they are used. > For example BEEP in the abstract. > WSDL in 3rd para section 1. Expanded. > - Sect 2.5, last sentence. > you may want to add a citation (and reference) to the RFC(s) > that describes "chunking and persistent connections". Citation added (HTTP 1.1). > - I see sometimes "Reciever" and other times "Receiver". > I think it should be consistent: "Receiver" > - Security COnsiderations section: s/IPSec/IPsec/ Fixed. Thanks, Ted. > Bert > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner- >> netconf@ops.ietf.org]On >> Behalf Of Ted Goddard >> Sent: Tuesday, August 30, 2005 19:46 >> To: netconf >> Subject: proposed changes for draft-ietf-netconf-soap-06 >> >> >> >> Hi All, >> >> I would like to propose the following changes for the NETCONF SOAP >> draft in the indicated sections: >> >> >> Section 0 >> >> RFC 3978 boilerplate >> >> Section 2.4 BCP56: On the Use of HTTP as a Substrate >> >> It is also possible to respond to the concern on the re-use of >> port 80. A NETCONF SOAP service SHOULD be offered over a new >> standard port for NETCONF over SOAP (over HTTP) to >> be defined as requested in the IANA considerations of this >> document. >> >> Section 4 Security Considerations >> >> The IANA requested port SHOULD be used, as this provides a >> means >> for efficient firewall filtering during possible >> denial-of-service >> attacks. >> >> Section 5 IANA Considerations >> >> The IANA is requested to assign TCP ports for NETCONF for SOAP >> over HTTP and SOAP over BEEP. >> >> The IANA is requested to place netconf-soap_1.0.wsdl in the >> IANA XML registry. >> >> The following indicated ID-nits appear to be in error (xml2rfc >> output checked with "od -c"): >> >> tmp/draft-ietf-netconf-soap-05.txt(452): >> Line is too long: the offending characters are 'elope"' >> tmp/draft-ietf-netconf-soap-05.txt(464): >> Line is too long: the offending characters are >> 's:netconf:base:1.0">' >> >> >> Thanks, >> Ted. >> > > -- > 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: > -- 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: From owner-netconf@ops.ietf.org Fri Sep 02 17:15:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBIsD-0007JN-8z for netconf-archive@megatron.ietf.org; Fri, 02 Sep 2005 17:15:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03039 for ; Fri, 2 Sep 2005 17:14:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBInW-000LtN-Lu for netconf-data@psg.com; Fri, 02 Sep 2005 21:10:06 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EBInV-000LsN-1X for netconf@ops.ietf.org; Fri, 02 Sep 2005 21:10:05 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.4+Sun/8.13.4) with ESMTP id j82LA2EG008601; Fri, 2 Sep 2005 23:10:02 +0200 (CEST) From: Simon Leinen Message-ID: <17176.49066.800746.827986@diotima.switch.ch> Date: Fri, 2 Sep 2005 23:10:02 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fvuQWpQiwh" Content-Transfer-Encoding: 7bit To: netconf@ops.ietf.org Subject: IETF 63 NETCONF minutes X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --fvuQWpQiwh Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Here are the minutes from our last meeting, in ASCII format. You'll find the HTML version on http://ops.ietf.org/netconf/63/minutes.html as I have submitted it to the IETF secretariat. If you have any corrections or additions please send them to me. -- Simon. --fvuQWpQiwh Content-Type: text/plain Content-Disposition: inline; filename="minutes.txt" Content-Transfer-Encoding: quoted-printable NETCONF WG Minutes, IETF 63 IETF 63, Paris Thursday, 4 August 2005, 0900-1000, room 341 Chairs: Simon Leinen, Andy Bierman (participating remotely) Scribes: Eliot Lear (Jabber), Dan Romascanu (off-line) Minutes: Simon Leinen. This was the 8th meeting of the WG (including the interim). Document Status AD Feedback on Submitted Documents All 4 WG documents (prot, ssh, beep, soap) were submitted for publication. Bert Wijnen, the Area Director in charge of our WG, already provided some feedback. Besides a few minor bugs, Bert noticed that the prot document had a null IANA considerations section although it seems clear that the document does have IANA considerations. This issue may require discussion. "You may need/want a few registries". Grouping of Documents for Publication On the way through the approval process towards RFC publication, the prot and ssh documents should be treated together, while the beep and soap documents should advance separately. Interoperability Testing MOME had an interoperability testing event last week, featuring nsis/ipfix/netconf. There were four netconf implementations present, two from commercial vendors and two from academic institutions. As a participant in the tests, James Hong provided some feedback. Data Model Since there is no standard NETCONF data model, an ad-hoc one was defined for the tests. Some incompatibilities on the data model level were found between the implementations. In addition, the data model used for testing concerned interfaces. This made testing difficult, as successful configuration changes would typically break connectivity to the NETCONF agent. SSH Mapping Only the mandatory SSH mapping was tested. Participants reported there were small issues getting SSH to interoperate, in particular the message separator and the use of SSH subsystems posed problems. As these particular parts of the SSH mapping were modified during the WG process, the issues may be the result of implementations initially based on earlier versions of the specification, rather than issues with the current specification. Two agent implementations lacked SSH transport and weren't tested. there was one SOAP implementation. we felt it would have been easier to test. we did NOT really test edit-config. Pipelining According to James Hong, there were issues on how to handle "pipelined" requests. In the absence of the principal prot authors, this stirred some discussion on whether request pipelining is in fact permitted by the protocol as currently specified. Although each message can only contain a single element, and each element only a single method call, pipelining is explicitly permitted in the sense that an additional request may be send before the response was read. The organizers will forward a summary to the NETCONF mailing list. Discussion Dan Romascanu: Are there any recommendations for what the data model should include regarding future work=3F Simon: Having guidelines would be helpful. Sharon asked how the ad-hoc data model was described. James Hong said that the common model was a very simple XSD. Bert has a generally positive impression from the results of the interoperability tests. There didn't seem to be any major problems with the protocol itself. Charter Discussion Status With Respect to Current Charter and Options for Going Forward Simon reminds that the charter is a contract between the Working Group and the IETF. We have completed our current action items, but we have unmet goals, specifically around (fine-grained) locking and notifications. Notifications once were in the protocol but were dropped. The current charter also talks about XML usage guidelines that the group should develop, but this is very open ended - we should consider scope. Access control is another area that (like locking) was deferred because of interactions with the data model. Simon listed several possible ways to go forward: * "declare victory and go home" * finish notifications (to fulfill charter to the letter)=3F * go dormant until we have enough implementation experience and operating experience and then review. Lastly, the big question is whether or not to take on data modeling, and if so what would the scope of that work be=3F Sharon's "NETCONF Phase 2 Musing" (see slides) Sharon presents her view of NETCONF development. Phase one has been completed now. Primary focus for protocol is on configuration, but we shouldn't preclude discussion on other forms of management, such as monitoring. Notifications are useful for informing operators when a configuration has changed, as well as for security auditing purposes. There is a draft available on an "SMI" for NETCONF. The intent is to foster interoperability without creating unnecessary rules. We should be careful as to what - if anything - gtes taken forward from the SNMP SMI. As a proof of concept, there is an initial set of definitions for reusable application-level data types. There is also a definition of a schema for NETCONF reporting - which could be turned into a configuration schema. Other areas to work on include asynchronous messaging/event notification, access control, a method for deliverying software loads for NETCONF, and a method for multi-channel support. Some of this will have to be moved to a phase 3/phase N. As next steps, Sharon proposes that the NETCONF event and data modeling work be added to the NETCONF charter as phase 2. Other work can be added as there is interest and resources available. Discussion Gauging Interest in Additional Work and Experience with Existing Protocol Simon: we must update the charter, and that charter will receive review by AD and IESG, and (provided IESG accepts it) the IETF. He asks Bert about his and the IESG's decision criteria. Bert responds that the normal criteria apply, such as the need for significant interest etc. But first he has a few questions to the room: Bert asks the attendees Concerning any of the proposed new work items - who is in favor of those=3F About 10-12 people. Among these people, who has an implementation of NETCONF (including the SSH mapping)=3F Hardly any positive response, although one proponent claimed an implementation-in-progress. Bert points out that the one person in the room who was at the interoperability event last week didn't raise his hand. Bert has an issue with the fact that the people who want to add work items haven't worked on or experimented with implementations of what we have defined right now. Dan Romascanu is in favor of additional work in the data model area in particular. The absence of a data model and the consequent lack of interoperability is a problem when talking about NETCONF both with customers and internally (about a proprietary system that could be migrated to a NETCONF base). He did not raise his hand on the second question because his company does not write protocols; they expect commercial or public domain products to become available, and are already experimenting with what's available. Bert has more questions for the proponents of additional work items: How many of you have downloaded and experimented with the publicly available implementations=3F Still only a subset of the 10-12. How many have actually been working with operators to see if they'll use this protocol=3F A relatively large number. However it's not clear how useful this kind of feedback is until operators actually had the opportunity of playing with implementations. Bert reminds the group that we got here because operators weren't using many of the features that were added to SNMP over the years, such as writable MIBs, and he wants to be very prudent that we not miss the operators again. Through the OPS directorate, we asked operators - who made us start this work because they weren't happy with SNMP - to review the work and play with this stuff and make sure we've done the right thing before put in additional person-years to continue to develop this work. Please get other operators to comment. Sharon: We have a preliminary implementation we've put in front of operators and they like the direction. Notifications/Asynchronous Messaging Sharon: Every single project group asks about asynchronous messaging=2E If we don't standardize asynchronous messaging, we'll have an interoperability mess in a few years as vendors will do their own thing. "Asynchronous messaging" describes a subscription-based information retrieval model as opposed to a poll/response one. A lot of applications - not just configuration-related - need this, but often it is used for supporting the bigger picture of configuration management. Sharon avoids the word "notifications" because people often think about the specific SNMP mechanism. Kathleen Moriarty shares some thoughts from the perspective of a NETCONF customer, a large enterprise network and operator of various IPS (Intrusion Prevention Systems) from different vendors. Central management based on open standards would be very useful. Regulations such as Sarbanes-Oxley or the Federal Information Security Management Act (FISMA) mandate auditability of what changes were made when and by whom. A requirement for implementing NETCONF would be an open standard to do rollbacks. Another trend is to automate changes and rollbacks. Andy points out that detailed audit logs are different from rollback; NETCONF provides some rollback, but no auditing. Simon hears this as another request for notifications. Existing configuration systems that we use already have very good notifications for configuration-related events, using SNMP traps/notifications and syslog. SNMP traps and syslog are perceived as too hard to integrate with configuration applications, so it seems attractive to integrate this into the NETCONF protocol. But we're not the only ones having this problem! He agrees with Andy that this group could work on notifications, but maybe we would duplicate existing work, or do work that should better be done elsewhere. David Martin points out that although we decided early on that Web Services would be too heavy for NETCONF, it may be worthwhile to look at WS work in the area of notifications. Andy reminds the group that the original NETCONF proposal was to use reliable syslog (RFC 3195), and explicitly not to invent anything new. Juergen Schoenwaelder cautions that RFC 3195 has not seen widespread use in the almost four years since it was published. Sharon was involved in the syslog stuff, trawled through the Web Services stuff, and also looked at event subscription in SIP. The intent is not to invent unnecessarily. Dave Perkins: On the auditing issue, we have a management application has the identity when you do a transaction. the user who pressed the button is not captured. [proxied discussion] Darren Loher agrees with Andy's comment that an event system such as reliable syslog would be extremely valuable in general. Andy isn't sure whether RFC 3195 is the right choice, but he wants to avoid reinvention if possible Data Model (and more on Notifications...) Azita Kia: On the data model, and that there was a lot of work done in SNMP. NETCONF has been successful so far, but without a data model, it's just a protocol to exchange generic data. Creating a data model is a very big task. Can we do some incremental work, leveraging the wealth of SMI definitions and MIBs that have already been done, by XMLizing some of those=3F Simon concedes that this could be a way forward, but also notes that MIBS and SNMP haven't been very successful for configuration. Jim Golvinsky: Not having a reference data model makes the protocol useless. We end up with N-square integration points. I'm going to be flamed now. He finds notifications important, but is concerned that we would be ignoring all the work that has been done in Web Services and also in the DMTF. Glenn Waters opines that the only way to build an integrated solution is to include notifications. Without them the protocol has a big hole. As to data models, we currently don't have a language to talk about data modeling. It's not sufficient to say "XML Schema". We need an SMI for XML, and need those rules to be put down in a single document. And we have to develop the language and then push the data model. Closing Remarks of our Area Director Bert says that in the past we've often heard "I'm channeling my customer's requirements." While I understand that few customers can make it here, we need to hear from them. I am willing to keep those communications private, but I'd like to hear from them. This was done because operators had expressed discontent with what was there, so they should be expected to review and comment. --fvuQWpQiwh-- -- 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: From owner-netconf@ops.ietf.org Fri Sep 02 20:21:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBLn2-00023k-1I for netconf-archive@megatron.ietf.org; Fri, 02 Sep 2005 20:21:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20662 for ; Fri, 2 Sep 2005 20:21:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBLe6-000IgP-KQ for netconf-data@psg.com; Sat, 03 Sep 2005 00:12:34 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EBLe3-000Ig5-5C for netconf@ops.ietf.org; Sat, 03 Sep 2005 00:12:31 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j830CF8k010538; Fri, 2 Sep 2005 17:12:20 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Sep 2005 17:14:32 -0700 Message-ID: From: "McDonald, Ira" To: "'Ted Goddard'" , "Wijnen, Bert (Bert)" Cc: netconf Subject: RE: AD review: draft-ietf-netconf-soap-05 Date: Fri, 2 Sep 2005 17:14:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" 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 Hi, I see (belatedly) that your WSDL is v1.1 (not a standard and never will be a standard). For what it's worth, the printing industry has experienced real trouble building interoperable SOAP-based implementations using WSDL/1.1 (the existing tools that generate the SOAP are wildly incompatible) in our recent PSI/1.0 (Print Services Interface) project in the IEEE/ISTO Printer Working Group organization. I seriously urge you to abandon entirely the WSDL specification for NetConf. It's only informative anyway (because WSDL/1.1 isn't standards track at W3C). Cheers, - Ira (co-editor of PSI/1.0). Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Ted Goddard > Sent: Friday, September 02, 2005 4:57 PM > To: Wijnen, Bert (Bert) > Cc: netconf > Subject: Re: AD review: draft-ietf-netconf-soap-05 > > > > Comments are inline: > (Bert, thanks for the review and the XML Registry clarification; > I've incorporated those suggestions below as well.) > > On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: > > > Hre is my AD review. Sorry that this one slipped through > > the cracks and took a bit longer. I have also seen > > the suggested changes (as per below email from Ted) and > > will assume such changes will be made. > > > > A lot of the SOAP/WSDL stuff is completely new for me, > > so pls bear with me if I ask newbee questions. > > But I think we should assume that others who read the > > documents may also be newbees, and so maybe we should at > > least make it all clear in the document. > > > > - I do not see in the document how a session-id gets > > passed from setting up a BEEP or HTTP conenction > > to the NetConf protocol level so that NetConf can use > > the session-id. Maybe it is there, but I do not see it. > > Pls explain and clarify in the text. > > This is exchanged through messages. The opening sentence > in 3.3 will be revised as follows: > > Capabilities exchange and session ID establishment are performed > through the exchange of messages. > > > - sect 3.7 > > - Is it OK to assume a "hypothetical location", or should we > > decide and/or request IANA or xmlsoap.org to define a > > real and approved location? > > IANA should be requested to provide a location for the NETCONF > schema (in netconf-prot, I believe). How should netconf-soap > be revised to accommodate an IANA request in netconf-prot? > > > - Have you (has anyone) done a SYNTAX check on the WSDL > > document, and if so, which tool was used? > > The WSDL has been checked with xmllint against the xmlsoap.org > schemas. > > > - In the WSDL document, there are www.iana.org items. > > for example I see: > > > location="http://www.iana.org/assignments/xml-registry/ > > schema/netconf-base_1.0.xsd"/> > > WHere is that coming from. > > Maybe that is to be found in the missing (i.e. TBD) text from > > the netconf-protocol document? > > Both the namespace and the netconf schema location should be > requested from IANA in the netconf-protocol document. The > netconf-soap draft will be revised to request a netconf-soap > namespace. > > The IANA is requested to assign an XML namespace for the NETCONF > over SOAP WSDL definitions. > > > > Another example > > xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" > > Does that need a citation/reference? > > This is the standard SOAP namespace as defined in the WSDL reference. > > > xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" > > Does IANA now how to create that? Or is there no IANA > > action needed for that? > > IANA action is needed (request described above). > > > There may be other stuff. Once I understand the above I can > > check further and see if I have more questions. > > > > - IANA considerations Section > > - says "IANA will". Maybe better: "IANA is requested to" > > - Is the port for BEEP not already requested via the > > netconf-over-beep document? > > This is a different usage of BEEP. netconf-beep does not use > the SOAP BEEP mapping (rfc3288bis) but rather uses BEEP directly. > > > - Where is IANA supposed to put the WSDL definition? > > you say in the XML registry. WHich is the document that > > explains how to do that? Where is the ptr to the iana > > we page that contains these sort of documents? > > This IANA request will be removed. > > > CItation/Reference issues: > > > > > > !! Missing citation for Normative reference: > > P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for > > syslog", RFC 3195, > > > > !! Missing citation for Informative reference: > > P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP > > Messages with > > > > !! Missing citation for Informative reference: > > P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and > > R. Monzillo, "Web > > Extraneous references removed. > > > NITS: > > > > - Pls expand Acrionyms first time they are used. > > For example BEEP in the abstract. > > WSDL in 3rd para section 1. > > Expanded. > > > - Sect 2.5, last sentence. > > you may want to add a citation (and reference) to the RFC(s) > > that describes "chunking and persistent connections". > > Citation added (HTTP 1.1). > > > - I see sometimes "Reciever" and other times "Receiver". > > I think it should be consistent: "Receiver" > > - Security COnsiderations section: s/IPSec/IPsec/ > > Fixed. > > Thanks, > Ted. > > > Bert > > > > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org [mailto:owner- > >> netconf@ops.ietf.org]On > >> Behalf Of Ted Goddard > >> Sent: Tuesday, August 30, 2005 19:46 > >> To: netconf > >> Subject: proposed changes for draft-ietf-netconf-soap-06 > >> > >> > >> > >> Hi All, > >> > >> I would like to propose the following changes for the NETCONF SOAP > >> draft in the indicated sections: > >> > >> > >> Section 0 > >> > >> RFC 3978 boilerplate > >> > >> Section 2.4 BCP56: On the Use of HTTP as a Substrate > >> > >> It is also possible to respond to the concern on the > re-use of > >> port 80. A NETCONF SOAP service SHOULD be offered over a new > >> standard port for NETCONF over SOAP (over HTTP) to > >> be defined as requested in the IANA considerations of this > >> document. > >> > >> Section 4 Security Considerations > >> > >> The IANA requested port SHOULD be used, as this provides a > >> means > >> for efficient firewall filtering during possible > >> denial-of-service > >> attacks. > >> > >> Section 5 IANA Considerations > >> > >> The IANA is requested to assign TCP ports for > NETCONF for SOAP > >> over HTTP and SOAP over BEEP. > >> > >> The IANA is requested to place netconf-soap_1.0.wsdl in the > >> IANA XML registry. > >> > >> The following indicated ID-nits appear to be in error (xml2rfc > >> output checked with "od -c"): > >> > >> tmp/draft-ietf-netconf-soap-05.txt(452): > >> Line is too long: the offending characters are 'elope"' > >> tmp/draft-ietf-netconf-soap-05.txt(464): > >> Line is too long: the offending characters are > >> 's:netconf:base:1.0">' > >> > >> > >> Thanks, > >> Ted. > >> > > > > -- > > 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: > > > > > > -- > 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: > -- 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: From owner-netconf@ops.ietf.org Sat Sep 03 13:57:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBcGS-000665-7n for netconf-archive@megatron.ietf.org; Sat, 03 Sep 2005 13:57:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17054 for ; Sat, 3 Sep 2005 13:57:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBc78-000MCg-AP for netconf-data@psg.com; Sat, 03 Sep 2005 17:47:38 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EBc76-000MCP-5s for netconf@ops.ietf.org; Sat, 03 Sep 2005 17:47:36 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j83HlWjA026224; Sat, 3 Sep 2005 12:47:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 3 Sep 2005 19:47:32 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0F1E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ted Goddard Cc: netconf Subject: RE: AD review: draft-ietf-netconf-soap-05 Date: Sat, 3 Sep 2005 19:47:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: Ted Goddard [mailto:ted.goddard@icesoft.com] > Sent: Friday, September 02, 2005 17:57 > To: Wijnen, Bert (Bert) > Cc: netconf > Subject: Re: AD review: draft-ietf-netconf-soap-05 > > > > Comments are inline: > (Bert, thanks for the review and the XML Registry clarification; > I've incorporated those suggestions below as well.) > > On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: > > > Hre is my AD review. Sorry that this one slipped through > > the cracks and took a bit longer. I have also seen > > the suggested changes (as per below email from Ted) and > > will assume such changes will be made. > > > > A lot of the SOAP/WSDL stuff is completely new for me, > > so pls bear with me if I ask newbee questions. > > But I think we should assume that others who read the > > documents may also be newbees, and so maybe we should at > > least make it all clear in the document. > > > > - I do not see in the document how a session-id gets > > passed from setting up a BEEP or HTTP conenction > > to the NetConf protocol level so that NetConf can use > > the session-id. Maybe it is there, but I do not see it. > > Pls explain and clarify in the text. > > This is exchanged through messages. The opening sentence > in 3.3 will be revised as follows: > > Capabilities exchange and session ID establishment are performed > through the exchange of messages. > Would be good to have an example of such exchange, so that people can clearly see how it is done. > > - sect 3.7 > > - Is it OK to assume a "hypothetical location", or should we > > decide and/or request IANA or xmlsoap.org to define a > > real and approved location? > > IANA should be requested to provide a location for the NETCONF > schema (in netconf-prot, I believe). How should netconf-soap > be revised to accommodate an IANA request in netconf-prot? > The pieces that netconf-prot needs to get registered is the task of the netconf-prot document. I did challenge them on the TBD in their IANA considerations section. If you use/need reference to those registered namespaces, then do indeed reference them and add some (commentary if needed) text that explains it. > > - Have you (has anyone) done a SYNTAX check on the WSDL > > document, and if so, which tool was used? > > The WSDL has been checked with xmllint against the xmlsoap.org > schemas. > Might want to document that, so that people know. Just a simple comment is fine. > > - In the WSDL document, there are www.iana.org items. > > for example I see: > > > location="http://www.iana.org/assignments/xml-registry/ > > schema/netconf-base_1.0.xsd"/> > > WHere is that coming from. > > Maybe that is to be found in the missing (i.e. TBD) text from > > the netconf-protocol document? > > Both the namespace and the netconf schema location should be > requested from IANA in the netconf-protocol document. The > netconf-soap draft will be revised to request a netconf-soap > namespace. > > The IANA is requested to assign an XML namespace for the NETCONF > over SOAP WSDL definitions. > Good. The above is not good enuf though. When you request a namespace, then pls also add some rules and guidelines for IANA that explain how and what IANA can add to the namespace later. Read RFC2434 about that. > > > Another example > > xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" > > Does that need a citation/reference? > > This is the standard SOAP namespace as defined in the WSDL reference. > One way or another, pls add that to the doc. Either as prelimenary text before the WSDL document or as comments inside the document. Maybe I am asking too much here, because I know little about WSDL. If the WG feels no ptrs/references are needed, I will live with it. > > xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" > > Does IANA now how to create that? Or is there no IANA > > action needed for that? > > IANA action is needed (request described above). > > > There may be other stuff. Once I understand the above I can > > check further and see if I have more questions. > > > > - IANA considerations Section > > - says "IANA will". Maybe better: "IANA is requested to" > > - Is the port for BEEP not already requested via the > > netconf-over-beep document? > > This is a different usage of BEEP. netconf-beep does not use > the SOAP BEEP mapping (rfc3288bis) but rather uses BEEP directly. > Oh well... > > - Where is IANA supposed to put the WSDL definition? > > you say in the XML registry. WHich is the document that > > explains how to do that? Where is the ptr to the iana > > we page that contains these sort of documents? > > This IANA request will be removed. > OK > > CItation/Reference issues: > > > > > > !! Missing citation for Normative reference: > > P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose > > Internet Mail > > > > !! Missing citation for Normative reference: > > P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for > > syslog", RFC 3195, > > > > !! Missing citation for Informative reference: > > P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP > > Messages with > > > > !! Missing citation for Informative reference: > > P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and > > R. Monzillo, "Web > > Extraneous references removed. > Good > > NITS: > > > > - Pls expand Acrionyms first time they are used. > > For example BEEP in the abstract. > > WSDL in 3rd para section 1. > > Expanded. > Good. I hope you understood I just listed a few examples. Pls check all acronyms. > > - Sect 2.5, last sentence. > > you may want to add a citation (and reference) to the RFC(s) > > that describes "chunking and persistent connections". > > Citation added (HTTP 1.1). > OK > > - I see sometimes "Reciever" and other times "Receiver". > > I think it should be consistent: "Receiver" > > - Security COnsiderations section: s/IPSec/IPsec/ > > Fixed. > Good, Thanks, Bert > Thanks, > Ted. > > > Bert > > > > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org [mailto:owner- > >> netconf@ops.ietf.org]On > >> Behalf Of Ted Goddard > >> Sent: Tuesday, August 30, 2005 19:46 > >> To: netconf > >> Subject: proposed changes for draft-ietf-netconf-soap-06 > >> > >> > >> > >> Hi All, > >> > >> I would like to propose the following changes for the NETCONF SOAP > >> draft in the indicated sections: > >> > >> > >> Section 0 > >> > >> RFC 3978 boilerplate > >> > >> Section 2.4 BCP56: On the Use of HTTP as a Substrate > >> > >> It is also possible to respond to the concern on the > re-use of > >> port 80. A NETCONF SOAP service SHOULD be offered over a new > >> standard port for NETCONF over SOAP (over HTTP) to > >> be defined as requested in the IANA considerations of this > >> document. > >> > >> Section 4 Security Considerations > >> > >> The IANA requested port SHOULD be used, as this provides a > >> means > >> for efficient firewall filtering during possible > >> denial-of-service > >> attacks. > >> > >> Section 5 IANA Considerations > >> > >> The IANA is requested to assign TCP ports for > NETCONF for SOAP > >> over HTTP and SOAP over BEEP. > >> > >> The IANA is requested to place netconf-soap_1.0.wsdl in the > >> IANA XML registry. > >> > >> The following indicated ID-nits appear to be in error (xml2rfc > >> output checked with "od -c"): > >> > >> tmp/draft-ietf-netconf-soap-05.txt(452): > >> Line is too long: the offending characters are 'elope"' > >> tmp/draft-ietf-netconf-soap-05.txt(464): > >> Line is too long: the offending characters are > >> 's:netconf:base:1.0">' > >> > >> > >> Thanks, > >> Ted. > >> > > > > -- > > 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: > > > > -- 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: From owner-netconf@ops.ietf.org Sun Sep 04 11:27:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBwPX-0002k6-3Q for netconf-archive@megatron.ietf.org; Sun, 04 Sep 2005 11:27:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11440 for ; Sun, 4 Sep 2005 11:27:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBwGC-0008bV-Gw for netconf-data@psg.com; Sun, 04 Sep 2005 15:18:20 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EBwGA-0008bI-9S for netconf@ops.ietf.org; Sun, 04 Sep 2005 15:18:18 +0000 Received: (qmail 27486 invoked by uid 78); 4 Sep 2005 15:18:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail.networksolutionsemail.com with SMTP; 4 Sep 2005 15:18:17 -0000 Message-ID: <431B0FBC.2000802@andybierman.com> Date: Sun, 04 Sep 2005 08:16:12 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Ted Goddard'" , "Wijnen, Bert (Bert)" , netconf Subject: Re: AD review: draft-ietf-netconf-soap-05 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit McDonald, Ira wrote: >Hi, > >I see (belatedly) that your WSDL is v1.1 (not a standard and >never will be a standard). For what it's worth, the printing >industry has experienced real trouble building interoperable >SOAP-based implementations using WSDL/1.1 (the existing tools >that generate the SOAP are wildly incompatible) in our recent >PSI/1.0 (Print Services Interface) project in the IEEE/ISTO >Printer Working Group organization. > >I seriously urge you to abandon entirely the WSDL specification >for NetConf. It's only informative anyway (because WSDL/1.1 >isn't standards track at W3C). > > Is there a WSDL spec that is a somewhat stable standard? I would rather keep the text as non-normative than remove it. Informative text is a Good Thing in a document intended to help SW developers implement a protocol specification. >Cheers, >- Ira (co-editor of PSI/1.0). > > Andy -- 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: From owner-netconf@ops.ietf.org Sun Sep 04 13:05:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxvz-00036u-M2 for netconf-archive@megatron.ietf.org; Sun, 04 Sep 2005 13:05:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14366 for ; Sun, 4 Sep 2005 13:05:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBxnG-000KMe-80 for netconf-data@psg.com; Sun, 04 Sep 2005 16:56:34 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EBxnD-000KM8-Fl for netconf@ops.ietf.org; Sun, 04 Sep 2005 16:56:31 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j84GuLjP005000; Sun, 4 Sep 2005 09:56:21 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 4 Sep 2005 09:58:41 -0700 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , "McDonald, Ira" Cc: "'Ted Goddard'" , "Wijnen, Bert (Bert)" , netconf Subject: RE: AD review: draft-ietf-netconf-soap-05 Date: Sun, 4 Sep 2005 09:58:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" 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 Hi Andy, See the W3C's Web Services Description Working Group http://www.w3.org/2002/ws/desc/ All of their WSDL/2.0 specs are now in second Last Call (ending 19 September 2005). WSDL/2.0 is _NOT_ compatible with WSDL/1.1 (thus the major version change), because it was deemed impossible to achieve compatibility in a meaningful way with the widespread ambiguities of WSDL/1.1 specs and implementations. FWIW, no two printer vendors implementing PSI/1.0 ever successfully interoperated at all without hand tweaking the SOAP emitted by their WSDL/1.1 tools. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Sunday, September 04, 2005 11:16 AM > To: McDonald, Ira > Cc: 'Ted Goddard'; Wijnen, Bert (Bert); netconf > Subject: Re: AD review: draft-ietf-netconf-soap-05 > > > McDonald, Ira wrote: > > >Hi, > > > >I see (belatedly) that your WSDL is v1.1 (not a standard and > >never will be a standard). For what it's worth, the printing > >industry has experienced real trouble building interoperable > >SOAP-based implementations using WSDL/1.1 (the existing tools > >that generate the SOAP are wildly incompatible) in our recent > >PSI/1.0 (Print Services Interface) project in the IEEE/ISTO > >Printer Working Group organization. > > > >I seriously urge you to abandon entirely the WSDL specification > >for NetConf. It's only informative anyway (because WSDL/1.1 > >isn't standards track at W3C). > > > > > > Is there a WSDL spec that is a somewhat stable standard? > I would rather keep the text as non-normative than remove it. > Informative text is a Good Thing in a document intended to help > SW developers implement a protocol specification. > > >Cheers, > >- Ira (co-editor of PSI/1.0). > > > > > > Andy > -- 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: From owner-netconf@ops.ietf.org Tue Sep 06 07:06:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECbHS-0002ZP-Ne for netconf-archive@megatron.ietf.org; Tue, 06 Sep 2005 07:06:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20407 for ; Tue, 6 Sep 2005 07:06:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECb6j-000CBD-67 for netconf-data@psg.com; Tue, 06 Sep 2005 10:55:17 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ECb6h-000CAo-FY for netconf@ops.ietf.org; Tue, 06 Sep 2005 10:55:15 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2005 03:55:16 -0700 X-IronPort-AV: i="3.96,170,1122879600"; d="scan'208"; a="209864823:sNHT29157624" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j86AtAZ1029779; Tue, 6 Sep 2005 03:55:10 -0700 (PDT) Received: from [144.254.23.103] (dhcp-data-vlan10-23-103.cisco.com [144.254.23.103]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j86AoRNd024562; Tue, 6 Sep 2005 03:50:28 -0700 Message-ID: <431D758D.9060509@cisco.com> Date: Tue, 06 Sep 2005 12:55:09 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf CC: "Ken Crozier \(kcrozier\)" Subject: draft-ietf-netconf-beep-06.txt X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=168; t=1126003829; x=1126436029; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:draft-ietf-netconf-beep-06.txt| From:Eliot=20Lear=20| Date:Tue,=2006=20Sep=202005=2012=3A55=3A09=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=V3+3quQd3hOVnzU/aYiNU1RVuZ5UKIrJn958Aq0+kLLtxdg3Y2Z0v3D/B51cd143zCenEbMB gaF4pTdlxIzzkaPtSDwElZrVGc5jH+wxrf8sx9nUZHcFOA0/Xg4nCCx/BUkQlFfW50l9WCaOkpY DayXMNA7pW6ObINyUwCTIZ5s= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I submitted this draft today in response to Bert's AD comments (TLA expansion earlier, IANA fixes, FF fixes). It passes idnits without complaint. Should show up in drafts directory in a day or so. Eliot -- 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: From owner-netconf@ops.ietf.org Wed Sep 07 16:01:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED66g-0005AM-QK for netconf-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:01:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14122 for ; Wed, 7 Sep 2005 16:01:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED5vs-0001I7-0j for netconf-data@psg.com; Wed, 07 Sep 2005 19:50:08 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ED5vm-0001Ff-Qh for netconf@ops.ietf.org; Wed, 07 Sep 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ED5vl-0005I8-UD; Wed, 07 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-beep-06.txt Message-Id: Date: Wed, 07 Sep 2005 15:50:01 -0400 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=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) Author(s) : E. Lear, K. Crozier Filename : draft-ietf-netconf-beep-06.txt Pages : 14 Date : 2005-9-7 This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-beep-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-beep-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-7150659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-beep-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-beep-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-7150659.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Thu Sep 08 19:07:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVUW-00075I-5K for netconf-archive@megatron.ietf.org; Thu, 08 Sep 2005 19:07:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28050 for ; Thu, 8 Sep 2005 19:07:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDVHf-000KMs-GR for netconf-data@psg.com; Thu, 08 Sep 2005 22:54:19 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EDVHd-000KLR-7V for netconf@ops.ietf.org; Thu, 08 Sep 2005 22:54:17 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Thu, 8 Sep 2005 15:54:34 -0700 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507EE0F1E@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507EE0F1E@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: AD review: draft-ietf-netconf-soap-05 Date: Thu, 8 Sep 2005 16:54:12 -0600 To: "Wijnen, Bert (Bert)" , netconf X-Mailer: Apple Mail (2.734) 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: 7bit Comments are inline Should a new draft be issued given the changes indicated below? On 3-Sep-05, at 11:47 AM, Wijnen, Bert (Bert) wrote: > Inline > > >> -----Original Message----- >> From: Ted Goddard [mailto:ted.goddard@icesoft.com] >> Sent: Friday, September 02, 2005 17:57 >> To: Wijnen, Bert (Bert) >> Cc: netconf >> Subject: Re: AD review: draft-ietf-netconf-soap-05 >> >> >> >> Comments are inline: >> (Bert, thanks for the review and the XML Registry clarification; >> I've incorporated those suggestions below as well.) >> >> On 1-Sep-05, at 1:32 PM, Wijnen, Bert (Bert) wrote: >> >> >>> Hre is my AD review. Sorry that this one slipped through >>> the cracks and took a bit longer. I have also seen >>> the suggested changes (as per below email from Ted) and >>> will assume such changes will be made. >>> >>> A lot of the SOAP/WSDL stuff is completely new for me, >>> so pls bear with me if I ask newbee questions. >>> But I think we should assume that others who read the >>> documents may also be newbees, and so maybe we should at >>> least make it all clear in the document. >>> >>> - I do not see in the document how a session-id gets >>> passed from setting up a BEEP or HTTP conenction >>> to the NetConf protocol level so that NetConf can use >>> the session-id. Maybe it is there, but I do not see it. >>> Pls explain and clarify in the text. >>> >> >> This is exchanged through messages. The opening sentence >> in 3.3 will be revised as follows: >> >> Capabilities exchange and session ID establishment are performed >> through the exchange of messages. >> >> > > Would be good to have an example of such exchange, so that people can > clearly see how it is done. An example that shows the necessary client/server roles when HTTP is used has been added. > >>> - sect 3.7 >>> - Is it OK to assume a "hypothetical location", or should we >>> decide and/or request IANA or xmlsoap.org to define a >>> real and approved location? >>> >> >> IANA should be requested to provide a location for the NETCONF >> schema (in netconf-prot, I believe). How should netconf-soap >> be revised to accommodate an IANA request in netconf-prot? >> >> > > The pieces that netconf-prot needs to get registered is the task > of the netconf-prot document. I did challenge them on the TBD > in their IANA considerations section. > > If you use/need reference to those registered namespaces, then > do indeed reference them and add some (commentary if needed) > text that explains it. A reference to these namespaces being subject to IANA consideration for the NETCONF protocol has been added. The following WSDL document assumes a hypothetical location for the NETCONF schema and a hypothetical identifier for the NETCONF namespace, subject to IANA considerations for the NETCONF [1] protocol. > >>> - Have you (has anyone) done a SYNTAX check on the WSDL >>> document, and if so, which tool was used? >>> >> >> The WSDL has been checked with xmllint against the xmlsoap.org >> schemas. >> >> > Might want to document that, so that people know. Just a simple > comment is fine. Comment and reference to xmllint added. It is valid as verified by the xmlsoft.org tool xmllint against the standard WSDL [15] xmlsoap.org schemas referenced by the "SOAP" and default namespace declarations below. > >>> - In the WSDL document, there are www.iana.org items. >>> for example I see: >>> >> location="http://www.iana.org/assignments/xml-registry/ >>> schema/netconf-base_1.0.xsd"/> >>> WHere is that coming from. >>> Maybe that is to be found in the missing (i.e. TBD) text from >>> the netconf-protocol document? >>> >> >> Both the namespace and the netconf schema location should be >> requested from IANA in the netconf-protocol document. The >> netconf-soap draft will be revised to request a netconf-soap >> namespace. >> >> The IANA is requested to assign an XML namespace for the NETCONF >> over SOAP WSDL definitions. >> >> > Good. The above is not good enuf though. > When you request a namespace, then pls also add some rules > and guidelines for IANA that explain how and what IANA can add > to the namespace later. Read RFC2434 about that. Added a comment that namespace additions should follow the "Specification Required" policy -- it is not necessary for third parties to add to this namespace as XML allows them to simply declare their own namespaces. The IANA is requested to assign an XML namespace for the NETCONF over SOAP WSDL definitions. Following the policies outlined in RFC 2434 [14], assigned values in this namespace are allocated according to the "Specification Required" policy. > >> >> >>> Another example >>> xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" >>> Does that need a citation/reference? >>> >> >> This is the standard SOAP namespace as defined in the WSDL reference. >> >> > > One way or another, pls add that to the doc. Either as prelimenary > text before the WSDL document or as comments inside the document. > Maybe I am asking too much here, because I know little about WSDL. > If the WG feels no ptrs/references are needed, I will live with it. Comment added with WSDL validity comment above. > >>> xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" >>> Does IANA now how to create that? Or is there no IANA >>> action needed for that? >>> >> >> IANA action is needed (request described above). >> >> >>> There may be other stuff. Once I understand the above I can >>> check further and see if I have more questions. >>> >>> - IANA considerations Section >>> - says "IANA will". Maybe better: "IANA is requested to" >>> - Is the port for BEEP not already requested via the >>> netconf-over-beep document? >>> >> >> This is a different usage of BEEP. netconf-beep does not use >> the SOAP BEEP mapping (rfc3288bis) but rather uses BEEP directly. >> >> > > Oh well... > > >>> - Where is IANA supposed to put the WSDL definition? >>> you say in the XML registry. WHich is the document that >>> explains how to do that? Where is the ptr to the iana >>> we page that contains these sort of documents? >>> >> >> This IANA request will be removed. >> >> > OK > > >>> CItation/Reference issues: >>> >>> >>> !! Missing citation for Normative reference: >>> P018 L030: [5] Freed, N. and N. Borenstein, "Multipurpose >>> Internet Mail >>> >>> !! Missing citation for Normative reference: >>> P018 L034: [6] Freed, N. and N. Borenstein, "Multipurpose >>> Internet Mail >>> >>> !! Missing citation for Normative reference: >>> P019 L014: [13] Rose, M. and D. New, "Reliable Delivery for >>> syslog", RFC 3195, >>> >>> !! Missing citation for Informative reference: >>> P019 L035: [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP >>> Messages with >>> >>> !! Missing citation for Informative reference: >>> P019 L045: [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and >>> R. Monzillo, "Web >>> >> >> Extraneous references removed. >> >> > > Good MIME reference restored along with acronym expansion. > >>> NITS: >>> >>> - Pls expand Acrionyms first time they are used. >>> For example BEEP in the abstract. >>> WSDL in 3rd para section 1. >>> >> >> Expanded. >> >> > Good. > I hope you understood I just listed a few examples. > Pls check all acronyms. Expanded IANA, XML, MIME, and RADIUS. Nits checked with idnits-v1.77. > >>> - Sect 2.5, last sentence. >>> you may want to add a citation (and reference) to the RFC(s) >>> that describes "chunking and persistent connections". >>> >> >> Citation added (HTTP 1.1). >> >> > OK > > >>> - I see sometimes "Reciever" and other times "Receiver". >>> I think it should be consistent: "Receiver" >>> - Security COnsiderations section: s/IPSec/IPsec/ >>> >> >> Fixed. >> >> > > Good, > Thanks, Bert Thanks, Ted. >>>> -----Original Message----- >>>> From: owner-netconf@ops.ietf.org [mailto:owner- >>>> netconf@ops.ietf.org]On >>>> Behalf Of Ted Goddard >>>> Sent: Tuesday, August 30, 2005 19:46 >>>> To: netconf >>>> Subject: proposed changes for draft-ietf-netconf-soap-06 >>>> >>>> >>>> >>>> Hi All, >>>> >>>> I would like to propose the following changes for the NETCONF SOAP >>>> draft in the indicated sections: >>>> >>>> >>>> Section 0 >>>> >>>> RFC 3978 boilerplate >>>> >>>> Section 2.4 BCP56: On the Use of HTTP as a Substrate >>>> >>>> It is also possible to respond to the concern on the >>>> >> re-use of >> >>>> port 80. A NETCONF SOAP service SHOULD be offered over a new >>>> standard port for NETCONF over SOAP (over HTTP) to >>>> be defined as requested in the IANA considerations of this >>>> document. >>>> >>>> Section 4 Security Considerations >>>> >>>> The IANA requested port SHOULD be used, as this provides a >>>> means >>>> for efficient firewall filtering during possible >>>> denial-of-service >>>> attacks. >>>> >>>> Section 5 IANA Considerations >>>> >>>> The IANA is requested to assign TCP ports for >>>> >> NETCONF for SOAP >> >>>> over HTTP and SOAP over BEEP. >>>> >>>> The IANA is requested to place netconf-soap_1.0.wsdl in the >>>> IANA XML registry. >>>> >>>> The following indicated ID-nits appear to be in error (xml2rfc >>>> output checked with "od -c"): >>>> >>>> tmp/draft-ietf-netconf-soap-05.txt(452): >>>> Line is too long: the offending characters are 'elope"' >>>> tmp/draft-ietf-netconf-soap-05.txt(464): >>>> Line is too long: the offending characters are >>>> 's:netconf:base:1.0">' >>>> >>>> >>>> Thanks, >>>> Ted. >>>> >>>> >>> >>> -- >>> 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: >>> >>> >> >> >> > > -- > 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: > -- 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: From owner-netconf@ops.ietf.org Mon Sep 12 11:37:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEqMy-0006ak-Ut for netconf-archive@megatron.ietf.org; Mon, 12 Sep 2005 11:37:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27210 for ; Mon, 12 Sep 2005 11:37:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEq9O-000G43-W2 for netconf-data@psg.com; Mon, 12 Sep 2005 15:23:18 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EEq9N-000G3h-Rk for netconf@ops.ietf.org; Mon, 12 Sep 2005 15:23:18 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8CFNFn23389 for ; Mon, 12 Sep 2005 11:23:15 -0400 (EDT) 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: Decision on NETCONF charter extensions Date: Mon, 12 Sep 2005 11:23:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B404CA40D6@zcarhxm2.corp.nortel.com> Thread-Topic: Decision on NETCONF charter extensions Thread-Index: AcWkDGAZerTOUyafSsCbXKvI5eBqQATn71WA From: "Sharon Chisholm" To: "netconf" 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Actually, I don't believe we were done defining the charter updates either. I had planed one more rewrite after Paris before submitting again. But that likely doesn't have much bearing on this discussion, so let me ask a question and make a couple points. Netconf Events does not require an extension to the charter. Should we assume then that work is still a candidate for short term inclusion in the charter? Those of us working on various bits of netconf phase 2 still feel the current gaps are critical to be addressed and will continue to progress that work to support our Netconf implementations. Please let me know if you are interested in participating in discussions.=20 I have heard a lot of offline support for the netconf phase 2 work, but people have not echoed that support to the mailing list. This understandably gets interpreted badly by the chairs. Just a note though that from the bakeoff we saw that ambiguities in the data model specification framework led to non-interoperable implementations. Also note that there was at least one operator who strongly supported Netconf Events in the face to face meeting in Paris.=20 Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, August 18, 2005 11:37 AM To: netconf Subject: Decision on NETCONF charter extensions Hi, Simon and I have been discussing the status of the WG with our ADs. The four of us do not believe that the charter extension proposals presented to date are sufficiently complete, or widely accepted by the WG, to justify new NETCONF work at this time. As Bert stated at the WG meeting in Paris, the following goals have much higher priority: - getting more implementations of the current document set - getting a show of buy-in from operators that they are indeed playing/testing with implementations - getting a nod/ack from operators that the protocol makes sense and will be used We need to see operator buy-in before we go too far down this path, and end up in the same situation as we ended up with SNMP. W.r.t. new work by this WG, the ADs would like to see the proponents of such new work: - work hard on implementations of the current specs - show prototypes of implementations of the suggested enhancements - work hard on initial data modeling specs and show that there is convergence in thinking before we charter it. (remember the SMIng efforts? we do not want to end up in the same deadlock) - show prototype implementations of such data modeling work so we get a feel of what it is. For all of the above, get operators to show interest and buy-in. Andy and Simon -- 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: -- 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: From owner-netconf@ops.ietf.org Mon Sep 12 19:18:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExZS-0004H1-To for netconf-archive@megatron.ietf.org; Mon, 12 Sep 2005 19:18:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08145 for ; Mon, 12 Sep 2005 19:18:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EExP6-000Pd0-D7 for netconf-data@psg.com; Mon, 12 Sep 2005 23:08:00 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EExP4-000Pcf-Ll for netconf@ops.ietf.org; Mon, 12 Sep 2005 23:07:58 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by borg.juniper.net with ESMTP; 12 Sep 2005 16:07:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,103,1125903600"; d="scan'208"; a="500517963:sNHT24270824" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:07:57 -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: NETCONF protocol IANA considerations & capability URNs Date: Mon, 12 Sep 2005 16:07:27 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440BC4BC7F@photon.jnpr.net> Thread-Topic: NETCONF protocol IANA considerations & capability URNs Thread-Index: AcW37r6dppisp6/gQfqsBOx8vI/XNA== From: "Rob Enns" To: "Netconf \(E-mail\)" X-OriginalArrivalTime: 12 Sep 2005 23:07:57.0563 (UTC) FILETIME=[D05AACB0:01C5B7EE] 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 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.=20 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=20 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: From owner-netconf@ops.ietf.org Tue Sep 13 11:14:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCUR-00065L-QO for netconf-archive@megatron.ietf.org; Tue, 13 Sep 2005 11:14:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26696 for ; Tue, 13 Sep 2005 11:14:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFCHD-000MIH-2k for netconf-data@psg.com; Tue, 13 Sep 2005 15:00:51 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EFCHA-000MHX-3M for netconf@ops.ietf.org; Tue, 13 Sep 2005 15:00:48 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8DF0ijt028539; Tue, 13 Sep 2005 10:00:45 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Sep 2005 17:00:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550808DDA8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rob Enns (E-mail)" , "Netconf (E-mail)" Subject: FW: NETCONF protocol IANA considerations & capability URNs Date: Tue, 13 Sep 2005 17:00:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk 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: > -- 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: From owner-netconf@ops.ietf.org Tue Sep 13 11:52:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFD5L-0003p3-9y for netconf-archive@megatron.ietf.org; Tue, 13 Sep 2005 11:52:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28332 for ; Tue, 13 Sep 2005 11:52:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFCxK-000PH7-Ac for netconf-data@psg.com; Tue, 13 Sep 2005 15:44:22 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EFCxI-000PGr-S9 for netconf@ops.ietf.org; Tue, 13 Sep 2005 15:44:21 +0000 Received: (qmail 26686 invoked by uid 78); 13 Sep 2005 15:44:19 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail.networksolutionsemail.com with SMTP; 13 Sep 2005 15:44:19 -0000 Message-ID: <4326F3D2.8060803@andybierman.com> Date: Tue, 13 Sep 2005 08:44:18 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: Re: NETCONF protocol IANA considerations & capability URNs References: <062B922B6EC55149B5A267ECE78E5D440BC4BC7F@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440BC4BC7F@photon.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit Rob Enns wrote: I would like to go with the new format if nobody objects. Essentially, we are removing the "xml:ns" from this formatted string, since it doesn't add any information and it is inconsistent with other URN definitions. Andy >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: > > > > -- 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: From owner-netconf@ops.ietf.org Tue Sep 13 12:46:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDvA-0004LP-EF for netconf-archive@megatron.ietf.org; Tue, 13 Sep 2005 12:46:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01443 for ; Tue, 13 Sep 2005 12:46:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFDlD-0003L5-SZ for netconf-data@psg.com; Tue, 13 Sep 2005 16:35:55 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EFDlC-0003Ki-Um for netconf@ops.ietf.org; Tue, 13 Sep 2005 16:35:55 +0000 Received: (qmail 20613 invoked by uid 78); 13 Sep 2005 16:35:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail6.netsol.inquent.com with SMTP; 13 Sep 2005 16:35:54 -0000 Message-ID: <4326FFE9.3010200@andybierman.com> Date: Tue, 13 Sep 2005 09:35:53 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf Subject: Re: Decision on NETCONF charter extensions References: <713043CE8B8E1348AF3C546DBE02C1B404CA40D6@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B404CA40D6@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit Sharon Chisholm wrote: >hi > >Actually, I don't believe we were done defining the charter updates >either. I had planed one more rewrite after Paris before submitting >again. But that likely doesn't have much bearing on this discussion, so >let me ask a question and make a couple points. > >Netconf Events does not require an extension to the charter. Should we >assume then that work is still a candidate for short term inclusion in >the charter? > >Those of us working on various bits of netconf phase 2 still feel the >current gaps are critical to be addressed and will continue to progress >that work to support our Netconf implementations. Please let me know if >you are interested in participating in discussions. > > I certainly don't object to the WG discussing notifications/events (don't want to start a terminology debate now). First there needs to be even the most basic agreement on the feature requirements. We started out just trying to incorporate RFC 3195 (Reliable Delivery for syslog) into our BEEP transport only, and that was dropped. I assume we will design the notification PDU in a content-neutral (layered) fashion, as we did with the PDU. I think if somebody designed and implemented something, got operators/app-developers to use it, and wrote a draft documenting it, we could proceed. (If you remember back, that's what Juniper did with Junoscript, even before the XMLCONF design team.) >I have heard a lot of offline support for the netconf phase 2 work, but >people have not echoed that support to the mailing list. This >understandably gets interpreted badly by the chairs. > > Yes - a lack of mailing list activity means people are not interested enough at this time to write an email. >Just a note though that from the bakeoff we saw that ambiguities in the >data model specification framework led to non-interoperable >implementations. Also note that there was at least one operator who >strongly supported Netconf Events in the face to face meeting in Paris. > > What does this first sentence mean? Did test participants start with a particular data model definition to implement? (I have to read the test report again). >Sharon > > > Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Thursday, August 18, 2005 11:37 AM >To: netconf >Subject: Decision on NETCONF charter extensions > > >Hi, > >Simon and I have been discussing the status of the WG with >our ADs. The four of us do not believe that the charter extension >proposals presented to date are sufficiently complete, or widely >accepted by the WG, to justify new NETCONF work at this time. > >As Bert stated at the WG meeting in Paris, the following goals have much >higher priority: > - getting more implementations of the current document set > - getting a show of buy-in from operators that they are > indeed playing/testing with implementations > - getting a nod/ack from operators that the protocol > makes sense and will be used > >We need to see operator buy-in before we go too far down this path, and >end up in the same situation as we ended up with SNMP. W.r.t. new work >by this WG, the ADs would like to see the proponents of such new work: > > - work hard on implementations of the current specs > - show prototypes of implementations of the suggested > enhancements > - work hard on initial data modeling specs and show that > there is convergence in thinking before we charter it. > (remember the SMIng efforts? we do not want to end > up in the same deadlock) > - show prototype implementations of such data modeling work > so we get a feel of what it is. > >For all of the above, get operators to show interest and buy-in. > > >Andy and Simon > > > >-- >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: > > >-- >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: > > > > -- 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: From owner-netconf@ops.ietf.org Tue Sep 13 19:19:54 2005 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 ; 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" To: "Wijnen, Bert \(Bert\)" , "Netconf \(E-mail\)" 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=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Tuesday, September 13, 2005 8:01 AM > To: Rob Enns; Netconf (E-mail) > Subject: FW: NETCONF protocol IANA considerations & capability URNs >=20 > I had a question that I asked to one of the APPS ADs. > Here is the answer. FYI and action >=20 > Bert >=20 > -----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 >=20 >=20 > I'm very familiar with that situation. There is no XML=20 > associated with a > namespace -- it's identified by a URI and a URI alone. =20 > 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. >=20 > The text you've copied below should probably leave the first=20 > XML field in > the template blank. It's clearly not "this document". The=20 > second one is OK > as long as appendix B is the appropriate XML Schema, nested=20 > between BEGIN > and END tags as described in RFC 3688. >=20 > -Scott- >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > > Sent: Tuesday, September 13, 2005 10:17 AM > > To: Scott Hollenbeck (E-mail) > > Subject: FW: NETCONF protocol IANA considerations & capability URNs > >=20 > > Scott, can you check the below, if it is correct and makes sense? > >=20 > > When I look at > > http://www.iana.org/assignments/xml-registry/ns.html > >=20 > > 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. > >=20 > > Bert > >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org=20 > [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 > >=20 > >=20 > > 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.=20 > >=20 > > The URNs currently have the form: > >=20 > > urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 > >=20 > > This says that the capability is an XML namespace as defined > > by RFC 3688. Strictly speaking, that is incorrect. > >=20 > > The capability URNs should really be a NETCONF protocol=20 > > parameter a la RFC 3553. Something like: > >=20 > > urn:ietf:params:netconf:capability:{name}:1.0 > >=20 > > If the WG approves, I will make this change to the protocol draft. > >=20 > > Here is a proposed IANA considerations section assuming the > > capabilities are expressed as shown above. Please comment. > >=20 > > ---- > >=20 > > 10. IANA Considerations > >=20 > > 10.1. NETCONF XML Namespace > >=20 > > This document requests that IANA assign a URI for the NETCONF XML > > namespace in the IETF XML registry [8]. > >=20 > > Following the format in RFC 3688, the following registration is > > requested. > >=20 > > URI: Please assign the URI=20 > "urn:ietf:params:xml:ns:netconf" for use > > by the NETCONF protocol. > >=20 > > Registrant Contact: The IESG. > >=20 > > XML: This document. > >=20 > > 10.2. NETCONF XML Schema > >=20 > > This document requests that IANA assign a URI for the NETCONF XML > > namespace in the IETF XML registry [8]. > >=20 > > Following the format in RFC 3688, the following registration is > > requested. > >=20 > > URI: Please assign the URI=20 > "urn:ietf:params:xml:schema:netconf" for > > use by the NETCONF protocol. > >=20 > > Registrant Contact: The IESG. > >=20 > > XML: Appendix B of this document. > >=20 > > 10.3. NETCONF Capability URNs > >=20 > > This document requests that IANA create a registry for allocating > > NETCONF capability identifiers. Allocation from the=20 > > registry is on a > > First Come First Served Basis, but a specification is required. > >=20 > > 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. > >=20 > > Following the guidelines in RFC 3553 [7], IANA is=20 > > requested to assign > > a NETCONF sub-namespace as follows: > >=20 > > Registry name: netconf > >=20 > > Specification: This document. > >=20 > > Repository: This document. > >=20 > > Index value: The NETCONF capability name. > >=20 > > -- > > 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: > >=20 >=20 -- 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: From owner-netconf@ops.ietf.org Wed Sep 14 16:02:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdSZ-0005X8-Oy for netconf-archive@megatron.ietf.org; Wed, 14 Sep 2005 16:02:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01890 for ; Wed, 14 Sep 2005 16:02:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFdG1-000He6-RW for netconf-data@psg.com; Wed, 14 Sep 2005 19:49:25 +0000 Received: from [198.152.12.100] (helo=tiere.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFdFx-000HdT-MW for netconf@ops.ietf.org; Wed, 14 Sep 2005 19:49:21 +0000 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8EJka2f028729 for ; Wed, 14 Sep 2005 15:46:37 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8EJiE2f025337 for ; Wed, 14 Sep 2005 15:45:18 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: Decision on NETCONF charter extensions Date: Wed, 14 Sep 2005 22:46:51 +0300 Message-ID: Thread-Topic: Decision on NETCONF charter extensions Thread-Index: AcWkDGAZerTOUyafSsCbXKvI5eBqQATn71WAAG3e5DA= From: "Romascanu, Dan \(Dan\)" To: "Sharon Chisholm" , "netconf" Cc: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 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 I have repeatedly stated my opinion, based also on what we hear from our customers that in the absence of a standard data model the NETCONF work is not complete, and cannot offer the level of interoperability that is expected from an IETF protocol. I believe that the WG chairs are raising the threshold at an level that is unprecedented high in the IETF asking for data modeling specifications to be written and prototype implementations be shown as a condition for the work being chartered. I respectfully disagree with this position, and I believe that the SMIng example that they are bringing as the precedent to avoid does not apply, because SMIng was a refinement, actually a third version of the SMI for SNMP, long after SNMP had a chance to reach standard interoperability because both the protocol and the data model were defined from the start. To use a aeronautics metaphor, while SMIng may have been a raise in altitude from 30,000 to 39,000 feet NETCONF is not even given a chance to take off in the absence of a standard data model.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Monday, September 12, 2005 6:23 PM > To: netconf > Subject: RE: Decision on NETCONF charter extensions >=20 > hi >=20 > Actually, I don't believe we were done defining the charter=20 > updates either. I had planed one more rewrite after Paris=20 > before submitting again. But that likely doesn't have much=20 > bearing on this discussion, so let me ask a question and make=20 > a couple points. >=20 > Netconf Events does not require an extension to the charter.=20 > Should we assume then that work is still a candidate for=20 > short term inclusion in the charter? >=20 > Those of us working on various bits of netconf phase 2 still=20 > feel the current gaps are critical to be addressed and will=20 > continue to progress that work to support our Netconf=20 > implementations. Please let me know if you are interested in=20 > participating in discussions.=20 >=20 > I have heard a lot of offline support for the netconf phase 2=20 > work, but people have not echoed that support to the mailing=20 > list. This understandably gets interpreted badly by the chairs. >=20 > Just a note though that from the bakeoff we saw that=20 > ambiguities in the data model specification framework led to=20 > non-interoperable implementations. Also note that there was=20 > at least one operator who strongly supported Netconf Events=20 > in the face to face meeting in Paris.=20 >=20 > Sharon >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, August 18, 2005 11:37 AM > To: netconf > Subject: Decision on NETCONF charter extensions >=20 >=20 > Hi, >=20 > Simon and I have been discussing the status of the WG with=20 > our ADs. The four of us do not believe that the charter=20 > extension proposals presented to date are sufficiently=20 > complete, or widely accepted by the WG, to justify new=20 > NETCONF work at this time. >=20 > As Bert stated at the WG meeting in Paris, the following=20 > goals have much higher priority: > - getting more implementations of the current document set > - getting a show of buy-in from operators that they are > indeed playing/testing with implementations > - getting a nod/ack from operators that the protocol > makes sense and will be used >=20 > We need to see operator buy-in before we go too far down this=20 > path, and end up in the same situation as we ended up with=20 > SNMP. W.r.t. new work by this WG, the ADs would like to see=20 > the proponents of such new work: >=20 > - work hard on implementations of the current specs > - show prototypes of implementations of the suggested > enhancements > - work hard on initial data modeling specs and show that > there is convergence in thinking before we charter it. > (remember the SMIng efforts? we do not want to end > up in the same deadlock) > - show prototype implementations of such data modeling work > so we get a feel of what it is. >=20 > For all of the above, get operators to show interest and buy-in. >=20 >=20 > Andy and Simon >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- 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: From owner-netconf@ops.ietf.org Wed Sep 14 17:16:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFecK-0005Vt-Do for netconf-archive@megatron.ietf.org; Wed, 14 Sep 2005 17:16:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12453 for ; Wed, 14 Sep 2005 17:16:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFeSH-000NTc-Jk for netconf-data@psg.com; Wed, 14 Sep 2005 21:06:09 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EFeSD-000NT8-Lc for netconf@ops.ietf.org; Wed, 14 Sep 2005 21:06:06 +0000 Received: (qmail 16402 invoked by uid 78); 14 Sep 2005 21:06:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail12.netsol.inquent.com with SMTP; 14 Sep 2005 21:06:04 -0000 Message-ID: <432890BB.5070307@andybierman.com> Date: Wed, 14 Sep 2005 14:06:03 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: Sharon Chisholm , netconf , bwijnen@lucent.com Subject: Re: Decision on NETCONF charter extensions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit Romascanu, Dan (Dan) wrote: >I have repeatedly stated my opinion, based also on what we hear from our >customers that in the absence of a standard data model the NETCONF work >is not complete, and cannot offer the level of interoperability that is >expected from an IETF protocol. I believe that the WG chairs are raising >the threshold at an level that is unprecedented high in the IETF asking >for data modeling specifications to be written and prototype >implementations be shown as a condition for the work being chartered. I >respectfully disagree with this position, and I believe that the SMIng >example that they are bringing as the precedent to avoid does not apply, >because SMIng was a refinement, actually a third version of the SMI for >SNMP, long after SNMP had a chance to reach standard interoperability >because both the protocol and the data model were defined from the >start. To use a aeronautics metaphor, while SMIng may have been a raise >in altitude from 30,000 to 39,000 feet NETCONF is not even given a >chance to take off in the absence of a standard data model. > > I disagree that we are starting from zero wrt/ data modeling. 1) Language There are existing languages (XSD, RelaxNG) for defining templates for valid XML instance documents. There may be standard 'appinfo' extensions, and other usage conventions that may be helpful, but the WG should not reinvent XSD or something like it. 2) Data Models We started SNMP with little more than a handful of counters for the protocol itself. We could finish the netconf-state data model that was pulled from the PROT spec, as a separate effort. Somebody could publish an Interfaces data model as well. Somebody could publish a standard for converting SMIv2 MIBs and SNMP PDU payloads to an XML syntax, which happens to comply with NETCONF payload requirements. None of these things have to be done in the NETCONF WG. The NETCONF protocol is intentionally content-neutral. We aren't going to define any CLRs for this content. (There are already people defining CLRs for XML, so we don't need to duplicate that work.) The NETCONF WG is never going to attempt the create technology-specific data models -- these will need to be developed within WGs close to the particular technology being modeled. 3) Raising The Bar Yes indeed, the bar is being raised for introduction of new work. The ADs and co-Chairs want people to do the "sandbox" phase on their own and bring somewhat-proven (I say 'somewhat' because there are no rigid standards to meet). If you can say "we've implemented this and network operators have used it and like it", then you can also say "I think the WG should standardize it." As previously stated, we want to see some proof that operators will use NETCONF before we invest more standards effort in it. IMO, the old argument "there are no standard data models for configuration" is not very compelling because operators have never had that, and aren't really expecting it very soon. Clueful developers and operators will be able to evaluate the protocol wrt/ ease-of-use, standard and proprietary RPC calls, and error responses. We're just looking for people to put the protocol to *some* useful work. We don't expect full-blown management of anything right away. >Regards, > >Dan > > Andy > > > > > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm >>Sent: Monday, September 12, 2005 6:23 PM >>To: netconf >>Subject: RE: Decision on NETCONF charter extensions >> >>hi >> >>Actually, I don't believe we were done defining the charter >>updates either. I had planed one more rewrite after Paris >>before submitting again. But that likely doesn't have much >>bearing on this discussion, so let me ask a question and make >>a couple points. >> >>Netconf Events does not require an extension to the charter. >>Should we assume then that work is still a candidate for >>short term inclusion in the charter? >> >>Those of us working on various bits of netconf phase 2 still >>feel the current gaps are critical to be addressed and will >>continue to progress that work to support our Netconf >>implementations. Please let me know if you are interested in >>participating in discussions. >> >>I have heard a lot of offline support for the netconf phase 2 >>work, but people have not echoed that support to the mailing >>list. This understandably gets interpreted badly by the chairs. >> >>Just a note though that from the bakeoff we saw that >>ambiguities in the data model specification framework led to >>non-interoperable implementations. Also note that there was >>at least one operator who strongly supported Netconf Events >>in the face to face meeting in Paris. >> >>Sharon >> >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>Sent: Thursday, August 18, 2005 11:37 AM >>To: netconf >>Subject: Decision on NETCONF charter extensions >> >> >>Hi, >> >>Simon and I have been discussing the status of the WG with >>our ADs. The four of us do not believe that the charter >>extension proposals presented to date are sufficiently >>complete, or widely accepted by the WG, to justify new >>NETCONF work at this time. >> >>As Bert stated at the WG meeting in Paris, the following >>goals have much higher priority: >> - getting more implementations of the current document set >> - getting a show of buy-in from operators that they are >> indeed playing/testing with implementations >> - getting a nod/ack from operators that the protocol >> makes sense and will be used >> >>We need to see operator buy-in before we go too far down this >>path, and end up in the same situation as we ended up with >>SNMP. W.r.t. new work by this WG, the ADs would like to see >>the proponents of such new work: >> >> - work hard on implementations of the current specs >> - show prototypes of implementations of the suggested >> enhancements >> - work hard on initial data modeling specs and show that >> there is convergence in thinking before we charter it. >> (remember the SMIng efforts? we do not want to end >> up in the same deadlock) >> - show prototype implementations of such data modeling work >> so we get a feel of what it is. >> >>For all of the above, get operators to show interest and buy-in. >> >> >>Andy and Simon >> >> >> >>-- >>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: >> >> >>-- >>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: >> >> >> > >-- >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: > > > > -- 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: From owner-netconf@ops.ietf.org Thu Sep 15 11:30:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFvgc-0008IH-EQ for netconf-archive@megatron.ietf.org; Thu, 15 Sep 2005 11:30:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17993 for ; Thu, 15 Sep 2005 11:30:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFvRK-000N39-VZ for netconf-data@psg.com; Thu, 15 Sep 2005 15:14:18 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFvRF-000N2o-UU for netconf@ops.ietf.org; Thu, 15 Sep 2005 15:14:13 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Thu, 15 Sep 2005 08:14:17 -0700 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440BC4BC7F@photon.jnpr.net> References: <062B922B6EC55149B5A267ECE78E5D440BC4BC7F@photon.jnpr.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ADDDCC7-8130-4AF2-B63A-4F2DBF8EB00E@icesoft.com> Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: NETCONF protocol IANA considerations & capability URNs Date: Thu, 15 Sep 2005 09:12:58 -0600 To: Rob Enns , "Netconf ((E-mail))" X-Mailer: Apple Mail (2.734) 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Do these IANA considerations also provide for placing the NETCONF schema itself in the XML registry, such as with the conference-info XSD? http://www.iana.org/assignments/xml-registry/schema/conference-info.xsd http://www.iana.org/assignments/xml-registry/schema.html Ted. On 12-Sep-05, at 5:07 PM, Rob Enns wrote: > 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: > -- 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: From owner-netconf@ops.ietf.org Thu Sep 15 13:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxbl-0007D8-BV for netconf-archive@megatron.ietf.org; Thu, 15 Sep 2005 13:33:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22752 for ; Thu, 15 Sep 2005 13:33:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFxUa-0006jl-Ty for netconf-data@psg.com; Thu, 15 Sep 2005 17:25:48 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EFxUX-0006jV-UE for netconf@ops.ietf.org; Thu, 15 Sep 2005 17:25:45 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 15 Sep 2005 10:25:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,114,1125903600"; d="scan'208"; a="482474555:sNHT23431280" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 10:25:45 -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: Thu, 15 Sep 2005 10:25:38 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440BC4BF5F@photon.jnpr.net> Thread-Topic: NETCONF protocol IANA considerations & capability URNs Thread-Index: AcW6CC59N53tCgupSWmACpsGwTaT0AAEMtAg From: "Rob Enns" To: "Ted Goddard" , "Netconf \(\(E-mail\)\)" X-OriginalArrivalTime: 15 Sep 2005 17:25:45.0013 (UTC) FILETIME=[813D6E50:01C5BA1A] 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think that's what it says, yes. Identifying the schema in Appendix B and marking it with BEGIN/END seems to imply that IANA will place that XML in the registry (see section 4 of RFC 3688). thanks, Rob=20 > -----Original Message----- > From: Ted Goddard [mailto:ted.goddard@icesoft.com]=20 > Sent: Thursday, September 15, 2005 8:13 AM > To: Rob Enns; Netconf ((E-mail)) > Subject: Re: NETCONF protocol IANA considerations & capability URNs >=20 >=20 > Do these IANA considerations also provide for placing the=20 > NETCONF schema > itself in the XML registry, such as with the conference-info XSD? >=20 > http://www.iana.org/assignments/xml-registry/schema/conference > -info.xsd >=20 > http://www.iana.org/assignments/xml-registry/schema.html >=20 > Ted. >=20 > On 12-Sep-05, at 5:07 PM, Rob Enns wrote: >=20 > > 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=20 > "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=20 > "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=20 > registry is =20 > > 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 =20 > > 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: > > >=20 >=20 -- 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: From owner-netconf@ops.ietf.org Thu Sep 15 16:01:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzv3-0003bg-MF for netconf-archive@megatron.ietf.org; Thu, 15 Sep 2005 16:01:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02491 for ; Thu, 15 Sep 2005 16:01:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFzkE-000GkX-0w for netconf-data@psg.com; Thu, 15 Sep 2005 19:50:06 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFzkB-000GjB-5I for netconf@ops.ietf.org; Thu, 15 Sep 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EFzkA-0001jl-2H; Thu, 15 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-08.txt Message-Id: Date: Thu, 15 Sep 2005 15:50:02 -0400 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=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Configuration Protocol Author(s) : R. Enns Filename : draft-ietf-netconf-prot-08.txt Pages : 97 Date : 2005-9-15 The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-prot-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-15120121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-15120121.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Sun Sep 18 16:59:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH6Fq-0006id-I8 for netconf-archive@megatron.ietf.org; Sun, 18 Sep 2005 16:59:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24922 for ; Sun, 18 Sep 2005 16:59:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EH64P-000Crf-Lm for netconf-data@psg.com; Sun, 18 Sep 2005 20:47:29 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EH64O-000CrT-Io for netconf@ops.ietf.org; Sun, 18 Sep 2005 20:47:28 +0000 Received: (qmail 1603 invoked by uid 78); 18 Sep 2005 20:47:17 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail12.netsol.inquent.com with SMTP; 18 Sep 2005 20:47:17 -0000 Message-ID: <432DD254.3050005@andybierman.com> Date: Sun, 18 Sep 2005 13:47:16 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf CC: Rob Enns Subject: problems in draft-ietf-netconf-prot-08 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit Hi, Here is what I have found studying diffs between -07 and -08: ------------------------------- 1) Clarification added to sec. 7.9: The operation does not rollback configuration or other device state modifications made by the entity holding the lock. Note that this is not true for a confirmed-commit (see sec. 8.4.1). If you kill the session that is holding the lock, and of course also issued the first commit, the agent must revert the running config. -------------------------------- 2) Change to NETCONF Base URN inconsistently applied: Throughout the examples, and some normative text (3.1, 8.1), the base URN is listed in 3 different forms: (A) urn:ietf:params:xml:ns:netconf:base:1.0 (B) urn:ietf:params:netconf:base:1.0 From sec. 10.1: (C) URI: Please assign the URI "urn:ietf:params:xml:ns:netconf" for use by the NETCONF protocol. Form (C) of the NETCONF NS is not used at all within the document. All xmlns declarations are in form (A). Only the capability exchange in sec 8.1 shows form (B) in use. Shouldn't they all be changed to form (B) for both the NETCONF NS (all xmlns declarations) and the NETCONF Base capability (used as content for the element for the version of the protocol supported)? --------------------------------------------------- 3) From sec. 10.2, NETCONF Schema IANA request: URI: Please assign the URI "urn:ietf:params:xml:schema:netconf" for use by the NETCONF protocol. This string is not used anywhere in the document. From the XSD in appendix B: From owner-netconf@ops.ietf.org Mon Sep 19 11:01:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHN8s-00072M-Uo for netconf-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:01:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27524 for ; Mon, 19 Sep 2005 11:01:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHMy3-000Pof-R3 for netconf-data@psg.com; Mon, 19 Sep 2005 14:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHMy3-000Pnv-1j for netconf@ops.ietf.org; Mon, 19 Sep 2005 14:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EHMy1-0005ZP-RY; Mon, 19 Sep 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-soap-06.txt Message-Id: Date: Mon, 19 Sep 2005 10:50:01 -0400 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=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) Author(s) : T. Goddard Filename : draft-ietf-netconf-soap-06.txt Pages : 22 Date : 2005-9-19 The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP (Hypertext Transport Protocol) and SOAP over BEEP (Blocks Exchange Extensible Protocol) bindings for NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-soap-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-soap-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-19101330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-soap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-soap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-19101330.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Mon Sep 19 14:13:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQ97-0006as-Db for netconf-archive@megatron.ietf.org; Mon, 19 Sep 2005 14:13:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11617 for ; Mon, 19 Sep 2005 14:13:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHPz3-000Je4-5U for netconf-data@psg.com; Mon, 19 Sep 2005 18:03:17 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHPz1-000Jdk-Bn for netconf@ops.ietf.org; Mon, 19 Sep 2005 18:03:15 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 19 Sep 2005 11:03:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,123,1125903600"; d="scan'208"; a="501357962:sNHT23376600" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 11:03:14 -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: problems in draft-ietf-netconf-prot-08 Date: Mon, 19 Sep 2005 11:02:52 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440C24DC2B@photon.jnpr.net> Thread-Topic: problems in draft-ietf-netconf-prot-08 Thread-Index: AcW8kjCSuVVnynnHT3ioCjBPVrwC5gAqhntA From: "Rob Enns" To: "Andy Bierman" , "netconf" X-OriginalArrivalTime: 19 Sep 2005 18:03:14.0788 (UTC) FILETIME=[67DCDA40:01C5BD44] 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > 1) Clarification added to sec. 7.9: >=20 > The operation does not rollback configuration or > other device state modifications made by the entity holding the > lock. >=20 > Note that this is not true for a confirmed-commit (see sec. 8.4.1). > If you kill the session that is holding the lock, and of course > also issued the first commit, the agent must revert the=20 > running config. True.=20 > 2) Change to NETCONF Base URN inconsistently applied: >=20 > Throughout the examples, and some normative text (3.1, 8.1), > the base URN is listed in 3 different forms: Let me try to clarify this: =20 > (A) urn:ietf:params:xml:ns:netconf:base:1.0 This is the NETCONF protocol XML namespace we should be using.=20 =20 > (B) urn:ietf:params:netconf:base:1.0 This is the base capability URN, it's not an XML namespace.=20 (one might argue it should be: urn:ietf:params:netconf:capability:base:1.0 -- if folks feel strongly about it I can change it) In any case a URN of the form "urn:ietf:params:netconf:..." should be found only in capabilities. I believe the document is correct in this regard--if you see specific examples where it's wrong please point them out. > From sec. 10.1: >=20 > (C) URI: Please assign the URI=20 > "urn:ietf:params:xml:ns:netconf" for use > by the NETCONF protocol. By asking for the URI above I'm assuming we can also use: urn:ietf:params:xml:ns:netconf:base:1.0 (ie. (A) above) as the namespace. Perhaps that was a little presumptuous. Perhaps this is best resolved by requesting the entire namespace URI (ie. (A) above): urn:ietf:params:xml:ns:netconf:base:1.0 > Form (C) of the NETCONF NS is not used at all within the document. > All xmlns declarations are in form (A). Only the capability exchange > in sec 8.1 shows form (B) in use.=20 > =20 > Shouldn't they all be changed to form (B) for > both the NETCONF NS (all xmlns declarations) > and the NETCONF Base capability (used as content > for the element for the version of > the protocol supported)? I think the capability URIs (including the base capability) and=20 namespace URI should be different. > --------------------------------------------------- >=20 >=20 > 3) From sec. 10.2, NETCONF Schema IANA request: >=20 > URI: Please assign the URI "urn:ietf:params:xml:schema:netconf" for > use by the NETCONF protocol. >=20 > This string is not used anywhere in the document. > > From the XSD in appendix B: >=20 > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > =20 > targetNamespace=3D"urn:ietf:params:xml:ns:netconf:base:1.0" >=20 >=20 > Shouldn't this targetNamespace be the same as the string > used in all the xmlns examples in the document for the > NETCONF namespace? Which is supposed to be form (B) above? The namespace we're defining in the XML schema is the NETCONF protocol namespace. I think it is correct as it stands. The URI registration for the NETCONF protocol XML schema in independent, and afaik that URI does not need to appear in the XSD document. > --------------------------------------------------------------- >=20 > 4) From sec 10.3: >=20 > This document requests that IANA create a registry for allocating > NETCONF capability identifiers. Allocation from the=20 > registry is on a > First Come First Served Basis, but a specification is required. >=20 > 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. >=20 > Following the guidelines in RFC 3553 [7], IANA is=20 > requested to assign > a NETCONF sub-namespace as follows: >=20 > Registry name: netconf >=20 > Specification: Section 8 of this document. >=20 > Repository: Section 8 of this document. >=20 >=20 > Does paragraph 1 imply that the NETCONF registry will have > values defined outside the WG? I am opposed to this. =20 > We need to keep WG and vendor definitions separate, just like > we do with SMI. Agreed. By requiring a specification an RFC or other permanent document needs to be provided (see RFC 2434). We could raise the bar and say that IETF Consensus is required--this effectively means that an IETF WG must approve additions to this registry. =20 > The specification of the capability URNs is listed as 'Section 8'. > This is not sufficient because the values are scattered throughout > a very large section. IMO we need a table added in sec 8 that > lists all the actual strings, and 10.3 should refer to that table. It would certainly be easier to gather the capability strings from a table, at the cost of duplicating them in the document. Isn't the=20 normative text enough? 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: From owner-netconf@ops.ietf.org Sun Sep 25 06:37:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTss-0005GF-JX for netconf-archive@megatron.ietf.org; Sun, 25 Sep 2005 06:37:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04162 for ; Sun, 25 Sep 2005 06:37:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJTh9-0001dN-M7 for netconf-data@psg.com; Sun, 25 Sep 2005 10:25:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EJTh9-0001d2-0R for netconf@ops.ietf.org; Sun, 25 Sep 2005 10:25:19 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2005 03:25:18 -0700 X-IronPort-AV: i="3.97,143,1125903600"; d="scan'208"; a="345360082:sNHT28617702" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8PAP9KC012547 for ; Sun, 25 Sep 2005 03:25:10 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp235.cisco.com [10.61.64.235]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8PAbAKn031530 for ; Sun, 25 Sep 2005 03:37:11 -0700 Message-ID: <43367B0A.3040303@cisco.com> Date: Sun, 25 Sep 2005 12:25:14 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: draft-ietf-netconf-beep-07.txt X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=214; t=1127644631; x=1128076831; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:draft-ietf-netconf-beep-07.txt| From:Eliot=20Lear=20| Date:Sun,=2025=20Sep=202005=2012=3A25=3A14=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=QNqZkGI9p65N1XTaQlsG78ZcIfrVWqya0IGgIcA1VCe4n3IzqX/G4fLRkPbZy3f8JYAbjFjk akmkEEICRtW8IeO3FdfqeYCz7k1999Dt4qvrua5sg9GOzFuNTWOdLthzaoDEJaNvjt5KYbfwE4l gFOmmEjIqsYsABUJFs9MWbzI= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I've just transmitted a new version of the beep draft. It contains the following single change: a change of the URN in the example and the count associated in the MSG, in accordance with the core draft change. Draft should appear in the next day or so. Eliot -- 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: From owner-netconf@ops.ietf.org Mon Sep 26 11:01:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuTX-0002jS-VD for netconf-archive@megatron.ietf.org; Mon, 26 Sep 2005 11:01:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03918 for ; Mon, 26 Sep 2005 11:01:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJuIw-000Ll1-Ja for netconf-data@psg.com; Mon, 26 Sep 2005 14:50:06 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EJuIt-000Ljr-6U for netconf@ops.ietf.org; Mon, 26 Sep 2005 14:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EJuIs-0006dG-40; Mon, 26 Sep 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-beep-07.txt Message-Id: Date: Mon, 26 Sep 2005 10:50:02 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) Author(s) : E. Lear, K. Crozier Filename : draft-ietf-netconf-beep-07.txt Pages : 14 Date : 2005-9-26 This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-beep-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-beep-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-26095532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-beep-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-beep-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-26095532.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: