From wjhns1@hardakers.net Tue Jan 4 08:08:37 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A9C3A6CE3 for ; Tue, 4 Jan 2011 08:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUg5DhL6BuMK for ; Tue, 4 Jan 2011 08:08:32 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 114273A6CB3 for ; Tue, 4 Jan 2011 08:08:32 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id DC52722C3C; Tue, 4 Jan 2011 08:10:16 -0800 (PST) From: Wes Hardaker To: "t.petch" Organization: Sparta References: <00b101cb609e$fc77ccc0$4001a8c0@gateway.2wire.net> <011a01cba6a8$f15b4c40$4001a8c0@gateway.2wire.net> Date: Tue, 04 Jan 2011 08:10:16 -0800 In-Reply-To: <011a01cba6a8$f15b4c40$4001a8c0@gateway.2wire.net> (t. petch's message of "Tue, 28 Dec 2010 17:04:26 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: ws6zed@gmail.com, netconf@ietf.org Subject: Re: [Netconf] e-mail getting bounced X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:08:37 -0000 >>>>> On Tue, 28 Dec 2010 17:04:26 +0100, "t.petch" said: tp> My e-mail to you gets bounced and I believe the MSA is then refusing tp> to send it to anyone so I have taken you off the addressees. BTW, I've now learned this is because btconnect isn't RFC compliant :-P -- Wes Hardaker Cobham Analytic Solutions From sangitarajankar@gmail.com Thu Jan 6 22:02:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A0E3A67B1 for ; Thu, 6 Jan 2011 22:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPEu7WxN5j4w for ; Thu, 6 Jan 2011 22:02:17 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6A5273A67AE for ; Thu, 6 Jan 2011 22:02:17 -0800 (PST) Received: by yxt33 with SMTP id 33so7537179yxt.31 for ; Thu, 06 Jan 2011 22:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eICACHd6QDxVSzPVfAKKIHbOQpjg2gLj172nVr6hRXE=; b=fgXPCRgIYA0/2kqotAj7bdp+SoVcXCOsdK54Zs63Sk+QFWfYUVuIQ7LrhhjZqaH8Ti 7QfagPjGl8jbQyi9Lq3oORbI5fOGq83xCZxYQgALQYfMmrJvyuFdwF7MZvh9KbSHbu1X 9hqNbE+dXHP2VAyh6hfAxm7yp7Npv5OyfGLRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IFyRgY2oODdoTVyVmZe4qo1l4Y24qUC/FchrSenvW5QUNAFSFPStO+ZnagPEPctFIz 6XNz37fs7DGApXaheYzADKwWLUxT8yMdUXtcJVC5AJlH0/UAujzDhtxM8HhtIBuK2nb/ kqzo/35LuuZcPU2oKB40iKpxINQLyXEpzhCmc= MIME-Version: 1.0 Received: by 10.90.248.28 with SMTP id v28mr2833931agh.168.1294380263984; Thu, 06 Jan 2011 22:04:23 -0800 (PST) Received: by 10.90.74.8 with HTTP; Thu, 6 Jan 2011 22:04:23 -0800 (PST) Date: Fri, 7 Jan 2011 11:34:23 +0530 Message-ID: From: Sangita Rajankar To: netconf@ietf.org Content-Type: multipart/alternative; boundary=0016363b8e5ad6d08404993b6361 Subject: [Netconf] netconf xsd X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:02:18 -0000 --0016363b8e5ad6d08404993b6361 Content-Type: text/plain; charset=ISO-8859-1 Hi, can i forward a netconf.xsd file (modified by me) for checking whether it is ok to implement netconf protocol. Regards Mrs. Sangita Rajankar --0016363b8e5ad6d08404993b6361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
can i forward a netconf.xsd file (modified by me)=A0for checking wheth= er it is ok to implement netconf protocol.
=A0
Regards
Mrs. Sangita Rajankar
=A0
=A0
=A0
--0016363b8e5ad6d08404993b6361-- From mehmet.ersue@nsn.com Fri Jan 7 06:46:46 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4935C3A68EF for ; Fri, 7 Jan 2011 06:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.496 X-Spam-Level: X-Spam-Status: No, score=-104.496 tagged_above=-999 required=5 tests=[AWL=2.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oalSxvD0x5tm for ; Fri, 7 Jan 2011 06:46:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0AEE53A68ED for ; Fri, 7 Jan 2011 06:46:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p07EmoCZ029958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Jan 2011 15:48:50 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p07EmoeK025428 for ; Fri, 7 Jan 2011 15:48:50 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 15:48:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 15:48:30 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401704D5D@DEMUEXC006.nsn-intra.net> In-Reply-To: <4D109B51.8000000@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis-05.txt Thread-Index: AcuhCVnxZQMNr7ghT4uSFWYU4c2J4wNbM9Bw References: <4D109B51.8000000@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 07 Jan 2011 14:48:31.0318 (UTC) FILETIME=[F3B4CF60:01CBAE79] Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:46:46 -0000 Hi All, this is just a reminder that the WGLC for 4742bis draft ends=20 today. Please consider to review the document and send your comments=20 to NETCONF ML. Please state which proposal on ML you support. Please also consider to comment on Wes' mail, which proposes a few new changes. Following issues could benefit from a discussion, e.g.: - How should the LineFeed in section 4.2 be handled? Do we=20 need a special character to make it visible? - Should we keep the example in 4.3. as it was in -04, namely an example for EOM mechanism? - Should we stick the capability to "base:1.1" or state ":base:1.1 or later"? Thank you. Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert (IETF) Wijnen > Sent: Tuesday, December 21, 2010 1:19 PM > To: Netconf > Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis- > 05.txt >=20 >=20 > WG participants, >=20 > This is a 2,5 week (holiday season) WG Last Call for this draft. > The idea is to only check if the agreed upon edits have been made > properly/correctly and if they do not have any unforeseen side > effects/impacts. >=20 > The WG LC ends on Jan 7th, 2011. Please carefully check/review and > send us any comments you may have BEFORE Jan 7th 2011. >=20 > Bert and Mehmet > (Mehmet is the document shepherd) >=20 > Background: >=20 > We have been discussing (on this WG mailing list) a set of changes > to the rfc4742bis draft. This to try and get proper/reasonable framing. >=20 > The WG chairs concluded we do have more or less FULL consensus on > the proposed edits. And so we asked Margaret to make those edits > to the Internet Draft. She did so and the I-D (revision 05) has > been posted. >=20 > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-05.txt > Date: Mon, 20 Dec 2010 14:00:01 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org >=20 >=20 >=20 > 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. >=20 >=20 > Title : Using the NETCONF Configuration Protocol over > Secure Shell (SSH) > Author(s) : M. Wasserman, T. Goddard > Filename : draft-ietf-netconf-rfc4742bis-05.txt > Pages : 13 > Date : 2010-12-20 >=20 > This document describes a method for invoking and running the NETCONF > protocol within a Secure Shell (SSH) session as an SSH subsystem. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis- > 05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@cesnet.cz Fri Jan 7 07:45:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F160F3A6912 for ; Fri, 7 Jan 2011 07:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxVGgOrGxhB5 for ; Fri, 7 Jan 2011 07:45:34 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 7595F3A6914 for ; Fri, 7 Jan 2011 07:45:33 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 22B542CDE05B for ; Fri, 7 Jan 2011 16:47:38 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401704D5D@DEMUEXC006.nsn-intra.net> References: <4D109B51.8000000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A6401704D5D@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 07 Jan 2011 16:47:38 +0100 Message-ID: <1294415258.23524.88.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:45:35 -0000 On Pá, 2011-01-07 at 15:48 +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > this is just a reminder that the WGLC for 4742bis draft ends > today. > > Please consider to review the document and send your comments > to NETCONF ML. Please state which proposal on ML you support. > Please also consider to comment on Wes' mail, which proposes > a few new changes. > > Following issues could benefit from a discussion, e.g.: > > - How should the LineFeed in section 4.2 be handled? Do we > need a special character to make it visible? Yes, it would be better. > - Should we keep the example in 4.3. as it was in -04, namely an example > for EOM mechanism? I objected against the placement of the example in my review of pre-05, the example belongs at the end of sec. 4.2. It is NOT an example of EOM framing, so reading it as a part of 4.3 is confusing. > - Should we stick the capability to "base:1.1" or state ":base:1.1 or > later"? I'd stick to "base:1.1" and extend it with every new version. It could be that a later version again makes some changes to the mechanism. The far end of "later" is very loose. Lada > > Thank you. > > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of ext Bert (IETF) Wijnen > > Sent: Tuesday, December 21, 2010 1:19 PM > > To: Netconf > > Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis- > > 05.txt > > > > > > WG participants, > > > > This is a 2,5 week (holiday season) WG Last Call for this draft. > > The idea is to only check if the agreed upon edits have been made > > properly/correctly and if they do not have any unforeseen side > > effects/impacts. > > > > The WG LC ends on Jan 7th, 2011. Please carefully check/review and > > send us any comments you may have BEFORE Jan 7th 2011. > > > > Bert and Mehmet > > (Mehmet is the document shepherd) > > > > Background: > > > > We have been discussing (on this WG mailing list) a set of changes > > to the rfc4742bis draft. This to try and get proper/reasonable > framing. > > > > The WG chairs concluded we do have more or less FULL consensus on > > the proposed edits. And so we asked Margaret to make those edits > > to the Internet Draft. She did so and the I-D (revision 05) has > > been posted. > > > > -------- Original Message -------- > > Subject: [Netconf] I-D > Action:draft-ietf-netconf-rfc4742bis-05.txt > > Date: Mon, 20 Dec 2010 14:00:01 -0800 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: netconf@ietf.org > > > > > > > > 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 Configuration Protocol over > > Secure Shell (SSH) > > Author(s) : M. Wasserman, T. Goddard > > Filename : draft-ietf-netconf-rfc4742bis-05.txt > > Pages : 13 > > Date : 2010-12-20 > > > > This document describes a method for invoking and running the NETCONF > > protocol within a Secure Shell (SSH) session as an SSH subsystem. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis- > > 05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietfc@btconnect.com Fri Jan 7 10:24:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81003A6825 for ; Fri, 7 Jan 2011 10:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfMv0poGexUP for ; Fri, 7 Jan 2011 10:24:25 -0800 (PST) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by core3.amsl.com (Postfix) with ESMTP id 5F9493A67A1 for ; Fri, 7 Jan 2011 10:24:24 -0800 (PST) Received: from host81-156-207-254.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.254]) by c2beaomr09.btconnect.com with SMTP id BHR65195; Fri, 07 Jan 2011 18:26:29 +0000 (GMT) Message-ID: <01af01cbae8f$926a7dc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ersue, Mehmet \(NSN - DE/Munich\)" , "Netconf" References: <4D109B51.8000000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A6401704D5D@DEMUEXC006.nsn-intra.net> Date: Fri, 7 Jan 2011 18:23:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D275AD5.0082, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D275AD6.007B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:24:27 -0000 Mehmet Just a reminder, I have proposed a visible LineFeed on 28Dec, and also believe that the current text is confusing if not wrong as to what roles the various Line Feeds are playing Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" Sent: Friday, January 07, 2011 3:48 PM Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis-05.txt > Hi All, > > this is just a reminder that the WGLC for 4742bis draft ends > today. > > Please consider to review the document and send your comments > to NETCONF ML. Please state which proposal on ML you support. > Please also consider to comment on Wes' mail, which proposes > a few new changes. > > Following issues could benefit from a discussion, e.g.: > > - How should the LineFeed in section 4.2 be handled? Do we > need a special character to make it visible? > - Should we keep the example in 4.3. as it was in -04, namely an example > for EOM mechanism? > - Should we stick the capability to "base:1.1" or state ":base:1.1 or > later"? > > Thank you. > > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of ext Bert (IETF) Wijnen > > Sent: Tuesday, December 21, 2010 1:19 PM > > To: Netconf > > Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc4742bis- > > 05.txt > > > > > > WG participants, > > > > This is a 2,5 week (holiday season) WG Last Call for this draft. > > The idea is to only check if the agreed upon edits have been made > > properly/correctly and if they do not have any unforeseen side > > effects/impacts. > > > > The WG LC ends on Jan 7th, 2011. Please carefully check/review and > > send us any comments you may have BEFORE Jan 7th 2011. > > > > Bert and Mehmet > > (Mehmet is the document shepherd) > > > > Background: > > > > We have been discussing (on this WG mailing list) a set of changes > > to the rfc4742bis draft. This to try and get proper/reasonable > framing. > > > > The WG chairs concluded we do have more or less FULL consensus on > > the proposed edits. And so we asked Margaret to make those edits > > to the Internet Draft. She did so and the I-D (revision 05) has > > been posted. > > > > -------- Original Message -------- > > Subject: [Netconf] I-D > Action:draft-ietf-netconf-rfc4742bis-05.txt > > Date: Mon, 20 Dec 2010 14:00:01 -0800 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: netconf@ietf.org > > > > > > > > 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 Configuration Protocol over > > Secure Shell (SSH) > > Author(s) : M. Wasserman, T. Goddard > > Filename : draft-ietf-netconf-rfc4742bis-05.txt > > Pages : 13 > > Date : 2010-12-20 > > > > This document describes a method for invoking and running the NETCONF > > protocol within a Secure Shell (SSH) session as an SSH subsystem. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis- > > 05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Wed Jan 12 12:18:01 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D202D3A6A8B for ; Wed, 12 Jan 2011 12:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.679 X-Spam-Level: X-Spam-Status: No, score=-104.679 tagged_above=-999 required=5 tests=[AWL=1.920, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAmNWokIDdHa for ; Wed, 12 Jan 2011 12:18:00 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8D1A63A6A97 for ; Wed, 12 Jan 2011 12:17:59 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0CKKDq5016071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jan 2011 21:20:13 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0CKK9BA028471; Wed, 12 Jan 2011 21:20:13 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 21:20:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Avp9 B3Ah C2R4 FHRY Fp5L HWH2 IFwR IpDm I3os MGMD NzzP N78R Pbl+ Rf+O Rl7G TZxL; 2; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0AOwBuAGUAdABjAG8AbgBmAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {A6218B37-7243-4515-890B-0C09255C984C}; bQBlAGgAbQBlAHQALgBlAHIAcwB1AGUAQABuAHMAbgAuAGMAbwBtAA==; Wed, 12 Jan 2011 20:20:04 GMT; UgBlAHMAdQBsAHQAIABvAGYAIAA0ADcANAAyAGIAaQBzACAAVwBHAEwAQwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {A6218B37-7243-4515-890B-0C09255C984C} Content-class: urn:content-classes:message Date: Wed, 12 Jan 2011 21:20:04 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64017726F2@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Result of 4742bis WGLC Thread-Index: AcuwN7VYy2EcdsrHQUmoyivLluYe+wAkbSAAAAfDAkAALbugcAAx+SGwAArvJLA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 12 Jan 2011 20:20:08.0709 (UTC) FILETIME=[1B8A7B50:01CBB296] Subject: [Netconf] Result of 4742bis WGLC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:18:01 -0000 Hi All, please find below the list of changes I collected so far during WGLC.=20 After some discussion in a small group with the co-chairs, Margaret,=20 Martin, Andy and Juergen, we think this is now the result of the WG=20 last call. - It came out that less experienced implementer find it as helpful to see=20 the "invisible LineFeed" in the examples. We concluded that "\n" is the=20 most common character for this purpose. - We also concluded that we should stick to "base:1.1" and extend it=20 with a new version, which most likely will introduce other changes.=20 Margaret is going to prepare a new version by Friday. As planned we=20 will use the update for AD review and ask Dan to start the necessary=20 process. Mehmet ------------------------------------------------------------------------ -- Section 4.1 ----------- OLD: The previous version of this document defined the character sequence "]]<]]>" as a message separator, NEW: The previous version of this document defined the character sequence "]]>]]>" as a message separator, OLD: (see Section 4.1.1) NEW: (see Section 4.2) OLD: (see Section 4.1.2) NEW: (see Section 4.3) Section 4.2 ------------ OLD: could be encoded as: #4 ## NEW: could be encoded as (using "\n" as a visible representation of the LineFeed character): C: \n#4\n C: \n C: \n C: C: \n##\n OLD: Note that there is no newline character after the 'rpc' end tag, so there is no blank line generated before the '##' line. NEW: In the second and third chunks quoted above, each line is terminated by a LineFeed. For all the XML lines (except the last one), this example=20 treats the LineFeed as part of the chunk-data and so contributing to the=20 chunk-size. Note that there is no LineFeed character after the 'rpc' end-tag in this message. The LineFeed required by the start of the end-of-chunks block immediately follows the last '>' character in the message. Section 4.3 ------------ OLD: To continue the example given above, a NETCONF over SSH session to retrieve a set of configuration information might look like this: NEW: A NETCONF over SSH session, using the backwards-compatible end-of-message framing, to retrieve a set of configuration information might look like this: OLD: C: C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: S: #404 S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: S: ## NEW: C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> Section 5 ---------- OLD: To continue the example used in previous sections, an existing=09 NETCONF subsystem session could be closed as follows: NEW: To continue the example used in section 4.2, an existing=09 NETCONF subsystem session could be closed as follows: OLD: C: C: #141 C: C: C: C: C: ## S: S: #140 S: S: S: S: S: ## NEW: C: \n#140\n C: \n C: \n C: \n C: C: \n##\n S: \n#139\n S: \n S: \n S: \n S: S: \n##\n From kwatsen@juniper.net Wed Jan 12 16:05:54 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7483A6784 for ; Wed, 12 Jan 2011 16:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENEbfkQKuR3K for ; Wed, 12 Jan 2011 16:05:53 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 568313A657C for ; Wed, 12 Jan 2011 16:05:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTS5CbaEJBQ1dazSwE9DN7Em4HzYWJvaX@postini.com; Wed, 12 Jan 2011 16:08:14 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 12 Jan 2011 16:06:31 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Wed, 12 Jan 2011 16:06:28 -0800 Thread-Topic: with-defaults capability string doesn't match it's YANG namespace? Thread-Index: Acuytbnxwn5Mo9xcSbiXy0klkVf36g== Message-ID: <84600D05C20FF943918238042D7670FD37465B9334@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] with-defaults capability string doesn't match it's YANG namespace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:05:54 -0000 >From the "with-defaults" I-D: Section 4.3. Capability Identifier urn:ietf:params:netconf:capability:with-defaults:1.0 Section 5. YANG Module for the Parameter module ietf-netconf-with-defaults { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults= "; Is this allowed? =20 RFC 6020 says in section 5.6.4. Announcing Conformance Information in the <= hello> Message "The namespace URI MUST be advertised as a capability in the NETCONF message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form: capability-string =3D namespace-uri [ parameter-list ]" where namespace-uri is later equated to the namespace URI for the module as= it appears in the 'namespace' statement"... Thanks, Kent From biermana@Brocade.com Wed Jan 12 16:40:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F663A6778 for ; Wed, 12 Jan 2011 16:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igvp-XZIi+LB for ; Wed, 12 Jan 2011 16:40:25 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 2511A3A65A6 for ; Wed, 12 Jan 2011 16:40:25 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0D0UVlE020313; Wed, 12 Jan 2011 16:42:46 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id tsm37045k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Jan 2011 16:42:45 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Jan 2011 16:43:54 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 12 Jan 2011 16:42:45 -0800 From: Andy Bierman To: Kent Watsen , "netconf@ietf.org" Date: Wed, 12 Jan 2011 16:42:43 -0800 Thread-Topic: with-defaults capability string doesn't match it's YANG namespace? Thread-Index: Acuytbnxwn5Mo9xcSbiXy0klkVf36gABMQcQ Message-ID: References: <84600D05C20FF943918238042D7670FD37465B9334@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD37465B9334@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-12_08:2011-01-12, 2011-01-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101120169 Subject: Re: [Netconf] with-defaults capability string doesn't match it's YANG namespace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:40:26 -0000 Hi, This is allowed. The with-defaults capability is separate from the YANG module. Both capabilities are advertised. This was an debated issued during development. My argument for keeping them separate was so that the YANG module capability would be self-contained and consistent. Adding arbitrary extra parameters to that capability URI introduces unwanted coupling in the client and server code. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, January 12, 2011 4:06 PM To: netconf@ietf.org Subject: [Netconf] with-defaults capability string doesn't match it's YANG = namespace? >From the "with-defaults" I-D: Section 4.3. Capability Identifier urn:ietf:params:netconf:capability:with-defaults:1.0 Section 5. YANG Module for the Parameter module ietf-netconf-with-defaults { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults= "; Is this allowed? =20 RFC 6020 says in section 5.6.4. Announcing Conformance Information in the <= hello> Message "The namespace URI MUST be advertised as a capability in the NETCONF message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form: capability-string =3D namespace-uri [ parameter-list ]" where namespace-uri is later equated to the namespace URI for the module as= it appears in the 'namespace' statement"... Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Wed Jan 12 17:52:16 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361EE3A67D1 for ; Wed, 12 Jan 2011 17:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ2noJiK0eIG for ; Wed, 12 Jan 2011 17:52:13 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 9E8463A67E3 for ; Wed, 12 Jan 2011 17:52:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTS5bWnybTUVDr053bBggNfBbN000Uz5m@postini.com; Wed, 12 Jan 2011 17:54:35 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 12 Jan 2011 17:50:35 -0800 From: Kent Watsen To: Andy Bierman , "netconf@ietf.org" Date: Wed, 12 Jan 2011 17:50:33 -0800 Thread-Topic: with-defaults capability string doesn't match it's YANG namespace? Thread-Index: Acuytbnxwn5Mo9xcSbiXy0klkVf36gABMQcQAACZJyA= Message-ID: <84600D05C20FF943918238042D7670FD37465B9441@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD37465B9334@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] with-defaults capability string doesn't match it's YANG namespace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 01:52:16 -0000 > Both capabilities are advertised. Ah, that wasn't clear from the I-D... If another revision is to be publish= ed, maybe add a clarification to section 4.3? Thanks, Kent -----Original Message----- From: Andy Bierman [mailto:biermana@Brocade.com]=20 Sent: Wednesday, January 12, 2011 7:43 PM To: Kent Watsen; netconf@ietf.org Subject: RE: with-defaults capability string doesn't match it's YANG namesp= ace? Hi, This is allowed. The with-defaults capability is separate from the YANG module. Both capabilities are advertised. This was an debated issued during development. My argument for keeping them separate was so that the YANG module capability would be self-contained and consistent. Adding arbitrary extra parameters to that capability URI introduces unwanted coupling in the client and server code. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, January 12, 2011 4:06 PM To: netconf@ietf.org Subject: [Netconf] with-defaults capability string doesn't match it's YANG = namespace? >From the "with-defaults" I-D: Section 4.3. Capability Identifier urn:ietf:params:netconf:capability:with-defaults:1.0 Section 5. YANG Module for the Parameter module ietf-netconf-with-defaults { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults= "; Is this allowed? =20 RFC 6020 says in section 5.6.4. Announcing Conformance Information in the <= hello> Message "The namespace URI MUST be advertised as a capability in the NETCONF message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form: capability-string =3D namespace-uri [ parameter-list ]" where namespace-uri is later equated to the namespace URI for the module as= it appears in the 'namespace' statement"... Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Thu Jan 13 07:27:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9553A6B3F for ; Thu, 13 Jan 2011 07:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHOJwf09oAle for ; Thu, 13 Jan 2011 07:27:04 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 031753A69B9 for ; Thu, 13 Jan 2011 07:27:03 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0DFQbFg014958 for ; Thu, 13 Jan 2011 07:29:26 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id tt1xu82fa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Jan 2011 07:29:26 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Jan 2011 07:30:34 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 13 Jan 2011 07:29:25 -0800 From: Andy Bierman To: "netconf@ietf.org" Date: Thu, 13 Jan 2011 07:29:24 -0800 Thread-Topic: 4741bis, sec. 3, para 2 Thread-Index: AcuzNqgkGceUWhcTSBW0EvZGOo1z0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B11AB91666F22D498EEC66410EB3D3C4F4130A8B0FHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-13_07:2011-01-13, 2011-01-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101130063 Subject: [Netconf] 4741bis, sec. 3, para 2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:27:07 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F4130A8B0FHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This paragraph is holding up 4741bis, so let's see if it can be improved, but I will just remove my objection either way. Issues: - 'message' is too generic. The server never responds to a bad with - MUST is not realistic; what if the server is out of memory, or s= ome severe resource impairment is occurring? The server must have the option of dropping the s= ession. - The server must do something when it gets a message. Drop and i= gnore the message will only cause the client to timeout. Better to drop the session and get it over wi= th faster. OLD: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. NEW: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an 'rpc' message that is not well-formed XML, it SHOULD re= ply with an 'operation-failed' error. If a reply cannot be sent for any reason, the server MUST close the session. Andy --_000_B11AB91666F22D498EEC66410EB3D3C4F4130A8B0FHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This parag= raph is holding up 4741bis, so let’s see if it can be improved,
bu= t  I will just remove my objection either way.

 

Issues:

-    = ;      ‘message̵= 7; is too generic.  The server never responds to a bad <hello>with <rpc-reply>

-          MUST is not realistic; what if the server is out of memor= y, or some severe resource
impairment is occurring?  The server mus= t have the option of dropping the session.

-       = ;   The server must do something when it = gets a message.  Drop and ignore the message will only
cause the c= lient to timeout.  Better to drop the session and get it over with fas= ter.

 

OLD:

 

&n= bsp;  All NETCONF messages MUST be well-formed XML, encoded in UTF-8.&= nbsp; If a

   peer receives a message t= hat is not well-formed XML, it MUST reply

 &= nbsp; with an 'operation-failed' error.

&nbs= p;

NEW:

 

   All NETCONF messages MUST be we= ll-formed XML, encoded in UTF-8.  If a

&nb= sp;  peer receives an ‘rpc’ message that is not well-forme= d XML, it SHOULD reply

   with an 'oper= ation-failed' error.  If a reply cannot be sent for
   an= y reason, the server MUST close the session.

 

 

Andy

 

&n= bsp;

= --_000_B11AB91666F22D498EEC66410EB3D3C4F4130A8B0FHQ1EXCH01corp_-- From j.schoenwaelder@jacobs-university.de Thu Jan 13 07:31:25 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBFC3A6B9A for ; Thu, 13 Jan 2011 07:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.117 X-Spam-Level: X-Spam-Status: No, score=-103.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXDqWsJ19X7h for ; Thu, 13 Jan 2011 07:31:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 51D0D3A69B9 for ; Thu, 13 Jan 2011 07:31:23 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B46C7C0021; Thu, 13 Jan 2011 16:33:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W0xTNIYm-iNQ; Thu, 13 Jan 2011 16:33:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65880C005C; Thu, 13 Jan 2011 16:33:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8588B161C737; Thu, 13 Jan 2011 16:33:38 +0100 (CET) Date: Thu, 13 Jan 2011 16:33:38 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20110113153338.GA8764@elstar.local> Mail-Followup-To: Andy Bierman , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] 4741bis, sec. 3, para 2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:31:25 -0000 On Thu, Jan 13, 2011 at 07:29:24AM -0800, Andy Bierman wrote: > OLD: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > peer receives a message that is not well-formed XML, it MUST reply > with an 'operation-failed' error. > > NEW: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > peer receives an 'rpc' message that is not well-formed XML, it SHOULD reply > with an 'operation-failed' error. If a reply cannot be sent for > any reason, the server MUST close the session. Looks good to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Sat Jan 15 05:59:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDB43A6D2A for ; Sat, 15 Jan 2011 05:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.242 X-Spam-Level: X-Spam-Status: No, score=-100.242 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0rddtK+aNkV for ; Sat, 15 Jan 2011 05:59:07 -0800 (PST) Received: from relay.versatel.net (relay61.tele2.vuurwerk.nl [62.250.3.61]) by core3.amsl.com (Postfix) with ESMTP id AC6E43A6A5D for ; Sat, 15 Jan 2011 05:59:04 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Pe6hA-000532-4i; Sat, 15 Jan 2011 15:01:32 +0100 Message-ID: <316DD7F6955E4E01A77EF44C2AF1473E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" Date: Sat, 15 Jan 2011 15:01:06 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: Netconf Subject: [Netconf] Fw: list of 4741bis edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 13:59:07 -0000 In the email below is the list of changes that were poste to the list on Dec 15. We believe we have not heard any objections to the below list, but there was some more discussion on one piece of text for which we (WG chairs) believe we have consensus on a change: OLD: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. NEW: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an 'rpc' message that is not well-formed XML, it SHOULD reply with an 'operation-failed' error. If a reply cannot be sent for any reason, the server MUST close the session. Martin, can you please apply these changes and submit a new I-D, so we can hand it back to our AD. Thanks, Bert and Mehmet ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Netconf" ; "Martin Bjorklund" Sent: Wednesday, December 15, 2010 8:55 AM Subject: Re: [Netconf] list of 4741bis edits > Not having heard any objections to this, we suggest that Martin > puts a new revision out for this document later this week. > > If you DO HAVE objections, PLEASE SPEAK up ASAP. > > Bert and Mehmet > > > > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Sent: Friday, December 10, 2010 2:40 PM > Subject: [Netconf] list of 4741bis edits > > > Hi, > > As requested by the chairs, this is a list of proposed edits for > 4741bis. There are a few editorial changes, and two technical > changes. One is a fix for the XML Schema bug reported by Kent, and > one is a fix for the 'data' response element in the YANG module. > > > /martin > > > Section 4.2., paragraph 1: > OLD: > > The message is sent in response to an operation. > > NEW: > > The message is sent in response to an message. > > > Section 7.5., paragraph 6: > OLD: > > A lock MUST not be granted if either of the following conditions > is true: > > NEW: > > A lock MUST NOT be granted if either of the following conditions > is true: > > > Appendix B., paragraph 4: > OLD: > > This schema defines the syntax for the NETCONF Message layer > > NEW: > > This schema defines the syntax for the NETCONF Messages layer > > > > > Appendix B., paragraph 6: > OLD: > > > > > > > use="optional"/> > > > > > > minOccurs="0" maxOccurs="unbounded"/> > minOccurs="0" maxOccurs="unbounded"/> > > > > > NEW: > > > > > minOccurs="0" maxOccurs="unbounded"/> > minOccurs="0" maxOccurs="unbounded"/> > > > use="optional"/> > > > > > > > type="rpcResponseType" abstract="true"/> > > > Appendix C., paragraph 46: > OLD: > > output { > container data { > presence > "An empty data container indicates that the > request did not produce any results."; > description > "Copy of the source datastore subset which matched > the filter criteria (if any)."; > } > } > } > > NEW: > > output { > anyxml data { > description > "Copy of the source datastore subset which matched > the filter criteria (if any). An empty data container > indicates that the request did not produce any results."; > } > } > } > > > Appendix C., paragraph 84: > OLD: > > output { > container data { > presence > "An empty data container indicates that the filter > request did not match any results."; > description > "Copy of the running datastore subset and/or state > data which matched the filter criteria (if any)."; > } > } > } > > NEW: > > output { > anyxml data { > description > "Copy of the running datastore subset and/or state > data which matched the filter criteria (if any). > An empty data container indicates that the request did not > produce any results."; > } > } > } > ___ From Internet-Drafts@ietf.org Sun Jan 16 05:30:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5603A6E53; Sun, 16 Jan 2011 05:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFVQOzqhbgJu; Sun, 16 Jan 2011 05:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3B43A6E4C; Sun, 16 Jan 2011 05:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110116133001.9798.54392.idtracker@localhost> Date: Sun, 16 Jan 2011 05:30:01 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 13:30:04 -0000 --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 : Network Configuration Protocol (NETCONF) Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-07.txt Pages : 121 Date : 2011-01-16 The Network Configuration Protocol (NETCONF) 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 as Remote Procedure Calls (RPC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-netconf-4741bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-16052941.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Mon Jan 17 00:12:47 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100653A6EB0 for ; Mon, 17 Jan 2011 00:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY4gRTC70c8x for ; Mon, 17 Jan 2011 00:12:46 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 855163A6EA1 for ; Mon, 17 Jan 2011 00:12:43 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PekF8-0003Qn-BY for netconf@ietf.org; Mon, 17 Jan 2011 09:15:15 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PekF8-00029O-92 for netconf@ietf.org; Mon, 17 Jan 2011 09:15:14 +0100 Message-ID: <4D33FA93.5040407@bwijnen.net> Date: Mon, 17 Jan 2011 09:15:15 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fe4c53b80b05361988c8a3d7ffab13e7 Subject: [Netconf] Handing over to our AD: New Version Notification - draft-ietf-netconf-4741bis-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:12:47 -0000 Dear WG participants, We plan to hand this new version back to our AD. The changes that were made have been discussed and found no objections on the WG mailing list. Nevertheless, We'll give you all till Wednesday (any timezone) to check to make sure all is still OK with you. Bert and Mehmet -------- Original Message -------- Subject: New Version Notification - draft-ietf-netconf-4741bis-07.txt Date: Sun, 16 Jan 2011 05:30:02 -0800 From: Internet-Draft@ietf.org To: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, dromasca@avaya.com New version (-07) has been submitted for draft-ietf-netconf-4741bis-07.txt. http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-07.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-4741bis-07 IETF Secretariat. From bertietf@bwijnen.net Thu Jan 20 06:24:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98593A7122 for ; Thu, 20 Jan 2011 06:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBqAsiDpySA7 for ; Thu, 20 Jan 2011 06:24:02 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 01C213A7102 for ; Thu, 20 Jan 2011 06:24:00 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PfvTE-0001tJ-HH for netconf@ietf.org; Thu, 20 Jan 2011 15:26:42 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PfvTE-0002n9-DB for netconf@ietf.org; Thu, 20 Jan 2011 15:26:40 +0100 Message-ID: <4D384620.7010408@bwijnen.net> Date: Thu, 20 Jan 2011 15:26:40 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48c85727e7929f3bbae2049ead6a08bc0 Subject: [Netconf] 4741bis is back in the hands of our AD: for publication as PS RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:24:04 -0000 Since I did not see any comments, it is now back in our AD's capable hands. Bert -------- Original Message -------- Subject: Request to consider for publication as PS RFC Date: Thu, 20 Jan 2011 15:24:56 +0100 From: Bert Wijnen To: iesg-secreatary@ietf.org, Dan Romascanu Hi Dan, thanks for HOLDing the revision 6 that I had originally submitted. We have in the meanwhile made a few small (mainly editorial) changes to. The new modified writeup is below. Bert Wijnen Document shepherd ---- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Bert Wijnen is the document shepherd. Yes, I have reviewed the document many times, including this version 7, that I believe is ready for forwarding to the AD/IESG (this is a small, mainly editorial update after the revision 06 was on HOLD in the AD Queue). (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had wide review and re-reviews of NETCONF WG members. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The content of the document has strong WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Document passes ID-nits (as shown by the IETF idnits tool: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/ draft-ietf-netconf-4741bis-07.txt (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published except draft-ietf-netconf-rfc4742bis, but that is also being submitted for IESG consideration as proposed standard. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? IANA considerations are present and complete. No new namespaces are created and so no new Expert is needed. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The YANG and XSD modules have been checked by Martin Bjorklund. XSD also checked by co-chair Mehmet and I (Bert) have checked YANG. Both are found to be valid. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Network Configuration Protocol (NETCONF) 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 as Remote Procedure Calls (RPC). This revision of the document clarifies some text and fixes some minor bugs as found from implementatition experience of rfc4741. Working Group Summary The working group went over several versions of the document. The comments and reviews helped improve the document a lot and brought us to consensus on the 7th revision of the docuemnt. Document Quality There are implementations of this protocol, and in fact the rfc4741bis revision is based on implementation experience of that rfc. From kwatsen@juniper.net Thu Jan 20 15:18:25 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDE93A6858 for ; Thu, 20 Jan 2011 15:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qBvCaN1qCX7 for ; Thu, 20 Jan 2011 15:18:25 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id E53AD3A6884 for ; Thu, 20 Jan 2011 15:18:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTTjDZfkSKPHSdmqv7FR7cKF5D5oUiy2c@postini.com; Thu, 20 Jan 2011 15:21:09 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 20 Jan 2011 15:21:01 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Thu, 20 Jan 2011 15:20:58 -0800 Thread-Topic: namespace passing Thread-Index: Acu4+LITUqXpxAosTamF2em0ZDYCYg== Message-ID: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:18:26 -0000 Does NETCONF require devices to support all valid forms of namespace passin= g? The following 6 instance documents are all valid 1. write code 2. write code 3. write code 4. write code 5. write code 6. write code To both of the following two schemas (yes, all 12 combinations pass): module foo { namespace "http://acme.example.com/foo/1.0"; prefix "foo"; revision 2011-01-16 { description "Initial conception"; } rpc do-something { input { leaf what { type string; } } } } We typically see #1 used in the NETCONF and NETMOD RFCs, though 4741bis-07 = does have one example like #3 (on pg 25) and all examples in RFC 5751 use #= 5. Nowhere in 4741bis-07 does it asserts one form over the other, or provide a= means whereby a device can advertise which forms it supports. Since stand= ard validators support all forms, is it correct to assume that NETCONF serv= ers MUST support all forms? Furthermore, what statement can be made about the RPC-reply? Is it correct= to assume that NETCONF clients MUST support all forms, or can we assume th= e server to mimic the form used by the client? I'm asking because my experience is that most NETCONF implementations (both= servers and clients) hardcode one strategy only and either fail to process= an RPC passed using another form or fails to send the reply using any of t= he valid forms, which is causing various interoperability issues. =20 Thanks, Kent From ietf@andybierman.com Thu Jan 20 15:42:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59D13A6876 for ; Thu, 20 Jan 2011 15:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG1jRtgYZhlq for ; Thu, 20 Jan 2011 15:42:17 -0800 (PST) Received: from nm1.bullet.mail.ac4.yahoo.com (nm1.bullet.mail.ac4.yahoo.com [98.139.52.198]) by core3.amsl.com (Postfix) with SMTP id B1C413A6872 for ; Thu, 20 Jan 2011 15:42:17 -0800 (PST) Received: from [98.139.52.196] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 20 Jan 2011 23:45:01 -0000 Received: from [98.139.52.162] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 20 Jan 2011 23:45:01 -0000 Received: from [127.0.0.1] by omp1045.mail.ac4.yahoo.com with NNFMP; 20 Jan 2011 23:45:01 -0000 X-Yahoo-Newman-Id: 912008.37037.bm@omp1045.mail.ac4.yahoo.com Received: (qmail 72317 invoked from network); 20 Jan 2011 23:45:01 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp105.sbc.mail.ac4.yahoo.com with SMTP; 20 Jan 2011 15:44:58 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: OzuhYVUVM1k2c13oA0pEwVyAI3n__Sk3V2MVKFrI092LhLu _2vDsOsdLqA2yTkFtQNEx8a209VAIeykjkFjBWNW75Z_1e32vyK6JLq5Di8h rjy_ieRr.xBFIItRtvrSSBoNX3cjvylkvSoFLudwvHB.qiwr8MfPrkCEwsJ7 q_3t2m9rIgzG.AkzZEdvGaeeTRS7_Gqd5K.ErcITpRVx9kGtQBo4zVMdwKCx 874UlzVrSYwRkYiumjuZ1qEDGdpcN6GBijj0CpoqgvFW6dBrpUV8Y_D6DMYj Kjvt_5AskNT6WqNVLe5yW2Jm3AQav2DUcwkW_KcEmzSR6HRX9qiOUNaiGRQw YPIb5Q3uhZJdCmM4jm.4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D38C900.6050104@andybierman.com> Date: Thu, 20 Jan 2011 15:45:04 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:42:18 -0000 On 01/20/2011 03:20 PM, Kent Watsen wrote: > > Does NETCONF require devices to support all valid forms of namespace passing? > > yes. XML makes the rules here, not NETCONF. I recently changed yuma to do (1) instead of (6), to minimize message size. Libxml2 handles all forms so I suspect clients that use libxml2 will not have any problems. Is your concern that small footprint servers cannot support all forms? Andy > The following 6 instance documents are all valid > > 1. message-id="101"> > > write code > > > > 2. xmlns:foo="http://acme.example.com/foo/1.0" > message-id="101"> > > write code > > > > 3. message-id="101"> > > write code > > > > 4. message-id="101"> > > write code > > > > 5. xmlns="http://acme.example.com/foo/1.0" > message-id="101"> > > write code > > > > 6. message-id="101"> > > write code > > > > > > To both of the following two schemas (yes, all 12 combinations pass): > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="http://acme.example.com/foo/1.0" > targetNamespace="http://acme.example.com/foo/1.0" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > module foo { > namespace "http://acme.example.com/foo/1.0"; > prefix "foo"; > revision 2011-01-16 { > description "Initial conception"; > } > rpc do-something { > input { > leaf what { > type string; > } > } > } > } > > > We typically see #1 used in the NETCONF and NETMOD RFCs, though 4741bis-07 does have one example like #3 (on pg 25) and all examples in RFC 5751 use #5. > > Nowhere in 4741bis-07 does it asserts one form over the other, or provide a means whereby a device can advertise which forms it supports. Since standard validators support all forms, is it correct to assume that NETCONF servers MUST support all forms? > > Furthermore, what statement can be made about the RPC-reply? Is it correct to assume that NETCONF clients MUST support all forms, or can we assume the server to mimic the form used by the client? > > I'm asking because my experience is that most NETCONF implementations (both servers and clients) hardcode one strategy only and either fail to process an RPC passed using another form or fails to send the reply using any of the valid forms, which is causing various interoperability issues. > > Thanks, > Kent > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From kwatsen@juniper.net Fri Jan 21 06:07:28 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FE63A699C for ; Fri, 21 Jan 2011 06:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh-OyrMuJVzU for ; Fri, 21 Jan 2011 06:07:27 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 2FD553A6998 for ; Fri, 21 Jan 2011 06:07:27 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTTmTxAywpdN9vdClgdM4GaqJvHCnjATY@postini.com; Fri, 21 Jan 2011 06:10:13 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 21 Jan 2011 06:10:04 -0800 From: Kent Watsen To: Andy Bierman Date: Fri, 21 Jan 2011 06:09:59 -0800 Thread-Topic: [Netconf] namespace passing Thread-Index: Acu4/A8Fk39EvX61RRCR+p39LyTeLgAdiOOw Message-ID: <84600D05C20FF943918238042D7670FD374A9A4886@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> <4D38C900.6050104@andybierman.com> In-Reply-To: <4D38C900.6050104@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:07:28 -0000 > yes. > XML makes the rules here, not NETCONF. Good point. > Libxml2 handles all forms so I suspect clients that use libxml2 > will not have any problems. > > Is your concern that small footprint servers cannot support all forms? Definitely an issue on small footprint servers, but I think it's also an is= sue for others. I don't have the root-cause yet, but it seems that there a= re issues whenever a prefix is passed. I assume this is because libxml2 re= turns "nc:rpc" which fails a simple strcmp(name,"rpc") test. Limiting our = clients to just using #1 works, but I didn't see it stated in 4741 that we = had to, which is why I asked. Could you also respond to the 2nd part of my question regarding RPC-Replies= ? Is it correct to assume that NETCONF clients MUST support all forms, or = can we assume the server to mimic the form used by the client? I see that 4741biz-07 says:=20 If additional attributes are present in an element, a NETCONF peer MUST return them unmodified in the element. This includes any "xmlns" attributes. Does that mean that if the client uses #5 and there is an error, the server= must reply as follows: ... =20 Thanks, Kent From mbj@tail-f.com Fri Jan 21 06:59:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B93F3A6995 for ; Fri, 21 Jan 2011 06:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcBYzDdT-TrL for ; Fri, 21 Jan 2011 06:59:10 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 683693A6908 for ; Fri, 21 Jan 2011 06:59:10 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BE4BE616001; Fri, 21 Jan 2011 16:01:54 +0100 (CET) Date: Fri, 21 Jan 2011 16:01:54 +0100 (CET) Message-Id: <20110121.160154.151450421.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD374A9A4886@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> <4D38C900.6050104@andybierman.com> <84600D05C20FF943918238042D7670FD374A9A4886@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:59:11 -0000 Hi, Kent Watsen wrote: > Could you also respond to the 2nd part of my question regarding RPC-Replies? > Is it correct to assume that NETCONF clients MUST support all forms, or can we > assume the server to mimic the form used by the client? The server may use any legal XML form. So a well-written client should be prepared for any form. > I see that 4741biz-07 says: > > If additional attributes are present in an element, a NETCONF > peer MUST return them unmodified in the element. This > includes any "xmlns" attributes. > > Does that mean that if the client uses #5 and there is an error, the server > must reply as follows: > > xmlns="http://acme.example.com/foo/1.0" > message-id="101"> It could also reply with, e.g.: I still think that the rule that xmlns attribs are copied verbatim is unfortunate. /martin From lhotka@cesnet.cz Fri Jan 21 07:10:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8391C3A69FF for ; Fri, 21 Jan 2011 07:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYneFHcq5XWS for ; Fri, 21 Jan 2011 07:10:42 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 446C43A6A05 for ; Fri, 21 Jan 2011 07:10:42 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id B96B42CDE05B for ; Fri, 21 Jan 2011 16:13:26 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <20110121.160154.151450421.mbj@tail-f.com> References: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> <4D38C900.6050104@andybierman.com> <84600D05C20FF943918238042D7670FD374A9A4886@EMBX01-HQ.jnpr.net> <20110121.160154.151450421.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 21 Jan 2011 16:13:25 +0100 Message-ID: <1295622805.1647.84.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:10:43 -0000 On Pá, 2011-01-21 at 16:01 +0100, Martin Bjorklund wrote: > Hi, > > Kent Watsen wrote: > > Could you also respond to the 2nd part of my question regarding RPC-Replies? > > Is it correct to assume that NETCONF clients MUST support all forms, or can we > > assume the server to mimic the form used by the client? > > The server may use any legal XML form. So a well-written client > should be prepared for any form. > > > > I see that 4741biz-07 says: > > > > If additional attributes are present in an element, a NETCONF > > peer MUST return them unmodified in the element. This > > includes any "xmlns" attributes. > > > > Does that mean that if the client uses #5 and there is an error, the server > > must reply as follows: > > > > > xmlns="http://acme.example.com/foo/1.0" > > message-id="101"> > > It could also reply with, e.g.: > > xmlns:foo="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="http://acme.example.com/foo/1.0" > message-id="101"> > > > I still think that the rule that xmlns attribs are copied verbatim is > unfortunate. +1 (and one could also use more expressive words). Lada > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Fri Jan 21 12:28:56 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B953A67E2 for ; Fri, 21 Jan 2011 12:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOgd+IK-ohfw for ; Fri, 21 Jan 2011 12:28:55 -0800 (PST) Received: from nm8.bullet.mail.ne1.yahoo.com (nm8.bullet.mail.ne1.yahoo.com [98.138.90.71]) by core3.amsl.com (Postfix) with SMTP id 3AC083A67C2 for ; Fri, 21 Jan 2011 12:28:54 -0800 (PST) Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2011 20:31:38 -0000 Received: from [98.138.89.164] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2011 20:31:38 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 21 Jan 2011 20:31:38 -0000 X-Yahoo-Newman-Id: 654978.23048.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 30355 invoked from network); 21 Jan 2011 20:31:38 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 21 Jan 2011 12:31:35 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: gG00zV4VM1n0_wU_DE3AP9mmOEgqRjl1vNmIa_1fPC40nXG wUPEI1f7WnFkM6XUCpn80X2VO6wjyKpiipS6NZqptTOcjlBSGejenTJFSPmk hf1qo8C8ddpNiRUFK73cFsONZxZ1r5YLykTK3Bb4Qi53paQs889xSRXR52gG XrB40H_xJrL6A0tPtyGyX.xans_5rG3k5E3NQdsKFVboK1HK7Usv1EpgxJ1R Bgnt549iNRUeT4WPdnx6_IHO7P2rntVRjqMsUTJ0NT9ToG1nkB0nZ1.vk.yM D1SGLdSG3FK4OYVtTwSnzQzYz3XOW1M1zua6yTZabjqDgGMm.9O90V_XUnKH 2OBb8oefAqoOpTm0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D39ED35.6080105@andybierman.com> Date: Fri, 21 Jan 2011 12:31:49 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <84600D05C20FF943918238042D7670FD374A9A4497@EMBX01-HQ.jnpr.net> <4D38C900.6050104@andybierman.com> <84600D05C20FF943918238042D7670FD374A9A4886@EMBX01-HQ.jnpr.net> <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> In-Reply-To: <1295622805.1647.84.camel@behold> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 20:28:56 -0000 On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: ... >> I still think that the rule that xmlns attribs are copied verbatim is >> unfortunate. > > +1 (and one could also use more expressive words). > I was opposed to changing this in the past, but now I think I got it wrong. The dynamic nature of xmlns attributes is built into XML, and NETCONF steps on XML by mandating that the xmlns to prefix mappings must be maintained from request to reply. Reality is that implementations will only go so far to support preservation of these prefix mappings (i.e, from none to some to all). This 'feature' was originally put in because Junos needed it. Is that still the case? Is anybody writing clients that add extra attributes to the start tag? > Lada > Andy From mbj@tail-f.com Fri Jan 21 13:11:23 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E613A6828 for ; Fri, 21 Jan 2011 13:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIMHCSSiO4yu for ; Fri, 21 Jan 2011 13:11:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B2E73A6AA4 for ; Fri, 21 Jan 2011 13:11:18 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D556616001; Fri, 21 Jan 2011 22:14:04 +0100 (CET) Date: Fri, 21 Jan 2011 22:14:03 +0100 (CET) Message-Id: <20110121.221403.250794340.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4D39ED35.6080105@andybierman.com> References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:11:23 -0000 Andy Bierman wrote: > On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: > ... > >> I still think that the rule that xmlns attribs are copied verbatim is > >> unfortunate. > > > > +1 (and one could also use more expressive words). > > > > I was opposed to changing this in the past, > but now I think I got it wrong. The dynamic nature of xmlns > attributes > is built into XML, and NETCONF steps on XML by mandating that the > xmlns to prefix mappings must be maintained from request to reply. > > Reality is that implementations will only go so far to support > preservation of these prefix mappings (i.e, from none to some to all). > This 'feature' was originally put in because Junos needed it. I think they wanted to preserve some attributes, but not necessarily xmlns attributes. Maybe the juniper people can reply to this, but I'm pretty sure they do not handle all variants of xmlns attributes in the input (e.g. ). I'm also pretty sure that my implementation does not handle all corner cases either... I think we can keep the rule to preserve non-xmlns attribs, but it would be great to get rid of the rule to preserve xmlns attribs. /martin From phil@juniper.net Fri Jan 21 13:35:23 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AA53A67FD for ; Fri, 21 Jan 2011 13:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsJ1MlCLhSyc for ; Fri, 21 Jan 2011 13:35:22 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 820B93A67F8 for ; Fri, 21 Jan 2011 13:35:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTTn8v6MdM4OEdxH1Tgxy268B278JtuRX@postini.com; Fri, 21 Jan 2011 13:38:09 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 21 Jan 2011 13:29:32 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p0LLTVU84745; Fri, 21 Jan 2011 13:29:31 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p0LL75ZX027065; Fri, 21 Jan 2011 21:07:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201101212107.p0LL75ZX027065@idle.juniper.net> To: Andy Bierman In-Reply-To: <4D39ED35.6080105@andybierman.com> Date: Fri, 21 Jan 2011 16:07:05 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:35:23 -0000 Andy Bierman writes: >Reality is that implementations will only go so far to support >preservation of these prefix mappings (i.e, from none to some to all). >This 'feature' was originally put in because Junos needed it. >Is that still the case? Is anybody writing clients that add extra >attributes to the start tag? I've used it to put "host", "time", and "command" attributes on RPC input so I can carry this information in the RPC output. Thanks, Phil From ietf@andybierman.com Fri Jan 21 13:37:37 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FE03A67F8 for ; Fri, 21 Jan 2011 13:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y85YWoawsqXD for ; Fri, 21 Jan 2011 13:37:36 -0800 (PST) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by core3.amsl.com (Postfix) with SMTP id 70F3C3A67C2 for ; Fri, 21 Jan 2011 13:37:36 -0800 (PST) Received: from [98.139.52.189] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 21:40:20 -0000 Received: from [98.139.52.178] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 21:40:20 -0000 Received: from [127.0.0.1] by omp1061.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 21:40:20 -0000 X-Yahoo-Newman-Id: 597173.11651.bm@omp1061.mail.ac4.yahoo.com Received: (qmail 91449 invoked from network); 21 Jan 2011 21:40:20 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp105.sbc.mail.ac4.yahoo.com with SMTP; 21 Jan 2011 13:40:17 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: nnpvMTsVM1leu0XZXztcETh8EBqzKysMTKOkbLc1Kj3sR1m JvniPJ0l9jPhpMLTGw6R06DCM93tkOT4harPX_2O5aTV9B2VF37CdMxH5dH3 Wz5tam3lNLhYHvC_8f5_0MXMAJkPFltxElALGdLIgEZHXp75A35uZL2_3_UU 9R4nkKLIWhvgabG9Oh2tSu..2NAeK.qPeq4BcO4IJmasUPeLYfuNinX0dxo_ aBGWpeGSzr0ZSFv.7l_CtngIim6Im6Iy1pTevJ9pfX2B2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D39FD4F.8030507@andybierman.com> Date: Fri, 21 Jan 2011 13:40:31 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Bjorklund References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> In-Reply-To: <20110121.221403.250794340.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:37:37 -0000 On 01/21/2011 01:14 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: >> ... >>>> I still think that the rule that xmlns attribs are copied verbatim is >>>> unfortunate. >>> >>> +1 (and one could also use more expressive words). >>> >> >> I was opposed to changing this in the past, >> but now I think I got it wrong. The dynamic nature of xmlns >> attributes >> is built into XML, and NETCONF steps on XML by mandating that the >> xmlns to prefix mappings must be maintained from request to reply. >> >> Reality is that implementations will only go so far to support >> preservation of these prefix mappings (i.e, from none to some to all). >> This 'feature' was originally put in because Junos needed it. > > I think they wanted to preserve some attributes, but not necessarily > xmlns attributes. Maybe the juniper people can reply to this, but I'm > pretty sure they do not handle all variants of xmlns attributes in the > input (e.g.). I'm also pretty sure > that my implementation does not handle all corner cases either... > I know yuma has 2 hack/corner-cases: - prefix 'nc' is reserved for NETCONF; if an xmlns attribute from the is using this prefix, it will get removed. - default namespace is reserved for NETCONF (in ); if a default xmlns attribute was in the it will get deleted > I think we can keep the rule to preserve non-xmlns attribs, but it > would be great to get rid of the rule to preserve xmlns attribs. > I agree! Preserving non-xmlns attributes is not a problem unless they are qualified, or their content contains XML prefixes. IMO, we should not have to support that. Only simple string content will be preserved in unqualified attributes. > > /martin > > Andy From Internet-Drafts@ietf.org Mon Jan 24 06:15:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E651A3A68EC; Mon, 24 Jan 2011 06:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ibevaqxmXro; Mon, 24 Jan 2011 06:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354BE3A68E3; Mon, 24 Jan 2011 06:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124141502.660.71668.idtracker@localhost> Date: Mon, 24 Jan 2011 06:15:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 14:15:03 -0000 --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 Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-06.txt Pages : 13 Date : 2011-01-24 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-netconf-rfc4742bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24060832.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Mon Jan 24 06:57:56 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A123A6AE5; Mon, 24 Jan 2011 06:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsjNZvJw9osq; Mon, 24 Jan 2011 06:57:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B793A68E9; Mon, 24 Jan 2011 06:57:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124145755.11026.47818.idtracker@localhost> Date: Mon, 24 Jan 2011 06:57:55 -0800 Cc: netconf@ietf.org Subject: [Netconf] Last Call: (Network Configuration Protocol (NETCONF)) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 14:57:56 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Network Configuration Protocol (NETCONF)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ No IPR declarations have been submitted directly on this I-D. From mehmet.ersue@nsn.com Mon Jan 24 07:29:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBCC3A68E6 for ; Mon, 24 Jan 2011 07:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.781 X-Spam-Level: X-Spam-Status: No, score=-104.781 tagged_above=-999 required=5 tests=[AWL=1.818, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhDEmhWdmnlg for ; Mon, 24 Jan 2011 07:29:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1E5253A68D5 for ; Mon, 24 Jan 2011 07:29:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0OFVqp1001213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Jan 2011 16:31:53 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0OFVp1n021906 for ; Mon, 24 Jan 2011 16:31:52 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 16:31:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 24 Jan 2011 16:31:50 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64018521D9@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handing back to our AD: New Version Notification - draft-ietf-netconf-rfc4742bis-06.txt Thread-Index: Acu70YjWdDx7H+nfQOmFzhy7+npsSgACNo5g From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 24 Jan 2011 15:31:51.0732 (UTC) FILETIME=[D2B23F40:01CBBBDB] Subject: [Netconf] Handing back to our AD: New Version Notification - draft-ietf-netconf-rfc4742bis-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:29:03 -0000 RGVhciBORVRDT05GIFdHLA0KDQp2MDYgb2YgNDc0MmJpcyBpcyBvdXQuIFdlIHBsYW4gdG8gZ2l2 ZSB0aGUgbmV3IHZlcnNpb24gDQpiYWNrIHRvIG91ciBBRC4gVGhlcmUgaGFzIGJlZW4gbG9uZyBk aXNjdXNzaW9ucyBvbiA0NzQyYmlzLCANCndoaWNoIGludHJvZHVjZXMgbm93IHRoZSBDaHVua2Vk IEZyYW1pbmcgTWVjaGFuaXNtLiBXZSANCmhhZCBhIFdHTEMgYW5kIE1hcmdhcmV0IHJldmlzZWQg dGhlIGRyYWZ0IGJhc2VkIG9uIHRoZSANCmFncmVlZCBjaGFuZ2UgcmVxdWVzdHMuDQoNCldlIHdh bnQgdG8gZ2l2ZSB5b3UgdGltZSB0aWxsIFdlZG5lc2RheSBFT0IgdG8gbWFrZSBzdXJlIA0KeW91 IGNhbiBnbyB3aXRoIGl0Lg0KDQpNZWhtZXQgJiBCZXJ0DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGV4dCBJbnRlcm5ldC1EcmFmdEBpZXRmLm9yZyBbbWFpbHRvOkludGVy bmV0LURyYWZ0QGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAxMSAzOjE1 IFBNDQpUbzogbmV0Y29uZi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbmV0Y29u Zi1yZmM0NzQyYmlzQHRvb2xzLmlldGYub3JnOyBkcm9tYXNjYUBhdmF5YS5jb20NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlz LTA2LnR4dA0KDQpOZXcgdmVyc2lvbiAoLTA2KSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRyYWZ0 LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTA2LnR4dC4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTA2LnR4dCANCg0KDQpE aWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMtMDYgDQoNCklFVEYgU2VjcmV0YXJp YXQuDQo= From lhotka@cesnet.cz Mon Jan 24 07:51:29 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A802C3A6AF0 for ; Mon, 24 Jan 2011 07:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wXw31mxc+xd for ; Mon, 24 Jan 2011 07:51:26 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 0C7E13A68E6 for ; Mon, 24 Jan 2011 07:51:26 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id E231A2CDE04B; Mon, 24 Jan 2011 16:54:18 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20110121.221403.250794340.mbj@tail-f.com> References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Jan 2011 16:54:23 +0100 Message-ID: <1295884463.4317.43.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:51:30 -0000 On Pá, 2011-01-21 at 22:14 +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: > > ... > > >> I still think that the rule that xmlns attribs are copied verbatim is > > >> unfortunate. > > > > > > +1 (and one could also use more expressive words). > > > > > > > I was opposed to changing this in the past, > > but now I think I got it wrong. The dynamic nature of xmlns > > attributes > > is built into XML, and NETCONF steps on XML by mandating that the > > xmlns to prefix mappings must be maintained from request to reply. > > > > Reality is that implementations will only go so far to support > > preservation of these prefix mappings (i.e, from none to some to all). > > This 'feature' was originally put in because Junos needed it. > > I think they wanted to preserve some attributes, but not necessarily > xmlns attributes. Maybe the juniper people can reply to this, but I'm > pretty sure they do not handle all variants of xmlns attributes in the > input (e.g. ). I'm also pretty sure > that my implementation does not handle all corner cases either... > > I think we can keep the rule to preserve non-xmlns attribs, but it > would be great to get rid of the rule to preserve xmlns attribs. Absolutely. The latter rule may prevent the server implementation from using the NS prefixes it normally uses, for example after receiving ... If the server normally replies with , it would have to choose another prefix here. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Mon Jan 24 08:47:56 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3A33A6B06 for ; Mon, 24 Jan 2011 08:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMZEJKSyboJU for ; Mon, 24 Jan 2011 08:47:55 -0800 (PST) Received: from nm15-vm0.bullet.mail.ne1.yahoo.com (nm15-vm0.bullet.mail.ne1.yahoo.com [98.138.91.70]) by core3.amsl.com (Postfix) with SMTP id 85F1E3A6AE4 for ; Mon, 24 Jan 2011 08:47:55 -0800 (PST) Received: from [98.138.90.56] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 16:50:47 -0000 Received: from [98.138.89.254] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 16:50:47 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 24 Jan 2011 16:50:47 -0000 X-Yahoo-Newman-Id: 823811.35353.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 82080 invoked from network); 24 Jan 2011 16:50:47 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 24 Jan 2011 08:50:43 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .tKW_k8VM1k_JchQUrlY.KhqZAeJKGcC0ekM6Tt_YSjvIRf VyqT_29Yc X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3DAE0E.9000601@andybierman.com> Date: Mon, 24 Jan 2011 08:51:26 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> <1295884463.4317.43.camel@behold> In-Reply-To: <1295884463.4317.43.camel@behold> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 16:47:56 -0000 On 01/24/2011 07:54 AM, Ladislav Lhotka wrote: > On Pá, 2011-01-21 at 22:14 +0100, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: >>> ... >>>>> I still think that the rule that xmlns attribs are copied verbatim is >>>>> unfortunate. >>>> >>>> +1 (and one could also use more expressive words). >>>> >>> >>> I was opposed to changing this in the past, >>> but now I think I got it wrong. The dynamic nature of xmlns >>> attributes >>> is built into XML, and NETCONF steps on XML by mandating that the >>> xmlns to prefix mappings must be maintained from request to reply. >>> >>> Reality is that implementations will only go so far to support >>> preservation of these prefix mappings (i.e, from none to some to all). >>> This 'feature' was originally put in because Junos needed it. >> >> I think they wanted to preserve some attributes, but not necessarily >> xmlns attributes. Maybe the juniper people can reply to this, but I'm >> pretty sure they do not handle all variants of xmlns attributes in the >> input (e.g.). I'm also pretty sure >> that my implementation does not handle all corner cases either... >> >> I think we can keep the rule to preserve non-xmlns attribs, but it >> would be great to get rid of the rule to preserve xmlns attribs. > > Absolutely. The latter rule may prevent the server implementation from > using the NS prefixes it normally uses, for example after receiving > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="http://example.com/foo"> > ... > > > If the server normally replies with, it would have to > choose another prefix here. > That's the point -- server implementations are not going to bother. All the XML documents are independent of each other. The arbitrary set of mappings for 1 document does not need to be preserved. The actual problem with removing xmlns attributes is a corner-case few people probably care about: It is possible the client will send a qualified attribute or attribute content such as identityref or instance-identifier. The default attribute does not apply to attributes, so it is only an xmlns attribute with a prefix. This does not have the intended affect: In this case, 'myattribute' is still unqualified, and there is no namespace given for the 'identityref' content. > Lada > > >> >> >> /martin > Andy From lhotka@cesnet.cz Mon Jan 24 09:13:51 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD183A6906 for ; Mon, 24 Jan 2011 09:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPIV0oC6JwNp for ; Mon, 24 Jan 2011 09:13:50 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B57CF3A687C for ; Mon, 24 Jan 2011 09:13:49 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id D506F2CDE05B; Mon, 24 Jan 2011 18:16:42 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4D3DAE0E.9000601@andybierman.com> References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> <1295884463.4317.43.camel@behold> <4D3DAE0E.9000601@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 24 Jan 2011 18:16:47 +0100 Message-ID: <1295889407.4317.83.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:13:51 -0000 On Po, 2011-01-24 at 08:51 -0800, Andy Bierman wrote: > On 01/24/2011 07:54 AM, Ladislav Lhotka wrote: > > On Pá, 2011-01-21 at 22:14 +0100, Martin Bjorklund wrote: > >> Andy Bierman wrote: > >>> On 01/21/2011 07:13 AM, Ladislav Lhotka wrote: > >>> ... > >>>>> I still think that the rule that xmlns attribs are copied verbatim is > >>>>> unfortunate. > >>>> > >>>> +1 (and one could also use more expressive words). > >>>> > >>> > >>> I was opposed to changing this in the past, > >>> but now I think I got it wrong. The dynamic nature of xmlns > >>> attributes > >>> is built into XML, and NETCONF steps on XML by mandating that the > >>> xmlns to prefix mappings must be maintained from request to reply. > >>> > >>> Reality is that implementations will only go so far to support > >>> preservation of these prefix mappings (i.e, from none to some to all). > >>> This 'feature' was originally put in because Junos needed it. > >> > >> I think they wanted to preserve some attributes, but not necessarily > >> xmlns attributes. Maybe the juniper people can reply to this, but I'm > >> pretty sure they do not handle all variants of xmlns attributes in the > >> input (e.g.). I'm also pretty sure > >> that my implementation does not handle all corner cases either... > >> > >> I think we can keep the rule to preserve non-xmlns attribs, but it > >> would be great to get rid of the rule to preserve xmlns attribs. > > > > Absolutely. The latter rule may prevent the server implementation from > > using the NS prefixes it normally uses, for example after receiving > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:nc="http://example.com/foo"> > > ... > > > > > > If the server normally replies with, it would have to > > choose another prefix here. > > > > That's the point -- server implementations are not going to bother. > All the XML documents are independent of each other. The arbitrary > set of mappings for 1 document does not need to be preserved. > > The actual problem with removing xmlns attributes is a corner-case > few people probably care about: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="http://example.com/foo" nc:myattribute="nc:identityref"> > > It is possible the client will send a qualified attribute > or attribute content such as identityref or instance-identifier. > The default attribute does not apply to attributes, so it is only > an xmlns attribute with a prefix. I'm not sure I understand what you mean. The "nc:myidentifier" attribute belongs to the NS with URI "http://example.com/foo", and the fact that its value is a QName is outside the scope of XML namespaces spec. > > This does not have the intended affect: > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="http://example.com/foo" myattribute="identityref"> > > In this case, 'myattribute' is still unqualified, and there is no > namespace given for the 'identityref' content. I think the latter is application-specific, XML namespace declaration by itself only applies to element and attribute names, not contents or values. Lada > > > > Lada > > > > > >> > >> > >> /martin > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Mon Jan 24 09:44:47 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DC33A68F9 for ; Mon, 24 Jan 2011 09:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syDP7beqGKeR for ; Mon, 24 Jan 2011 09:44:46 -0800 (PST) Received: from nm26.bullet.mail.ac4.yahoo.com (nm26.bullet.mail.ac4.yahoo.com [98.139.52.223]) by core3.amsl.com (Postfix) with SMTP id 8ACF43A68F8 for ; Mon, 24 Jan 2011 09:44:46 -0800 (PST) Received: from [98.139.52.195] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 24 Jan 2011 17:47:39 -0000 Received: from [98.139.52.131] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 24 Jan 2011 17:47:39 -0000 Received: from [127.0.0.1] by omp1014.mail.ac4.yahoo.com with NNFMP; 24 Jan 2011 17:47:39 -0000 X-Yahoo-Newman-Id: 16834.95581.bm@omp1014.mail.ac4.yahoo.com Received: (qmail 97774 invoked from network); 24 Jan 2011 17:47:38 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.re3.yahoo.com with SMTP; 24 Jan 2011 09:47:35 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: JXc1jL0VM1kHGzGH.ZZbqhIkKJ1R7FwwyXEuqeiUT9aXnKz Jw3oh.yfAO8F4uqpdYk7IQh51F7abrZhQbL_yI9LkItnIiKM6hrZuem34xMl jsCdAzT1LSxJQ.VwLn4NbJul37OMOeIZXuSs2wuV70I0gDFeQYGJesKW8pNw K_8X0xkdnF1Ipbu9_MKuEpeGNgSAvCGsmBk5Wt37iUWnJTzj6e6UXxZAZVpp jFbJszB6TxmayBIM3YvdkaTmYP64Aw_q6CoAwp34JupmtKS6bqE3Oes5.VuE vSZE7eFUhbmTvWEo3uBxf X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3DBB62.5080801@andybierman.com> Date: Mon, 24 Jan 2011 09:48:18 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <20110121.160154.151450421.mbj@tail-f.com> <1295622805.1647.84.camel@behold> <4D39ED35.6080105@andybierman.com> <20110121.221403.250794340.mbj@tail-f.com> <1295884463.4317.43.camel@behold> <4D3DAE0E.9000601@andybierman.com> <1295889407.4317.83.camel@behold> In-Reply-To: <1295889407.4317.83.camel@behold> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] namespace passing X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:44:47 -0000 On 01/24/2011 09:16 AM, Ladislav Lhotka wrote: >.... >> The actual problem with removing xmlns attributes is a corner-case >> few people probably care about: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns:nc="http://example.com/foo" nc:myattribute="nc:identityref"> >> >> It is possible the client will send a qualified attribute >> or attribute content such as identityref or instance-identifier. >> The default attribute does not apply to attributes, so it is only >> an xmlns attribute with a prefix. > > I'm not sure I understand what you mean. The "nc:myidentifier" attribute > belongs to the NS with URI "http://example.com/foo", and the fact that > its value is a QName is outside the scope of XML namespaces spec. > OK -- but supporting identityref and i-i content requires namespace to prefix mapping. >> >> This does not have the intended affect: >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns="http://example.com/foo" myattribute="identityref"> >> >> In this case, 'myattribute' is still unqualified, and there is no >> namespace given for the 'identityref' content. > > I think the latter is application-specific, XML namespace declaration by > itself only applies to element and attribute names, not contents or > values. > The NETCONF peer has to do extra work and probably violate some internal layering to do it, in order to parse xpath, i-i, or identityref content. The prefix on the wire is XML, not YANG. In order to allow for the same identityref name with different bases, acme:foo and ietf:foo have to be treated as different identityrefs. > Lada > Andy From mehmet.ersue@nsn.com Thu Jan 27 03:15:22 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A608A3A68E8 for ; Thu, 27 Jan 2011 03:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.829 X-Spam-Level: X-Spam-Status: No, score=-104.829 tagged_above=-999 required=5 tests=[AWL=1.770, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B5paC0Ihh5o for ; Thu, 27 Jan 2011 03:15:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 834DB3A688E for ; Thu, 27 Jan 2011 03:15:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0RBIM6c031962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Jan 2011 12:18:22 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0RBILIV006888 for ; Thu, 27 Jan 2011 12:18:22 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 12:18:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: ACQa AN5L BG4q BrZs BzZg CnaT Dt8e D1cD D1up EToL Eg3D EzPu FpA4 HwU1 H6Gp IB6j; 1; bgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EF5712C1-1509-4CBC-BFBE-4D315BE74CB4}; bQBlAGgAbQBlAHQALgBlAHIAcwB1AGUAQABuAHMAbgAuAGMAbwBtAA==; Thu, 27 Jan 2011 11:18:10 GMT; RgBXADoAIABSAGUAcQB1AGUAcwB0ACAAdABvACAAYwBvAG4AcwBpAGQAZQByACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAG4AZQB0AGMAbwBuAGYALQA0ADcANAAyAGIAaQBzAC0AMAA2ACAAZgBvAHIAIABwAHUAYgBsAGkAYwBhAHQAaQBvAG4AIABhAHMAIABQAFMAIABSAEYAQwA= x-cr-puzzleid: {EF5712C1-1509-4CBC-BFBE-4D315BE74CB4} Content-class: urn:content-classes:message Date: Thu, 27 Jan 2011 12:18:10 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401880221@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to consider draft-ietf-netconf-4742bis-06 for publication as PS RFC thread-index: Acu+E3iZY+YM2kuXQ8qEXk/EVqhmqAAAAyDA From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 27 Jan 2011 11:18:13.0449 (UTC) FILETIME=[E321CB90:01CBBE13] Subject: [Netconf] FW: Request to consider draft-ietf-netconf-4742bis-06 for publication as PS RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 11:15:22 -0000 Hi All, since there were no additional comments, 4742bis is now back=20 in AD review. Cheers,=20 Mehmet=20 _____________________________________________ From: Ersue, Mehmet (NSN - DE/Munich)=20 Sent: Thursday, January 27, 2011 12:15 PM To: dromasca@avaya.com Cc: Bert (IETF) Wijnen Subject: Request to consider draft-ietf-netconf-4742bis-06 for publication as PS RFC Hi Dan,=20 thank you for giving us some more time to fix the issue=20 with the unsecure EOM. We think v06 of the 4742bis now solves the issue and has=20 near full WG consensus. The new document write-up contains=20 a detailed summary of the WG discussion. http://tools.ietf.org/html/draft-ietf-netconf-rfc4742bis-06=20 Please find below the updated document write-up. Mehmet Ersue Document shepherd ------------------------------------------------------------------------ --- (1.a) Who is the Document Shepherd for this document? Has the =20 Document Shepherd personally reviewed this version of the =20 document and, in particular, does he or she believe this =20 version is ready for forwarding to the IESG for publication?=20 =20 =20 I, Mehmet Ersue, am the Document Shepard for this document.=20 I have personally reviewed this version of the document and I=20 believe it is ready for publication.=20 =20 Adequate review has occurred from WG members, and it has been=20 reviewed especially by Bert Wijnen, Andy Bierman, Phil Shaefer, Martin Bjorklund, Lada Lothka, Wes Hardaker, Tom Petch, Ken=20 Watson, and Juergen Schoenwaelder. The issues raised in the=20 reviews have been discussed on the mailing list and fixed in=20 the last versions.=20 =20 =20 (1.b) Has the document had adequate review both from key WG members =20 and from key non-WG members? Does the Document Shepherd have =20 any concerns about the depth or breadth of the reviews that =20 have been performed? =20 =20 The document has had adequate review from working group and=20 non-working group members, mostly from NETCONF and NETMOD WGs. =20 I do not have any concerns about the depth or breadth of review. =20 =20 (1.c) Does the Document Shepherd have concerns that the document =20 needs more review from a particular or broader perspective, =20 e.g., security, operational complexity, someone familiar with =20 AAA, internationalization or XML?=20 =20 No.=20 =20 (1.d) Does the Document Shepherd have any specific concerns or =20 issues with this document that the Responsible Area Director =20 and/or the IESG should be aware of? For example, perhaps he =20 or she is uncomfortable with certain parts of the document, or =20 has concerns whether there really is a need for it. In any =20 event, if the WG has discussed those issues and has indicated =20 that it still wishes to advance the document, detail those =20 concerns here. Has an IPR disclosure related to this document =20 been filed? If so, please include a reference to the =20 disclosure and summarize the WG discussion and conclusion on =20 this issue. There are no concerns about the technical merit of the document.=20 There are no IPR disclosures filed on this document. =20 (1.e) How solid is the WG consensus behind this document? Does it =20 represent the strong concurrence of a few individuals, with =20 others being silent, or does the WG as a whole understand and =20 agree with it?=20 =20 There is strong consensus in the WG to publish this document. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme =20 discontent? If so, please summarise the areas of conflict in =20 separate email messages to the Responsible Area Director. (It =20 should be in a separate email because this questionnaire is =20 entered into the ID Tracker.)=20 =20 No.=20 =20 =20 (1.g) Has the Document Shepherd personally verified that the =20 document satisfies all ID nits? (See =20 http://www.ietf.org/ID-Checklist.html and =20 http://tools.ietf.org/tools/idnits/). Boilerplate checks are =20 not enough; this check needs to be thorough. Has the document =20 met all formal review criteria it needs to, such as the MIB =20 Doctor, media type and URI type reviews?=20 =20 Yes. There are no nits in this draft. =20 =20 (1.h) Has the document split its references into normative and =20 informative? Are there normative references to documents that =20 are not ready for advancement or are otherwise in an unclear =20 state? If such normative references exist, what is the =20 strategy for their completion? Are there normative references =20 that are downward references, as described in [RFC3967]? If =20 so, list these downward references to support the Area =20 Director in the Last Call procedure for them [RFC3967].=20 =20 The document has split references into normative and informative.=20 =20 =20 (1.i) Has the Document Shepherd verified that the document IANA =20 consideration section exists and is consistent with the body =20 of the document? If the document specifies protocol =20 extensions, are reservations requested in appropriate IANA =20 registries? Are the IANA registries clearly identified? If =20 the document creates a new registry, does it define the =20 proposed initial contents of the registry and an allocation =20 procedure for future registrations? Does it suggest a =20 reasonable name for the new registry? See [RFC5226]. If the =20 document describes an Expert Review process has Shepherd =20 conferred with the Responsible Area Director so that the IESG =20 can appoint the needed Expert during the IESG Evaluation?=20 =20 IANA considerations are present and complete. The draft=20 requests to update the allocations, which have been done=20 for RFC 4742. =20 (1.j) Has the Document Shepherd verified that sections of the =20 document that are written in a formal language, such as XML =20 code, BNF rules, MIB definitions, etc., validate correctly in =20 an automated checker? The ABNF rules for the chunked framing mechanism are correct=20 and follow RFC5234.=20 =20 =20 (1.k) The IESG approval announcement includes a Document =20 Announcement Write-Up. Please provide such a Document =20 Announcement Write-Up? Recent examples can be found in the=20 "Action" announcements for approved documents. The approval =20 announcement contains the following sections: =20 =20 Technical Summary =20 This document describes a method for invoking and running=20 the NETCONF protocol within a Secure Shell (SSH) session=20 as an SSH subsystem. Working Group Summary =20 This document has been longly discussed in the Working Group, including=20 several WG Last Calls. The comments and reviews helped to improve the=20 document a lot and the current version reflects the consensus of the WG.=20 The document incorporates all accepted errata against RFC4742. After a=20 long debate the WG decided to have the way a NETCONF Server extracts=20 the SSH user name from the SSH layer as implementation-dependent. =20 There was a long discussion on the handling of the EOM character sequence.=20 As the workgroup had only a mandate for bug fixing the workgroup first=20 agreed to keep using the EOM sequence to avoid incompatibility with existing=20 implementations. After the discussion on this issue in IETF #79 a few WG=20 members proposed to figure out if a proper framing solution can be found=20 now, while being backwards compatible with the rfc4742.=20 The old EOM framing has been seen as not secure enough: - RFC4742 assumes that the EOM sequence, ]]>]]>, cannot appear in any=20 well-formed XML document, which turned out to be mistaken. =20 - The EOM sequence can cause operational problems and open space for=20 attacks if sent deliberately in RPC messages. NETCONF co-chairs agreed to consider a solution only if there is a real WG=20 consensus (i.e. near 100%) on such a change. First a possible solution has=20 been discussed in a small team, which included most of the implementers=20 for NETCONF-related tools and protocol code. The solution proposes to=20 encode all NETCONF messages with a chunked framing (similar but not equal=20 to HTTP chunked framing). The document still uses the EOM sequence for the=20 initial message to avoid incompatibility with existing implementations. =20 NETCONF co-chairs asked the AD to hold the documents for 4741bis and=20 4742bis for a short period of time and the result of the discussion in the small=20 team has been sent to the WG for consensus.=20 Some of the discussion points were: - The proposal makes it a little bit harder to do just an SSH-session and then do=20 cut-and-paste input. The implementers believe that the proposed solution for=20 proper/decent framing is acceptable and that most implementation can/will=20 provide a simple scripting front-end to allow for some form of cut-and-paste. - It came out that less experienced implementers find it as helpful to see the=20 "invisible LineFeed" in the examples. The WG concluded that '\n' is the most=20 common character for this purpose. One WG member though was against '\n'=20 and wanted to use '}', which has been noted. - One WG member didn't want to stick the usage of the Chunked Framing=20 Mechanism to capability "base:1.1" only and wanted rather to state ":base:1.1=20 or later". The WG concluded that we should stick to "base:1.1" and extend it=20 with a new version, which most likely will introduce other changes.=20 =20 The changes have been accepted by the WG with some additional discussion=20 and bug fixing. As the result of the WG discussion the WG co-chairs concluded=20 near FULL consensus on the proposed edits and started a WGLC. The WGLC=20 did raise only minor issues. After a short discussion in a small team including=20 the WG co-chairs, the editor of 4742bis Margaret Wasserman, editors of 4741bis=20 Martin Bjorklund, Andy Bierman and Juergen Schoenwaelder the document=20 shepherd sent the collected bug fixing and change requests to NETCONF ML=20 and announced it as the result of the WG last call.=20 =20 Document Quality=20 Since SSH is mandatory transport for NETCONF there are numerous implementations of RFC 4742. It is expected that existing implementations=20 will be updated based on the 4742bis document once it gets published as=20 proposed standard. Mehmet Ersue Document Shepherd From bertietf@bwijnen.net Mon Jan 31 00:30:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648A83A6B2D for ; Mon, 31 Jan 2011 00:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdLkeJ8oaMog for ; Mon, 31 Jan 2011 00:30:10 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 4D5DB3A6AE3 for ; Mon, 31 Jan 2011 00:30:09 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PjpCJ-0004tK-Va for netconf@ietf.org; Mon, 31 Jan 2011 09:33:21 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PjpCJ-0004vR-Dm for netconf@ietf.org; Mon, 31 Jan 2011 09:33:19 +0100 Message-ID: <4D4673CF.7090804@bwijnen.net> Date: Mon, 31 Jan 2011 09:33:19 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: multipart/mixed; boundary="------------000707050204070400060004" X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d19a65ed4e3ef9aa30c2ca2bed573827 Subject: [Netconf] Fwd: Gen-ART LC review of draft-ietf-netconf-4741bis-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 08:30:11 -0000 This is a multi-part message in MIME format. --------------000707050204070400060004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I don't think I saw these appear on the netconf list, that is why I am forwarding. I assume that Andy or Martin will check and prepare a response. I will check too, but probably won't have time to go to the details till tomorrow. Bert Document shepherd -------- Original Message -------- Subject: Gen-ART LC review of draft-ietf-netconf-4741bis-07.txt Resent-Date: Mon, 31 Jan 2011 01:59:30 +0100 Resent-From: brian.e.carpenter@gmail.com Date: Mon, 31 Jan 2011 13:59:12 +1300 From: Brian E Carpenter Organization: University of Auckland To: draft-ietf-netconf-4741bis.all@tools.ietf.org, General Area Review Team Please see attached review. --------------000707050204070400060004 Content-Type: text/plain; name="draft-ietf-netconf-4741bis-07-carpenter.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-netconf-4741bis-07-carpenter.txt" SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gRm9y IGJhY2tncm91bmQgb24NCkdlbi1BUlQsIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0K DQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBM YXN0IENhbGwgY29tbWVudHMNCnlvdSBtYXkgcmVjZWl2ZS4NCg0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbmV0Y29uZi00NzQxYmlzLTA3LnR4dA0KUmV2aWV3ZXI6IEJyaWFuIENhcnBlbnRl cg0KUmV2aWV3IERhdGU6IDIwMTEtMDEtMzENCklFVEYgTEMgRW5kIERhdGU6IDIwMTEtMDIt MDcNCklFU0cgVGVsZWNoYXQgZGF0ZTogDQoNClN1bW1hcnk6IEFsbW9zdCByZWFkeSAtIHJl dmlldyB1c2Ugb2Ygbm9ybWF0aXZlIHdvcmRzDQotLS0tLS0tLQ0KDQpDb21tZW50Og0KLS0t LS0tLS0NCg0KVGhpcyBpcyBhIDEyMSBwYWdlIGRvY3VtZW50IHdpdGggYSB2ZXJ5IGxhcmdl IGFtb3VudCBvZiBjb2RlIGluY2x1ZGVkLA0KaW5jbHVkaW5nIGNvZGUgZXhwbGljaXRseSBt YXJrZWQgYXMgYmVpbmcgbm9ybWF0aXZlIGNvbnRlbnQuIEkgaGF2ZQ0Kbm90IGNoZWNrZWQg dGhpcyBjb2RlIGluIGFueSB3YXkuDQoNCk1pbm9yIGlzc3Vlcw0KLS0tLS0tLS0tLS0tDQoN CkknbSBhIGxpdHRsZSBjb25mdXNlZCBieSBzb21lIG9mIHRoZSBub24tbm9ybWF0aXZlIHVz ZXMgb2YgbG93ZXIgY2FzZSAic2hvdWxkIi4NCkZvciBleGFtcGxlOg0KDQoiMS4zLiAgQ2Fw YWJpbGl0aWVzDQoNCiAgIEEgTkVUQ09ORiBjYXBhYmlsaXR5IGlzIGEgc2V0IG9mIGZ1bmN0 aW9uYWxpdHkgdGhhdCBzdXBwbGVtZW50cyB0aGUNCiAgIGJhc2UgTkVUQ09ORiBzcGVjaWZp Y2F0aW9uLiAgVGhlIGNhcGFiaWxpdHkgaXMgaWRlbnRpZmllZCBieSBhDQogICB1bmlmb3Jt IHJlc291cmNlIGlkZW50aWZpZXIgKFVSSSkuICBUaGVzZSBVUklzIHNob3VsZCBmb2xsb3cg dGhlDQogICBndWlkZWxpbmVzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDguDQouLi4NCiI4 LiAgQ2FwYWJpbGl0aWVzDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIGEgc2V0IG9mIGNh cGFiaWxpdGllcyB0aGF0IGEgY2xpZW50IG9yIGEgc2VydmVyDQogICBNQVkgaW1wbGVtZW50 LiINCg0KU28gaWYgdGhlIGNhcGFiYWxpdGllcyBhcmUgYSBmb3JtYWwgTUFZLCB3aGF0IGlz IHRoYXQgYXBwYXJlbnRseSBub24tbm9ybWF0aXZlDQoic2hvdWxkIiBzdXBwb3NlZCB0byBt ZWFuPyBJIHN1Z2dlc3QgdGhhdCB0aGUgc2VudGVuY2Ugd291bGQgYmUgbGVzcyBjb25mdXNp bmcNCmlmIGl0IHNhaWQ6DQoNCiJTZWN0aW9uIDggcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3Ig dGhlc2UgVVJJcy4iIA0KDQpBbm90aGVyIGV4YW1wbGU6DQoNCiJBcHBlbmRpeCBELiAgQ2Fw YWJpbGl0eSBUZW1wbGF0ZQ0KDQogICBUaGlzIG5vbi1ub3JtYXRpdmUgc2VjdGlvbiBkZWZp bmVzIGEgdGVtcGxhdGUgdGhhdCBzaG91bGQgYmUgdXNlZCB0bw0KICAgZGVmaW5lIHByb3Rv Y29sIGNhcGFiaWxpdGllcy4gIg0KDQpJZiBpdCdzIG5vbi1ub3JtYXRpdmUsIGhvdyBpcyB0 aGUgcmVhZGVyIHRvIGludGVycHJldCAic2hvdWxkIj8gRG9lc24ndA0KaXQgbWVhbiAiY291 bGQiIG9yICJtaWdodCI/DQoNClRoZXJlIGFyZSB0ZW5zIG9mIGluc3RhbmNlcyBvZiBsb3dl ciBjYXNlICJzaG91bGQiIGFuZCBJIHdvbmRlciBob3cgbWFueQ0Kb2YgdGhlbSBhcmUgY29u ZnVzaW5nIGluIHRoaXMgd2F5Lg0KDQpTaW1pbGFybHk6DQoNCiIyLjMuICBBdXRoZW50aWNh dGlvbg0KDQogICBORVRDT05GIGNvbm5lY3Rpb25zIG11c3QgYmUgYXV0aGVudGljYXRlZC4g ICINCg0KU3VyZWx5IHRoYXQgc2hvdWxkIGJlIG5vcm1hdGl2ZSBNVVNUPyBBbmQgdGhlcmUg YXJlIGxvdHMgb2Ygb3RoZXIgbG93ZXINCmNhc2UgIm11c3QiIGFuZCAibWF5Ii4gVGhlIGxh dHRlciBpcyBlc3BlY2lhbGx5IGNvbmZ1c2luZyBiZWNhdXNlIGluDQpleGFtcGxlcyBsaWtl IHRoaXM6DQoiNi40LjQuICBTZWxlY3QgQWxsIDxuYW1lPiBFbGVtZW50cyB3aXRoaW4gdGhl IDx1c2Vycz4gU3VidHJlZQ0KDQogICBUaGlzIGZpbHRlciBjb250YWlucyB0d28gY29udGFp bm1lbnQgbm9kZXMgKDx1c2Vycz4sIDx1c2VyPikgYW5kIG9uZQ0KICAgc2VsZWN0aW9uIG5v ZGUgKDxuYW1lPikuICBBbGwgaW5zdGFuY2VzIG9mIHRoZSA8bmFtZT4gZWxlbWVudCBpbiB0 aGUNCiAgIHNhbWUgc2libGluZyBzZXQgYXJlIHNlbGVjdGVkIGluIHRoZSBmaWx0ZXIgb3V0 cHV0LiAgVGhlIGNsaWVudCBtYXkNCiAgIG5lZWQgdG8ga25vdyB0aGF0IDxuYW1lPiBpcyB1 c2VkIGFzIGFuIGluc3RhbmNlIGlkZW50aWZpZXIuLi4iDQoNCnMvbWF5L21pZ2h0LyB3b3Vs ZCBiZSBhcHByb3ByaWF0ZSwgYnV0IGluDQoNCiJUaGUgZmlsdGVyIGVsZW1lbnQgbWF5IG9w dGlvbmFsbHkgY29udGFpbiBhICJ0eXBlIiBhdHRyaWJ1dGUuIg0KDQpzL21heSBvcHRpb25h bGx5L01BWS8gd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNClRoZSBjdXJyZW50IG1peCBvZiBS RkMgMjExOSB0ZXJtcywgYXBwYXJlbnRseSBub3JtYXRpdmUgbG93ZXIgY2FzZSB0ZXJtcywg YW5kIA0KYXBwYXJlbnRseSBub24tbm9ybWF0aXZlIHVzZSBvZiAibWF5IiBhbmQgInNob3Vs ZCIgc2VlbXMgbGlrZSBpdCBuZWVkcyBjbGVhbmluZyB1cCANCmNvbXBhcmVkIHRvIFJGQzQ3 NDEuDQoNCg0K --------------000707050204070400060004--