From mehmet.ersue@nsn.com Sun Oct 3 10:15:07 2010 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 27CBA3A6DEE for ; Sun, 3 Oct 2010 10:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Eo7-DarJtdKA for ; Sun, 3 Oct 2010 10:15:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0CD4E3A6DE8 for ; Sun, 3 Oct 2010 10:15:04 -0700 (PDT) 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 o93HFthU015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 3 Oct 2010 19:15:55 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o93HFt4F002088 for ; Sun, 3 Oct 2010 19:15:55 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 19:15:55 +0200 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: Sun, 3 Oct 2010 19:15:52 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> In-Reply-To: <4C9B3E60.5030000@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActbFSvYCBJBrtm7Thm8gWdvPWBPSAIAqwCQ References: <4C9B3E60.5030000@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 03 Oct 2010 17:15:55.0210 (UTC) FILETIME=[A36BA2A0:01CB631E] Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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, 03 Oct 2010 17:15:07 -0000 Dear NETCONF Members, I hope this mail motivates the Netconf community to=20 comment or raises at least some discussion on the=20 content of 4741bis.=20 As you know 4741bis is the base protocol document=20 for NETCONF. Please comment on the 4741bis draft. It would be actually sufficient to say: "I read it=20 and it is ready to ship." [Co-chair hat off] I had read the document but read again.=20 I couldn't find any serious issues and I think it is=20 ready for publication though I have a few suggestions to make it more consistent and to improve the clarity=20 as a standard-track document. Section 1.1. Terminology I would suggest to bring the terms client/manager/ application vs. agent/server/device as early as=20 possible into relation. The document mainly avoids=20 the usage of the terms manager and agent though=20 there are some leftovers. OLD:=20 client: A client invokes protocol operations on a server. NEW:=20 client: A client (manager, application) invokes=20 protocol operations on a server (agent, device). OLD:=20 server: A server executes protocol operations invoked by a client. NEW:=20 server: A server (agent, device) executes protocol=20 operations invoked by a client (manager, application). Section 1.2. Protocol Overview To get it consistent with the rest of the document it would=20 be good to use only singular for layer titles. s/Operations/Operation/ s/Messages/Message/ s/Secure Transports/Secure Transport/ s/The Messages layer/The Message layer/ s/The Operations layer/The Operation layer/ Section 1.4. Separation of Configuration and State Data OLD: For example, if a local database of user authentication data is stored on the device, it is an implementation-dependent matter whether it is included in configuration data. NEW: For example, if a local database of user authentication data is stored on the device, it is implementation-dependent, whether=20 it is included in configuration data. Section 3. XML Considerations Concerning the mail-thread on "how to handle XML parse=20 errors" I agree with the last proposed text. OLD: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. NEW: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. =20 If a server receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. A few sentences on this issue should be added to=20 the security considerations section (see below). Section 3.2. No Document Type Declarations The title sounds like a command. Change to "Document Type Declarations". Section 4.3. Element s/layer: Messages/layer: Message/ s/layer: Operations/layer: Operation/ Section 5.2. Data Modeling "Devices and managers may support multiple data models, ..." s/managers/applications/ Section 7.5. To differentiate from Partial Lock RFC clearly, I would=20 underline that the operation is on the entire configuration=20 datastore. OLD:=20 The lock operation allows the client to lock the configuration system of a device. NEW: The lock operation allows the client to lock an entire configuration datastore of a server. I also would suggest to keep using the term "configuration=20 datastore" instead of "configuration", which is used in other=20 parts of the document to mean a specific part of the=20 configuration of a datastore. E.g. "An attempt to lock the configuration datastore MUST..." "The target configuration datastore is ,..." "The target parameter names the configuration datastore that will be locked." Sec. 1.1. says:=20 "session: Client and server exchange messages using a secure,=20 connection-oriented session." Sec. 2.1. Connection-Oriented Operation says:=20 "For example, when a lock is acquired by a client, the lock=20 persists until either it is explicitly released or the server=20 determines that the connection has been terminated." Sec. 2.3. Authentication says:=20 "The access permissions of a given client, identified by its=20 NETCONF username, are part of the configuration of the NETCONF=20 server. These permissions MUST be enforced during the remainder=20 of the NETCONF session." Sec. 7.5 says: "The operation can be used to force the=20 release of a lock owned by another NETCONF session." How a client can release a lock which is owned by another=20 session needs to be elaborated. E.g. Partial Lock RFC says:=20 "If needed, the returned session-id may be used to the NETCONF session holding the lock." I actually would suggest to delete this sentence in section 7.5.=20 and stick to the statement in section 2.1.=20 Section 7.7. "filter: This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is not present, all the device configuration and state information is returned." For the sake of completeness I would add what happens=20 if the filter parameter is available but empty. Section 8.4.1. Description s/configuration, /configuration. / Section 8.4.1. Description and 8.6.1. Description OLD: The current version is 1.1, and is defined in this document. It extends... NEW: The version 1.1 is defined in this document and extends... Section 12.2. Informative References Add draft-ietf-netmod-yang-usage-11 as informative reference. Section 9. Security Considerations I would suggest to add a few sentences for the EOM handling=20 and the possible thread concerning section 3. It would be=20 interesting to recommend a possible reaction if this happens=20 frequently, e.g. to drop the NETCONF session. Appendix B. XML Schema for NETCONF Messages Layer s/XML Schema for NETCONF Messages Layer/ XML Schema for NETCONF Message Layer/ Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert (IETF) Wijnen > Sent: Thursday, September 23, 2010 1:48 PM > To: Netconf > Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt >=20 >=20 > It was pointed out to me that we did not get ANY comments to this > WGLC. > Well, there was continued discussion on XML parse errors (which is > related partly to this document) on which we will come back tomorrow. >=20 > But no other comments, Also not any " I read it, go ahead to the next > step". >=20 > Can the WG chairs assume that people have indeed read the latest > version > of this document and are OK with it? >=20 > Can you please ASAP tell us: I read the doc and I am fine with it!!! >=20 > PLEASE >=20 > Bert and Mehmet >=20 > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > WG participants, this email starts a formal WG Last Call for revision > 4 > > of the 4741bis document. The document is targeted as Proposed > Standard > > to replace the current rfc4741. > > > > Please do review and tell us your position and comments. > > Please do so BEFORE 20 September 2010. > > > > Bert and Mehmet > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Monday, August 23, 2010 7:00 PM > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > 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-04.txt > > Pages : 121 > > Date : 2010-08-23 > > > > 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-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Sun Oct 3 10:24:35 2010 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 449FD3A6C77 for ; Sun, 3 Oct 2010 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.968 X-Spam-Level: X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MNc+wZyc19bZ for ; Sun, 3 Oct 2010 10:24:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DED913A6C5A for ; Sun, 3 Oct 2010 10:24:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BECAC004A; Sun, 3 Oct 2010 19:25:26 +0200 (CEST) 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 AHtLPe3s9U5A; Sun, 3 Oct 2010 19:25:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB6F0C000D; Sun, 3 Oct 2010 19:25:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BBBC150382A; Sun, 3 Oct 2010 19:24:55 +0200 (CEST) Date: Sun, 3 Oct 2010 19:24:55 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101003172455.GA16616@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Sun, 03 Oct 2010 17:24:35 -0000 On Sun, Oct 03, 2010 at 07:15:52PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Section 1.1. Terminology > > I would suggest to bring the terms client/manager/ > application vs. agent/server/device as early as > possible into relation. The document mainly avoids > the usage of the terms manager and agent though > there are some leftovers. > > OLD: > client: A client invokes protocol operations on a server. > NEW: > client: A client (manager, application) invokes > protocol operations on a server (agent, device). > > OLD: > server: A server executes protocol operations invoked by a client. > NEW: > server: A server (agent, device) executes protocol > operations invoked by a client (manager, application). I am against this change. The terminology is client and server; if there are any leftovers of other terms, we should remove them. There is a huge difference between a device and a NETCONF server, same for an application and a NETCONF client. > Section 9. Security Considerations > > I would suggest to add a few sentences for the EOM handling > and the possible thread concerning section 3. It would be > interesting to recommend a possible reaction if this happens > frequently, e.g. to drop the NETCONF session. 4741bis does not have an EOM marker - so how can we discuss it in the security considerations? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Sun Oct 3 10:52:19 2010 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 544483A6DF8 for ; Sun, 3 Oct 2010 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.136, 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 KlNDnCP1wQVG for ; Sun, 3 Oct 2010 10:52:17 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id EA0563A6D80 for ; Sun, 3 Oct 2010 10:52:17 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o93HoxoW032748; Sun, 3 Oct 2010 10:53:11 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id rp0xagy4b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 03 Oct 2010 10:53:10 -0700 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; Sun, 3 Oct 2010 10:57:09 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sun, 3 Oct 2010 10:53:10 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" Date: Sun, 3 Oct 2010 10:53:08 -0700 Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActjH/vGqS0s6DivQVixsu9Yy6MyQgAA4YZg Message-ID: References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> In-Reply-To: <20101003172455.GA16616@elstar.local> 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.0.10011, 1.0.148, 0.0.0000 definitions=2010-10-03_05:2010-10-03, 2010-10-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010030113 Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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, 03 Oct 2010 17:52:19 -0000 Hi, I agree with Juergen that we should stick with client/server terminology. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Sunday, October 03, 2010 10:25 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf= -netconf-4741bis-04.txt On Sun, Oct 03, 2010 at 07:15:52PM +0200, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Section 1.1. Terminology >=20 > I would suggest to bring the terms client/manager/ > application vs. agent/server/device as early as=20 > possible into relation. The document mainly avoids=20 > the usage of the terms manager and agent though=20 > there are some leftovers. >=20 > OLD:=20 > client: A client invokes protocol operations on a server. > NEW:=20 > client: A client (manager, application) invokes=20 > protocol operations on a server (agent, device). >=20 > OLD:=20 > server: A server executes protocol operations invoked by a client. > NEW:=20 > server: A server (agent, device) executes protocol=20 > operations invoked by a client (manager, application). I am against this change. The terminology is client and server; if there are any leftovers of other terms, we should remove them. There is a huge difference between a device and a NETCONF server, same for an application and a NETCONF client. =20 > Section 9. Security Considerations >=20 > I would suggest to add a few sentences for the EOM handling=20 > and the possible thread concerning section 3. It would be=20 > interesting to recommend a possible reaction if this happens=20 > frequently, e.g. to drop the NETCONF session. 4741bis does not have an EOM marker - so how can we discuss it in the security considerations? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Sun Oct 3 12:32:27 2010 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 3C1F23A6D5B for ; Sun, 3 Oct 2010 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 FcTLmGg9dLXL for ; Sun, 3 Oct 2010 12:32:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 7C4043A6C4E for ; Sun, 3 Oct 2010 12:32:25 -0700 (PDT) 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 o93JX8rn025433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Oct 2010 21:33:08 +0200 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 o93JX7uh028095; Sun, 3 Oct 2010 21:33:08 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 21:33:07 +0200 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: Sun, 3 Oct 2010 21:33:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640106533A@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActjH/vGqS0s6DivQVixsu9Yy6MyQgAA4YZgAANuyPA= References: <4C9B3E60.5030000@bwijnen.net><80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 03 Oct 2010 19:33:07.0121 (UTC) FILETIME=[CE059210:01CB6331] Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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, 03 Oct 2010 19:32:27 -0000 > I agree with Juergen that we should stick with client/server > terminology. This is also what I want. As this is the Terminology section the description of client (server) could also contain the=20 relation to other terms. =20 > Andy Mehmet >=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Sunday, October 03, 2010 10:25 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Netconf > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt >=20 > On Sun, Oct 03, 2010 at 07:15:52PM +0200, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > Section 1.1. Terminology > > > > I would suggest to bring the terms client/manager/ > > application vs. agent/server/device as early as > > possible into relation. The document mainly avoids > > the usage of the terms manager and agent though > > there are some leftovers. > > > > OLD: > > client: A client invokes protocol operations on a server. > > NEW: > > client: A client (manager, application) invokes > > protocol operations on a server (agent, device). > > > > OLD: > > server: A server executes protocol operations invoked by a client. > > NEW: > > server: A server (agent, device) executes protocol > > operations invoked by a client (manager, application). >=20 > I am against this change. The terminology is client and server; if > there are any leftovers of other terms, we should remove them. There > is a huge difference between a device and a NETCONF server, same for > an application and a NETCONF client. >=20 > > Section 9. Security Considerations > > > > I would suggest to add a few sentences for the EOM handling > > and the possible thread concerning section 3. It would be > > interesting to recommend a possible reaction if this happens > > frequently, e.g. to drop the NETCONF session. >=20 > 4741bis does not have an EOM marker - so how can we discuss it in > the security considerations? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Sun Oct 3 12:41:34 2010 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 A06C93A6D5B for ; Sun, 3 Oct 2010 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 JB9QEOCiU5E0 for ; Sun, 3 Oct 2010 12:41:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 90AEC3A6D16 for ; Sun, 3 Oct 2010 12:41:33 -0700 (PDT) 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 o93JgQv0032465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Oct 2010 21:42:26 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o93JgQuS011778; Sun, 3 Oct 2010 21:42:26 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 21:42:26 +0200 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: Sun, 3 Oct 2010 21:42:25 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101003172455.GA16616@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActjH/nHM3Oc0h83TPOAvD3IcmDP7gAEdprA References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 03 Oct 2010 19:42:26.0166 (UTC) FILETIME=[1B3D1160:01CB6333] Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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, 03 Oct 2010 19:41:34 -0000 > > Section 9. Security Considerations > > > > I would suggest to add a few sentences for the EOM handling > > and the possible thread concerning section 3. It would be > > interesting to recommend a possible reaction if this happens > > frequently, e.g. to drop the NETCONF session. >=20 > 4741bis does not have an EOM marker - so how can we discuss it in > the security considerations? EOM handling is for sure not part of NETCONF but the possible=20 thread concerning EOM handling is. I think security considerations=20 section should discuss the related security thread, as we did on=20 NETCONF ML with a long mail thread. Cheers, Mehmet From j.schoenwaelder@jacobs-university.de Sun Oct 3 13:55:20 2010 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 F180A3A6E89 for ; Sun, 3 Oct 2010 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YHrEY9iq+gVr for ; Sun, 3 Oct 2010 13:55:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE8653A6DB0 for ; Sun, 3 Oct 2010 13:55:18 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C81EC0004; Sun, 3 Oct 2010 22:56:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dTjkX2bFIIDH; Sun, 3 Oct 2010 22:56:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62980C0002; Sun, 3 Oct 2010 22:56:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F4EF1503A83; Sun, 3 Oct 2010 22:55:41 +0200 (CEST) Date: Sun, 3 Oct 2010 22:55:40 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101003205540.GA16936@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Sun, 03 Oct 2010 20:55:20 -0000 On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Section 9. Security Considerations > > > > > > I would suggest to add a few sentences for the EOM handling > > > and the possible thread concerning section 3. It would be > > > interesting to recommend a possible reaction if this happens > > > frequently, e.g. to drop the NETCONF session. > > > > 4741bis does not have an EOM marker - so how can we discuss it in > > the security considerations? > > EOM handling is for sure not part of NETCONF but the possible > thread concerning EOM handling is. I think security considerations > section should discuss the related security thread, as we did on > NETCONF ML with a long mail thread. There is no EOM issue if you run NETCONF over BEEP. We should stick to modularity and discuss things where they belong. Perhaps you want different text than the one I currently image you want... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Oct 6 02:50:15 2010 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 795293A6C84 for ; Wed, 6 Oct 2010 02:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 yP2J6HM5bO20 for ; Wed, 6 Oct 2010 02:50:13 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id 97C623A6E45 for ; Wed, 6 Oct 2010 02:50:10 -0700 (PDT) Received: from localhost (nomad.w2lan.cesnet.cz [195.113.228.50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 6BA9C3E01F5; Wed, 6 Oct 2010 11:42:04 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Ersue\, Mehmet \(NSN - DE\/Munich\)" In-Reply-To: <20101003205540.GA16936@elstar.local> References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Wed, 06 Oct 2010 11:42:03 +0200 Message-ID: <87y6abodxw.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 09:50:15 -0000 On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder wrote: > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > Section 9. Security Considerations > > > > > > > > I would suggest to add a few sentences for the EOM handling > > > > and the possible thread concerning section 3. It would be > > > > interesting to recommend a possible reaction if this happens > > > > frequently, e.g. to drop the NETCONF session. > > > > > > 4741bis does not have an EOM marker - so how can we discuss it in > > > the security considerations? > > > > EOM handling is for sure not part of NETCONF but the possible > > thread concerning EOM handling is. I think security considerations > > section should discuss the related security thread, as we did on > > NETCONF ML with a long mail thread. > > There is no EOM issue if you run NETCONF over BEEP. We should stick to > modularity and discuss things where they belong. Perhaps you want > different text than the one I currently image you want... SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the Messages, Operation or Content layer necessarily has an impact on operation and is a potential security hole. So I agree with Mehmet that 4741bis should not dismiss this issue completely. The protocol modularity has been damaged by the unfortunate EOM choice. Apart from Security Considerations, text in Sec. 3 should be changed as follows: OLD All NETCONF messages MUST be well-formed XML, encoded in UTF-8. NEW All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and MUST NOT contain the character sequence ']]>]]>'. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Oct 6 03:35:06 2010 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 145343A6F11 for ; Wed, 6 Oct 2010 03:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 sZZnB8PF73kA for ; Wed, 6 Oct 2010 03:35:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 046A33A7021 for ; Wed, 6 Oct 2010 03:35:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43497C0049; Wed, 6 Oct 2010 12:36:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bZcl09xgjGC6; Wed, 6 Oct 2010 12:36:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20608C0043; Wed, 6 Oct 2010 12:36:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 98FB61511945; Wed, 6 Oct 2010 12:35:33 +0200 (CEST) Date: Wed, 6 Oct 2010 12:35:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101006103533.GB52604@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y6abodxw.fsf@cesnet.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 10:35:06 -0000 On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote: > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder wrote: > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > > Section 9. Security Considerations > > > > > > > > > > I would suggest to add a few sentences for the EOM handling > > > > > and the possible thread concerning section 3. It would be > > > > > interesting to recommend a possible reaction if this happens > > > > > frequently, e.g. to drop the NETCONF session. > > > > > > > > 4741bis does not have an EOM marker - so how can we discuss it in > > > > the security considerations? > > > > > > EOM handling is for sure not part of NETCONF but the possible > > > thread concerning EOM handling is. I think security considerations > > > section should discuss the related security thread, as we did on > > > NETCONF ML with a long mail thread. > > > > There is no EOM issue if you run NETCONF over BEEP. We should stick to > > modularity and discuss things where they belong. Perhaps you want > > different text than the one I currently image you want... > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the > Messages, Operation or Content layer necessarily has an impact on > operation and is a potential security hole. So I agree with Mehmet that > 4741bis should not dismiss this issue completely. The protocol > modularity has been damaged by the unfortunate EOM choice. > > Apart from Security Considerations, text in Sec. 3 should be changed as > follows: > > OLD > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > NEW > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and > MUST NOT contain the character sequence ']]>]]>'. Still I believe it is the transport that has to deal with this. If a message contains ']]>]]>', a transport that can not handle this should either not accept to transport that message or have a mechanism to deal with it by quoting it or whatever. Pushing this issue up to the content layer just on the ground that the mandatory SSH transport is not totally robust seems odd from an architectural point of view. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Oct 6 04:03:54 2010 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 1C63D3A7115 for ; Wed, 6 Oct 2010 04:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 uPReAmX2hXlv for ; Wed, 6 Oct 2010 04:03:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D716C3A710C for ; Wed, 6 Oct 2010 04:03:52 -0700 (PDT) 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 o96B4p84016009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 13:04:51 +0200 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 o96B4oY4022170; Wed, 6 Oct 2010 13:04:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 13:04:30 +0200 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: Wed, 6 Oct 2010 13:04:29 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8A1D@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101006103533.GB52604@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlQkpbJMGUR/FETG2Vzqp3pDyHCgAAr2Kg References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Ladislav Lhotka" X-OriginalArrivalTime: 06 Oct 2010 11:04:30.0019 (UTC) FILETIME=[3FA69930:01CB6546] Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 11:03:54 -0000 > > Apart from Security Considerations, text in Sec. 3 should be changed > as > > follows: > > > > OLD > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > > > NEW > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and > > MUST NOT contain the character sequence ']]>]]>'. >=20 > Still I believe it is the transport that has to deal with this. If a > message contains ']]>]]>', a transport that can not handle this should > either not accept to transport that message or have a mechanism to > deal with it by quoting it or whatever. Pushing this issue up to the > content layer just on the ground that the mandatory SSH transport is > not totally robust seems odd from an architectural point of view. It is true that NETCONF does not have any awareness of EOM character sequence. NETCONF is aware of "well-formed XML" messages. The proposed=20 text by Martin defines what NETCONF should do (on its level) if the XML=20 message is not well-formed. : NEW: : All NETCONF messages MUST be well-formed XML, encoded in UTF-8. =20 : If a server receives a message that is not well-formed XML, it MUST : reply with an 'operation-failed' error. However, although EOM handling is not an issue on NETCONF level NETCONF=20 has a concrete security thread if XML messages are not well-formed=20 frequently. I proposed to discuss the security thread in the security considerations section. Mehmet From mbj@tail-f.com Wed Oct 6 04:36:35 2010 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 A9E433A6EF2 for ; Wed, 6 Oct 2010 04:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.284, 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 oWhemuf2Xk0n for ; Wed, 6 Oct 2010 04:36:34 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8F7FD3A6C75 for ; Wed, 6 Oct 2010 04:36:32 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3912061A30D; Wed, 6 Oct 2010 13:37:31 +0200 (CEST) Date: Wed, 06 Oct 2010 13:37:30 +0200 (CEST) Message-Id: <20101006.133730.41786057.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.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] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 11:36:35 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > [Co-chair hat off] > > I had read the document but read again. > I couldn't find any serious issues and I think it is > ready for publication though I have a few suggestions > to make it more consistent and to improve the clarity > as a standard-track document. > > > Section 1.1. Terminology > > I would suggest to bring the terms client/manager/ > application vs. agent/server/device as early as > possible into relation. The document mainly avoids > the usage of the terms manager and agent though > there are some leftovers. > > OLD: > client: A client invokes protocol operations on a server. > NEW: > client: A client (manager, application) invokes > protocol operations on a server (agent, device). > > OLD: > server: A server executes protocol operations invoked by a client. > NEW: > server: A server (agent, device) executes protocol > operations invoked by a client (manager, application). I agree with my co-editors that we should stick to the client/server terminology. There are a couple of places in the document where we should change the terminology from e.g. application to client. > Section 1.2. Protocol Overview > > To get it consistent with the rest of the document it would > be good to use only singular for layer titles. > > s/Operations/Operation/ > s/Messages/Message/ > s/Secure Transports/Secure Transport/ > s/The Messages layer/The Message layer/ > s/The Operations layer/The Operation layer/ I agree that singular makes more sense. I support this change. What do others think? > Section 1.4. Separation of Configuration and State Data > > OLD: > For example, if a local database of user authentication data is > stored on the device, it is an implementation-dependent matter > whether it is included in configuration data. > NEW: > For example, if a local database of user authentication data is > stored on the device, it is implementation-dependent, whether > it is included in configuration data. Why is the new text better? > Section 3. XML Considerations > > Concerning the mail-thread on "how to handle XML parse > errors" I agree with the last proposed text. > > OLD: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > NEW: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > If a server receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. The chairs must tell us what to do with this issue. > Section 3.2. No Document Type Declarations > > The title sounds like a command. > Change to "Document Type Declarations". Ok. > Section 4.3. Element > > s/layer: Messages/layer: Message/ > s/layer: Operations/layer: Operation/ See above. > Section 5.2. Data Modeling > > "Devices and managers may support multiple data models, ..." > > s/managers/applications/ I'd prefer "Clients and servers may support...". > Section 7.5. > > To differentiate from Partial Lock RFC clearly, I would > underline that the operation is on the entire configuration > datastore. > > OLD: > The lock operation allows the client to lock the configuration > system of a device. > NEW: > The lock operation allows the client to lock an entire configuration > datastore of a server. Ok. > I also would suggest to keep using the term "configuration > datastore" instead of "configuration", which is used in other > parts of the document to mean a specific part of the > configuration of a datastore. Ok. > E.g. > "An attempt to lock the configuration datastore MUST..." > "The target configuration datastore is ,..." > "The target parameter names the configuration datastore that will be > locked." > > Sec. 1.1. says: > "session: Client and server exchange messages using a secure, > connection-oriented session." > > Sec. 2.1. Connection-Oriented Operation says: > "For example, when a lock is acquired by a client, the lock > persists until either it is explicitly released or the server > determines that the connection has been terminated." > > Sec. 2.3. Authentication says: > "The access permissions of a given client, identified by its > NETCONF username, are part of the configuration of the NETCONF > server. These permissions MUST be enforced during the remainder > of the NETCONF session." > > Sec. 7.5 says: > "The operation can be used to force the > release of a lock owned by another NETCONF session." > > How a client can release a lock which is owned by another > session needs to be elaborated. E.g. Partial Lock RFC says: > "If needed, the returned session-id may be used to the > NETCONF session holding the lock." > > I actually would suggest to delete this sentence in section 7.5. > and stick to the statement in section 2.1. I think the text in 7.5 gives useful information. I am not sure why you think it needs to be removed. > Section 7.7. > > "filter: > This parameter specifies the portion of the system > configuration and state data to retrieve. If this parameter is > not present, all the device configuration and state information > is returned." > > For the sake of completeness I would add what happens > if the filter parameter is available but empty. If the filter parameter is present, the 'type' attribute specifies if it is a subtree filter or xpath filter. If no 'type' attribute is present, it defaults to subtree filtering. Section 6 describes this algorithm, and specificially 6.4.2 specifies how an empty subtree filter works. I don't think we should say anything about special filter values in 7.7. > Section 8.4.1. Description > > s/configuration, /configuration. / OK. > Section 8.4.1. Description and 8.6.1. Description > > OLD: > The current version is 1.1, and is defined in this document. It > extends... > NEW: > The version 1.1 is defined in this document and extends... Ok, I did: Version 1.1. is defined in this document and extends... > Section 12.2. Informative References > > Add draft-ietf-netmod-yang-usage-11 as informative reference. Why? That document is intended for YANG module writers. > Section 9. Security Considerations > > I would suggest to add a few sentences for the EOM handling > and the possible thread concerning section 3. It would be > interesting to recommend a possible reaction if this happens > frequently, e.g. to drop the NETCONF session. I'll await the current ML discussion... > Appendix B. XML Schema for NETCONF Messages Layer > > s/XML Schema for NETCONF Messages Layer/ > XML Schema for NETCONF Message Layer/ See above. /martin From mehmet.ersue@nsn.com Wed Oct 6 05:23:31 2010 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 D26863A6EE6 for ; Wed, 6 Oct 2010 05:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, 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 YN5Y-2NKGveE for ; Wed, 6 Oct 2010 05:23:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8E8B03A6EBC for ; Wed, 6 Oct 2010 05:23:30 -0700 (PDT) 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 o96CORVM018759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 14:24:27 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96COPW0020718; Wed, 6 Oct 2010 14:24:27 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 14:24:26 +0200 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: Wed, 6 Oct 2010 14:24:23 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101006.133730.41786057.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlSt/oZ7ylvL5ARfe01eAIj47TPwAAncFg References: <4C9B3E60.5030000@bwijnen.net><80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101006.133730.41786057.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" X-OriginalArrivalTime: 06 Oct 2010 12:24:26.0051 (UTC) FILETIME=[6A4F0130:01CB6551] Cc: netconf@ietf.org Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 12:23:31 -0000 Hi Martin, > > OLD: > > server: A server executes protocol operations invoked by a client. > > NEW: > > server: A server (agent, device) executes protocol > > operations invoked by a client (manager, application). >=20 > I agree with my co-editors that we should stick to the client/server > terminology. There are a couple of places in the document where we > should change the terminology from e.g. application to client. The text I proposed may be a bit misleading but this is=20 what I want too.=20 I just propose to bring the terms into relation as early=20 as possible in the terminology section. Then we can use=20 only client/server. =20 > > Section 1.4. Separation of Configuration and State Data > > > > OLD: > > For example, if a local database of user authentication data is > > stored on the device, it is an implementation-dependent matter > > whether it is included in configuration data. > > NEW: > > For example, if a local database of user authentication data is > > stored on the device, it is implementation-dependent, whether > > it is included in configuration data. >=20 > Why is the new text better? Clear and direct? Anyway, I can go with both. =20 > > Section 5.2. Data Modeling > > > > "Devices and managers may support multiple data models, ..." > > > > s/managers/applications/ >=20 > I'd prefer "Clients and servers may support...". Fine. =20 > > Sec. 7.5 says: > > "The operation can be used to force the > > release of a lock owned by another NETCONF session." > > > > How a client can release a lock which is owned by another > > session needs to be elaborated. E.g. Partial Lock RFC says: > > "If needed, the returned session-id may be used to the > > NETCONF session holding the lock." > > > > I actually would suggest to delete this sentence in section 7.5. > > and stick to the statement in section 2.1. >=20 > I think the text in 7.5 gives useful information. I am not sure why > you think it needs to be removed. I agree that the text in quotations marks above gives useful=20 information. However it is not self-explaining. The questions coming up are: How and whether a client is allowed to kill "any"=20 session.=20 =20 > > Section 7.7. > > > > "filter: > > This parameter specifies the portion of the system > > configuration and state data to retrieve. If this parameter is > > not present, all the device configuration and state information > > is returned." > > > > For the sake of completeness I would add what happens > > if the filter parameter is available but empty. >=20 > If the filter parameter is present, the 'type' attribute specifies if > it is a subtree filter or xpath filter. If no 'type' attribute is > present, it defaults to subtree filtering. Section 6 describes this > algorithm, and specificially 6.4.2 specifies how an empty subtree > filter works. I don't think we should say anything about special > filter values in 7.7. Agree. =20 > > Section 12.2. Informative References > > > > Add draft-ietf-netmod-yang-usage-11 as informative reference. >=20 > Why? That document is intended for YANG module writers. Appendix C includes a normative YANG module and IANA considerations=20 include namespace registration, etc., which follow the guidelines=20 in draft-ietf-netmod-yang-usage.=20 I think people who read the YANG module in 4741bis should be also pointed to the guidelines document. > /martin Mehmet/> From j.schoenwaelder@jacobs-university.de Wed Oct 6 05:50:41 2010 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 DC72D3A6E65 for ; Wed, 6 Oct 2010 05:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AlTs-E-rCNkm for ; Wed, 6 Oct 2010 05:50:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C6A433A6D93 for ; Wed, 6 Oct 2010 05:50:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F1C5C006B; Wed, 6 Oct 2010 14:51:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W9OanM5gjolz; Wed, 6 Oct 2010 14:51:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5FAFC0138; Wed, 6 Oct 2010 14:51:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A57BF1515096; Wed, 6 Oct 2010 14:51:10 +0200 (CEST) Date: Wed, 6 Oct 2010 14:51:10 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101006125110.GB53607@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , "netconf@ietf.org" References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101006.133730.41786057.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 12:50:41 -0000 On Wed, Oct 06, 2010 at 02:24:23PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Section 12.2. Informative References > > > > > > Add draft-ietf-netmod-yang-usage-11 as informative reference. > > > > Why? That document is intended for YANG module writers. > > Appendix C includes a normative YANG module and IANA considerations > include namespace registration, etc., which follow the guidelines > in draft-ietf-netmod-yang-usage. > I think people who read the YANG module in 4741bis should be also > pointed to the guidelines document. Why? The guidelines are for module writers / reviewers not module readers. You want to have them cited in each and every module we publish? We do not do this for MIB modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Oct 6 06:33:03 2010 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 ADFB43A6F5B for ; Wed, 6 Oct 2010 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 Babb2ldR3EdS for ; Wed, 6 Oct 2010 06:33:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 769353A6F4B for ; Wed, 6 Oct 2010 06:33:02 -0700 (PDT) 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 o96DY1HP012987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 15:34:01 +0200 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 o96DY02J007504; Wed, 6 Oct 2010 15:34:00 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 15:34:00 +0200 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: Wed, 6 Oct 2010 15:33:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8C4B@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101006125110.GB53607@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlVTvkzcBV1VwgRgCRAHsu7dZy2AABaqHw References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101006.133730.41786057.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net> <20101006125110.GB53607@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 06 Oct 2010 13:34:00.0515 (UTC) FILETIME=[227BA930:01CB655B] Cc: netconf@ietf.org Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 13:33:03 -0000 > On Wed, Oct 06, 2010 at 02:24:23PM +0200, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > > > Section 12.2. Informative References > > > > > > > > Add draft-ietf-netmod-yang-usage-11 as informative reference. > > > > > > Why? That document is intended for YANG module writers. > > > > Appendix C includes a normative YANG module and IANA considerations > > include namespace registration, etc., which follow the guidelines > > in draft-ietf-netmod-yang-usage. > > I think people who read the YANG module in 4741bis should be also > > pointed to the guidelines document. >=20 > Why? The guidelines are for module writers / reviewers not module > readers. You want to have them cited in each and every module we > publish? We do not do this for MIB modules. It is actually the same reason why we have the informative=20 reference on: [13] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. =20 > /js me/> From j.schoenwaelder@jacobs-university.de Wed Oct 6 06:43:01 2010 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 1F3C53A6F36 for ; Wed, 6 Oct 2010 06:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 XTBZ4yObhI-Q for ; Wed, 6 Oct 2010 06:42:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2EB63A6E6D for ; Wed, 6 Oct 2010 06:42:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DB07C0043; Wed, 6 Oct 2010 15:43:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x5wxrQmubgJ6; Wed, 6 Oct 2010 15:43:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EA75C000A; Wed, 6 Oct 2010 15:43:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8527D15153E0; Wed, 6 Oct 2010 15:43:29 +0200 (CEST) Date: Wed, 6 Oct 2010 15:43:29 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101006134329.GA54263@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , "netconf@ietf.org" References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101006.133730.41786057.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net> <20101006125110.GB53607@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64010A8C4B@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64010A8C4B@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 13:43:01 -0000 On Wed, Oct 06, 2010 at 03:33:59PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > On Wed, Oct 06, 2010 at 02:24:23PM +0200, Ersue, Mehmet (NSN - > > DE/Munich) wrote: > > > > > Section 12.2. Informative References > > > > > > > > > > Add draft-ietf-netmod-yang-usage-11 as informative reference. > > > > > > > > Why? That document is intended for YANG module writers. > > > > > > Appendix C includes a normative YANG module and IANA considerations > > > include namespace registration, etc., which follow the guidelines > > > in draft-ietf-netmod-yang-usage. > > > I think people who read the YANG module in 4741bis should be also > > > pointed to the guidelines document. > > > > Why? The guidelines are for module writers / reviewers not module > > readers. You want to have them cited in each and every module we > > publish? We do not do this for MIB modules. > > It is actually the same reason why we have the informative > reference on: > > [13] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the > Use of Extensible Markup Language (XML) within IETF Protocols", > BCP 70, RFC 3470, January 2003. Since the document in question defines a protocol that carries XML, having this reference may seem different from requiring a reference to the YANG guidelines how to write a YANG proper module in every YANG module. At least in the SMIv2 space, we managed to live without it. But then, if you feel strongly about this, lets just add it instead of debating this long. Lets hope the guidelines document gives the guideline that the guidelines document select-one-of(must|MUST|should|SHOULD) be cited. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Oct 6 06:50:41 2010 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 022F03A6F77 for ; Wed, 6 Oct 2010 06:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 U5LUHxpugoTf for ; Wed, 6 Oct 2010 06:50:39 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 004033A6E6D for ; Wed, 6 Oct 2010 06:50:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTKx+4890mmWAEiMJiBgyhdpHDc95G/U5@postini.com; Wed, 06 Oct 2010 06:51:40 PDT 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; Wed, 6 Oct 2010 06:50:42 -0700 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 o96DofU19115; Wed, 6 Oct 2010 06:50:41 -0700 (PDT) (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 o96DU1o1014393; Wed, 6 Oct 2010 13:30:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010061330.o96DU1o1014393@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20101006134329.GA54263@elstar.local> Date: Wed, 6 Oct 2010 09:30:01 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 13:50:41 -0000 Juergen Schoenwaelder writes: >Since the document in question defines a protocol that carries XML, >having this reference may seem different from requiring a reference to >the YANG guidelines how to write a YANG proper module in every YANG >module. At least in the SMIv2 space, we managed to live without it. Are we talking about putting a reference to yang-usage in the netconf-bis just to say that the new yang module follows those guidelines? Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Oct 6 06:54:20 2010 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 B8B7D3A6F9E for ; Wed, 6 Oct 2010 06:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MVs3nJbgXTjb for ; Wed, 6 Oct 2010 06:54:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4BB123A6F84 for ; Wed, 6 Oct 2010 06:54:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BCECC006B; Wed, 6 Oct 2010 15:55:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3wnm7NQlu+8J; Wed, 6 Oct 2010 15:55:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E9A3C000A; Wed, 6 Oct 2010 15:55:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5CDBA15154DC; Wed, 6 Oct 2010 15:54:49 +0200 (CEST) Date: Wed, 6 Oct 2010 15:54:48 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20101006135448.GC54263@elstar.local> Mail-Followup-To: Phil Shafer , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: <20101006134329.GA54263@elstar.local> <201010061330.o96DU1o1014393@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010061330.o96DU1o1014393@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 13:54:20 -0000 On Wed, Oct 06, 2010 at 03:30:01PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Since the document in question defines a protocol that carries XML, > >having this reference may seem different from requiring a reference to > >the YANG guidelines how to write a YANG proper module in every YANG > >module. At least in the SMIv2 space, we managed to live without it. > > Are we talking about putting a reference to yang-usage in the > netconf-bis just to say that the new yang module follows those > guidelines? That is my understanding. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Oct 6 07:16:03 2010 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 E0DC13A6F51 for ; Wed, 6 Oct 2010 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 xiD9MqEhwoOT for ; Wed, 6 Oct 2010 07:16:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8419C3A6B41 for ; Wed, 6 Oct 2010 07:16:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o96EH022019811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 16:17:00 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96EH0Sx031062; Wed, 6 Oct 2010 16:17:00 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 16:17:00 +0200 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: Wed, 6 Oct 2010 16:16:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8CB6@DEMUEXC006.nsn-intra.net> In-Reply-To: <201010061330.o96DU1o1014393@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlXZryj/Yju2PwSMeKeIdFlCSKDAAAzSDg References: <20101006134329.GA54263@elstar.local> <201010061330.o96DU1o1014393@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 06 Oct 2010 14:17:00.0344 (UTC) FILETIME=[242E5380:01CB6561] Cc: netconf@ietf.org Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 14:16:04 -0000 > From: ext Phil Shafer [mailto:phil@juniper.net] > Juergen Schoenwaelder writes: > >Since the document in question defines a protocol that carries XML, > >having this reference may seem different from requiring a reference to > >the YANG guidelines how to write a YANG proper module in every YANG > >module. At least in the SMIv2 space, we managed to live without it. >=20 > Are we talking about putting a reference to yang-usage in the > netconf-bis just to say that the new yang module follows those > guidelines? draft-ietf-netmod-yang-usage-11 has important guideline on=20 namespace registration, YANG module registration, etc., which=20 are used in 4741bis. Mehmet From ietf@andybierman.com Wed Oct 6 07:59:28 2010 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 DE79A3A6F7B for ; Wed, 6 Oct 2010 07:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152] 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 lsZTyit0JAgj for ; Wed, 6 Oct 2010 07:59:28 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by core3.amsl.com (Postfix) with ESMTP id D384F3A6C4C for ; Wed, 6 Oct 2010 07:59:27 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.149.5] (may be forged)) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o96F0Rlx011924 for ; Wed, 6 Oct 2010 11:00:27 -0400 Authentication-Results: cm-omr1 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.126.165.113] ([173.126.165.113:59577] helo=[173.126.165.113]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 25/00-11767-80F8CAC4; Wed, 06 Oct 2010 11:00:27 -0400 To: "=?utf-8?B?UGhpbCBTaGFmZXI=?=" , "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" Message-ID: <25.00.11767.80F8CAC4@cm-omr1> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 06 Oct 2010 08:00:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_1286377240331" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?We_NEED_RESPONSES=3A_WG_Last_Call_ended=09for?= =?utf-8?q?=3Adraft-ietf-netconf-4741bis-04=2Etxt?= 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, 06 Oct 2010 14:59:29 -0000 ------=_Part_2_1286377240331 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Tm8uCk5ldGNvbmYgdXNlcyBYTUwuICBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IFlBTkcg YmUgdXNlZCBhdCBhbGwuCkl0IGNlcnRhaW5seSBkb2VzIG5vdCBmYWN0b3IgaW50byBwcm90b2Nv bCBjb25mb3JtYW5jZS4KCkFuZHkKCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJQ aGlsIFNoYWZlciIgPHBoaWxAanVuaXBlci5uZXQ+CkRhdGU6IFdlZCwgT2N0IDYsIDIwMTAgMDY6 MzAKU3ViamVjdDogW05ldGNvbmZdIFdlIE5FRUQgUkVTUE9OU0VTOiBXRyBMYXN0IENhbGwgZW5k ZWQJZm9yOmRyYWZ0LWlldGYtbmV0Y29uZi00NzQxYmlzLTA0LnR4dApUbzogIkp1ZXJnZW4gU2No b2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4KQ2M6ICJu ZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4KCgpKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgd3JpdGVzOgo+U2luY2UgdGhlIGRvY3VtZW50IGluIHF1ZXN0aW9uIGRlZmluZXMgYSBwcm90 b2NvbCB0aGF0IGNhcnJpZXMgWE1MLAo+aGF2aW5nIHRoaXMgcmVmZXJlbmNlIG1heSBzZWVtIGRp ZmZlcmVudCBmcm9tIHJlcXVpcmluZyBhIHJlZmVyZW5jZSB0bwo+dGhlIFlBTkcgZ3VpZGVsaW5l cyBob3cgdG8gd3JpdGUgYSBZQU5HIHByb3BlciBtb2R1bGUgaW4gZXZlcnkgWUFORwo+bW9kdWxl LiBBdCBsZWFzdCBpbiB0aGUgU01JdjIgc3BhY2UsIHdlIG1hbmFnZWQgdG8gbGl2ZSB3aXRob3V0 IGl0LgoKQXJlIHdlIHRhbGtpbmcgYWJvdXQgcHV0dGluZyBhIHJlZmVyZW5jZSB0byB5YW5nLXVz YWdlIGluIHRoZQpuZXRjb25mLWJpcyBqdXN0IHRvIHNheSB0aGF0IHRoZSBuZXcgeWFuZyBtb2R1 bGUgZm9sbG93cyB0aG9zZQpndWlkZWxpbmVzPwoKVGhhbmtzLAogUGhpbApfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcgbGlzdApO ZXRjb25mQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZgoK ------=_Part_2_1286377240331 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Tm8uPGJyPk5ldGNvbmYgdXNlcyBYTUwuICZuYnNwO1RoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRo YXQgWUFORyBiZSB1c2VkIGF0IGFsbC48YnI+SXQgY2VydGFpbmx5IGRvZXMgbm90IGZhY3RvciBp bnRvIHByb3RvY29sIGNvbmZvcm1hbmNlLjxicj48YnI+QW5keTxicj48YnI+PGJyPi0tLS0tIFJl cGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7UGhpbCBTaGFmZXImcXVvdDsgJmx0O3Bo aWxAanVuaXBlci5uZXQmZ3Q7PGJyPkRhdGU6IFdlZCwgT2N0IDYsIDIwMTAgMDY6MzA8YnI+U3Vi amVjdDogW05ldGNvbmZdIFdlIE5FRUQgUkVTUE9OU0VTOiBXRyBMYXN0IENhbGwgZW5kZWQJZm9y OmRyYWZ0LWlldGYtbmV0Y29uZi00NzQxYmlzLTA0LnR4dDxicj5UbzogJnF1b3Q7SnVlcmdlbiBT Y2hvZW53YWVsZGVyJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGUmZ3Q7PGJyPkNjOiAmcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGll dGYub3JnJmd0Ozxicj48YnI+PGJyPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciB3cml0ZXM6PGJyPiZn dDtTaW5jZSB0aGUgZG9jdW1lbnQgaW4gcXVlc3Rpb24gZGVmaW5lcyBhIHByb3RvY29sIHRoYXQg Y2FycmllcyBYTUwsPGJyPiZndDtoYXZpbmcgdGhpcyByZWZlcmVuY2UgbWF5IHNlZW0gZGlmZmVy ZW50IGZyb20gcmVxdWlyaW5nIGEgcmVmZXJlbmNlIHRvPGJyPiZndDt0aGUgWUFORyBndWlkZWxp bmVzIGhvdyB0byB3cml0ZSBhIFlBTkcgcHJvcGVyIG1vZHVsZSBpbiBldmVyeSBZQU5HPGJyPiZn dDttb2R1bGUuIEF0IGxlYXN0IGluIHRoZSBTTUl2MiBzcGFjZSwgd2UgbWFuYWdlZCB0byBsaXZl IHdpdGhvdXQgaXQuPGJyPjxicj5BcmUgd2UgdGFsa2luZyBhYm91dCBwdXR0aW5nIGEgcmVmZXJl bmNlIHRvIHlhbmctdXNhZ2UgaW4gdGhlPGJyPm5ldGNvbmYtYmlzIGp1c3QgdG8gc2F5IHRoYXQg dGhlIG5ldyB5YW5nIG1vZHVsZSBmb2xsb3dzIHRob3NlPGJyPmd1aWRlbGluZXM/PGJyPjxicj5U aGFua3MsPGJyPiBQaGlsPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPk5ldGNvbmZAaWV0Zi5vcmc8YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPjxicj48 YnI+PGJyPg== ------=_Part_2_1286377240331-- From ietf@andybierman.com Wed Oct 6 08:08:10 2010 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 99B043A7115 for ; Wed, 6 Oct 2010 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152] 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 ays7nNaAz6sG for ; Wed, 6 Oct 2010 08:08:09 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by core3.amsl.com (Postfix) with ESMTP id E79E73A70CF for ; Wed, 6 Oct 2010 08:08:07 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.149.5] (may be forged)) by omr12.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o96F97A6031826 for ; Wed, 6 Oct 2010 11:09:07 -0400 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.126.165.113] ([173.126.165.113:34311] helo=[173.126.165.113]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 2B/91-03446-D019CAC4; Wed, 06 Oct 2010 11:09:07 -0400 To: "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" , mehmet.ersue@nsn.com Message-ID: <2B.91.03446.D019CAC4@cm-omr7> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 06 Oct 2010 08:09:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3_1286377757401" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?We_NEED_RESPONSES=3A_WG_Last_Call_ended_for?= =?utf-8?q?=3Adraft-ietf-netconf-4741bis-04=2Etxt?= 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, 06 Oct 2010 15:08:10 -0000 ------=_Part_3_1286377757401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayB0aGlzIFdHIG5lZWRzIHRvIG1ha2UgZGVjaXNpb25zIGFuZCBzdGljayB0byB0aGVt LgpDaGFuZ2luZyBlcnJvciBoYW5kbGluZyBmb3IgbWFsZm9ybWVkIFhNTCBpcyBub3QgYW4gZWRp dG9yaWFsIGNoYW5nZS4gICBUaGUgV0cgZGlkIG5vdCByZWFjaCBjb25zZW5zdXMgYW5kIHRoZSBj aGFpcnMgZGVjbGFyZWQgdGhlIGlzc3VlIGNsb3NlZC4gIFdoeSBpcyBpdCBvcGVuIGFnYWluPwoK QW5keQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTWFydGluIEJqb3JrbHVuZCIg PG1iakB0YWlsLWYuY29tPgpEYXRlOiBXZWQsIE9jdCA2LCAyMDEwIDA0OjM3ClN1YmplY3Q6IFtO ZXRjb25mXSBXZSBORUVEIFJFU1BPTlNFUzogV0cgTGFzdCBDYWxsIGVuZGVkIGZvcjpkcmFmdC1p ZXRmLW5ldGNvbmYtNDc0MWJpcy0wNC50eHQKVG86IDxtZWhtZXQuZXJzdWVAbnNuLmNvbT4KQ2M6 IDxuZXRjb25mQGlldGYub3JnPgoKCkhpLAoKIkVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmlj aCkiIDxtZWhtZXQuZXJzdWVAbnNuLmNvbT4gd3JvdGU6Cj4gW0NvLWNoYWlyIGhhdCBvZmZdCj4g Cj4gSSBoYWQgcmVhZCB0aGUgZG9jdW1lbnQgYnV0IHJlYWQgYWdhaW4uIAo+IEkgY291bGRuJ3Qg ZmluZCBhbnkgc2VyaW91cyBpc3N1ZXMgYW5kIEkgdGhpbmsgaXQgaXMgCj4gcmVhZHkgZm9yIHB1 YmxpY2F0aW9uIHRob3VnaCBJIGhhdmUgYSBmZXcgc3VnZ2VzdGlvbnMKPiB0byBtYWtlIGl0IG1v cmUgY29uc2lzdGVudCBhbmQgdG8gaW1wcm92ZSB0aGUgY2xhcml0eSAKPiBhcyBhIHN0YW5kYXJk LXRyYWNrIGRvY3VtZW50Lgo+IAo+IAo+IFNlY3Rpb24gMS4xLiBUZXJtaW5vbG9neQo+IAo+IEkg d291bGQgc3VnZ2VzdCB0byBicmluZyB0aGUgdGVybXMgY2xpZW50L21hbmFnZXIvCj4gYXBwbGlj YXRpb24gdnMuIGFnZW50L3NlcnZlci9kZXZpY2UgYXMgZWFybHkgYXMgCj4gcG9zc2libGUgaW50 byByZWxhdGlvbi4gVGhlIGRvY3VtZW50IG1haW5seSBhdm9pZHMgCj4gdGhlIHVzYWdlIG9mIHRo ZSB0ZXJtcyBtYW5hZ2VyIGFuZCBhZ2VudCB0aG91Z2ggCj4gdGhlcmUgYXJlIHNvbWUgbGVmdG92 ZXJzLgo+IAo+IE9MRDogCj4gICAgY2xpZW50OiBBIGNsaWVudCBpbnZva2VzIHByb3RvY29sIG9w ZXJhdGlvbnMgb24gYSBzZXJ2ZXIuCj4gTkVXOiAKPiAgICBjbGllbnQ6IEEgY2xpZW50IChtYW5h Z2VyLCBhcHBsaWNhdGlvbikgaW52b2tlcyAKPiAgICBwcm90b2NvbCBvcGVyYXRpb25zIG9uIGEg c2VydmVyIChhZ2VudCwgZGV2aWNlKS4KPiAKPiBPTEQ6IAo+ICAgIHNlcnZlcjogQSBzZXJ2ZXIg ZXhlY3V0ZXMgcHJvdG9jb2wgb3BlcmF0aW9ucyBpbnZva2VkIGJ5IGEgY2xpZW50Lgo+IE5FVzog Cj4gICAgc2VydmVyOiBBIHNlcnZlciAoYWdlbnQsIGRldmljZSkgZXhlY3V0ZXMgcHJvdG9jb2wg Cj4gICAgb3BlcmF0aW9ucyBpbnZva2VkIGJ5IGEgY2xpZW50IChtYW5hZ2VyLCBhcHBsaWNhdGlv bikuCgpJIGFncmVlIHdpdGggbXkgY28tZWRpdG9ycyB0aGF0IHdlIHNob3VsZCBzdGljayB0byB0 aGUgY2xpZW50L3NlcnZlcgp0ZXJtaW5vbG9neS4gIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBwbGFj ZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlIHdlCnNob3VsZCBjaGFuZ2UgdGhlIHRlcm1pbm9sb2d5 IGZyb20gZS5nLiBhcHBsaWNhdGlvbiB0byBjbGllbnQuCgo+IFNlY3Rpb24gMS4yLiBQcm90b2Nv bCBPdmVydmlldwo+IAo+IFRvIGdldCBpdCBjb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhl IGRvY3VtZW50IGl0IHdvdWxkIAo+IGJlIGdvb2QgdG8gdXNlIG9ubHkgc2luZ3VsYXIgZm9yIGxh eWVyIHRpdGxlcy4KPiAKPiBzL09wZXJhdGlvbnMvT3BlcmF0aW9uLwo+IHMvTWVzc2FnZXMvTWVz c2FnZS8KPiBzL1NlY3VyZSBUcmFuc3BvcnRzL1NlY3VyZSBUcmFuc3BvcnQvCj4gcy9UaGUgTWVz c2FnZXMgbGF5ZXIvVGhlIE1lc3NhZ2UgbGF5ZXIvCj4gcy9UaGUgT3BlcmF0aW9ucyBsYXllci9U aGUgT3BlcmF0aW9uIGxheWVyLwoKSSBhZ3JlZSB0aGF0IHNpbmd1bGFyIG1ha2VzIG1vcmUgc2Vu c2UuICBJIHN1cHBvcnQgdGhpcyBjaGFuZ2UuICBXaGF0CmRvIG90aGVycyB0aGluaz8KCj4gU2Vj dGlvbiAxLjQuIFNlcGFyYXRpb24gb2YgQ29uZmlndXJhdGlvbiBhbmQgU3RhdGUgRGF0YQo+IAo+ IE9MRDoKPiAgICBGb3IgZXhhbXBsZSwgaWYgYSBsb2NhbCBkYXRhYmFzZSBvZiB1c2VyIGF1dGhl bnRpY2F0aW9uIGRhdGEgaXMKPiAgICBzdG9yZWQgb24gdGhlIGRldmljZSwgaXQgaXMgYW4gaW1w bGVtZW50YXRpb24tZGVwZW5kZW50IG1hdHRlcgo+ICAgIHdoZXRoZXIgaXQgaXMgaW5jbHVkZWQg aW4gY29uZmlndXJhdGlvbiBkYXRhLgo+IE5FVzoKPiAgICBGb3IgZXhhbXBsZSwgaWYgYSBsb2Nh bCBkYXRhYmFzZSBvZiB1c2VyIGF1dGhlbnRpY2F0aW9uIGRhdGEgaXMKPiAgICBzdG9yZWQgb24g dGhlIGRldmljZSwgaXQgaXMgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50LCB3aGV0aGVyIAo+ICAg IGl0IGlzIGluY2x1ZGVkIGluIGNvbmZpZ3VyYXRpb24gZGF0YS4KCldoeSBpcyB0aGUgbmV3IHRl eHQgYmV0dGVyPwoKPiBTZWN0aW9uIDMuIFhNTCBDb25zaWRlcmF0aW9ucwo+IAo+IENvbmNlcm5p bmcgdGhlIG1haWwtdGhyZWFkIG9uICJob3cgdG8gaGFuZGxlIFhNTCBwYXJzZSAKPiBlcnJvcnMi IEkgYWdyZWUgd2l0aCB0aGUgbGFzdCBwcm9wb3NlZCB0ZXh0Lgo+IAo+IE9MRDoKPiAgICBBbGwg TkVUQ09ORiBtZXNzYWdlcyBNVVNUIGJlIHdlbGwtZm9ybWVkIFhNTCwgZW5jb2RlZCBpbiBVVEYt OC4KPiAKPiBORVc6Cj4gICAgQWxsIE5FVENPTkYgbWVzc2FnZXMgTVVTVCBiZSB3ZWxsLWZvcm1l ZCBYTUwsIGVuY29kZWQgaW4gVVRGLTguICAKPiAgICBJZiBhIHNlcnZlciByZWNlaXZlcyBhIG1l c3NhZ2UgdGhhdCBpcyBub3Qgd2VsbC1mb3JtZWQgWE1MLCBpdCBNVVNUCj4gICAgcmVwbHkgd2l0 aCBhbiAnb3BlcmF0aW9uLWZhaWxlZCcgZXJyb3IuCgpUaGUgY2hhaXJzIG11c3QgdGVsbCB1cyB3 aGF0IHRvIGRvIHdpdGggdGhpcyBpc3N1ZS4KCj4gU2VjdGlvbiAzLjIuIE5vIERvY3VtZW50IFR5 cGUgRGVjbGFyYXRpb25zCj4gCj4gVGhlIHRpdGxlIHNvdW5kcyBsaWtlIGEgY29tbWFuZC4KPiBD aGFuZ2UgdG8gIkRvY3VtZW50IFR5cGUgRGVjbGFyYXRpb25zIi4KCk9rLgoKPiBTZWN0aW9uIDQu My4gPHJwYy1lcnJvcj4gRWxlbWVudAo+IAo+IHMvbGF5ZXI6IE1lc3NhZ2VzL2xheWVyOiBNZXNz YWdlLwo+IHMvbGF5ZXI6IE9wZXJhdGlvbnMvbGF5ZXI6IE9wZXJhdGlvbi8KClNlZSBhYm92ZS4K Cj4gU2VjdGlvbiA1LjIuIERhdGEgTW9kZWxpbmcKPiAKPiAiRGV2aWNlcyBhbmQgbWFuYWdlcnMg bWF5IHN1cHBvcnQgbXVsdGlwbGUgZGF0YSBtb2RlbHMsIC4uLiIKPiAKPiBzL21hbmFnZXJzL2Fw cGxpY2F0aW9ucy8KCkknZCBwcmVmZXIgIkNsaWVudHMgYW5kIHNlcnZlcnMgbWF5IHN1cHBvcnQu Li4iLgoKPiBTZWN0aW9uIDcuNS4gPGxvY2s+Cj4gCj4gVG8gZGlmZmVyZW50aWF0ZSBmcm9tIFBh cnRpYWwgTG9jayBSRkMgY2xlYXJseSwgSSB3b3VsZCAKPiB1bmRlcmxpbmUgdGhhdCB0aGUgb3Bl cmF0aW9uIGlzIG9uIHRoZSBlbnRpcmUgY29uZmlndXJhdGlvbiAKPiBkYXRhc3RvcmUuCj4gCj4g T0xEOiAKPiAgICBUaGUgbG9jayBvcGVyYXRpb24gYWxsb3dzIHRoZSBjbGllbnQgdG8gbG9jayB0 aGUgY29uZmlndXJhdGlvbgo+ICAgIHN5c3RlbSBvZiBhIGRldmljZS4KPiBORVc6Cj4gICAgVGhl IGxvY2sgb3BlcmF0aW9uIGFsbG93cyB0aGUgY2xpZW50IHRvIGxvY2sgYW4gZW50aXJlIGNvbmZp Z3VyYXRpb24KPiAgICBkYXRhc3RvcmUgb2YgYSBzZXJ2ZXIuCgpPay4KCj4gSSBhbHNvIHdvdWxk IHN1Z2dlc3QgdG8ga2VlcCB1c2luZyB0aGUgdGVybSAiY29uZmlndXJhdGlvbiAKPiBkYXRhc3Rv cmUiIGluc3RlYWQgb2YgImNvbmZpZ3VyYXRpb24iLCB3aGljaCBpcyB1c2VkIGluIG90aGVyIAo+ IHBhcnRzIG9mIHRoZSBkb2N1bWVudCB0byBtZWFuIGEgc3BlY2lmaWMgcGFydCBvZiB0aGUgCj4g Y29uZmlndXJhdGlvbiBvZiBhIGRhdGFzdG9yZS4KCk9rLgoKPiBFLmcuCj4gIkFuIGF0dGVtcHQg dG8gbG9jayB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgTVVTVC4uLiIKPiAiVGhlIHRhcmdl dCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBpcyA8Y2FuZGlkYXRlPiwuLi4iCj4gIlRoZSB0YXJn ZXQgcGFyYW1ldGVyIG5hbWVzIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSB0aGF0IHdpbGwg YmUKPiBsb2NrZWQuIgo+IAo+IFNlYy4gMS4xLiBzYXlzOiAKPiAic2Vzc2lvbjogQ2xpZW50IGFu ZCBzZXJ2ZXIgZXhjaGFuZ2UgbWVzc2FnZXMgdXNpbmcgYSBzZWN1cmUsIAo+IGNvbm5lY3Rpb24t b3JpZW50ZWQgc2Vzc2lvbi4iCj4gCj4gU2VjLiAyLjEuIENvbm5lY3Rpb24tT3JpZW50ZWQgT3Bl cmF0aW9uIHNheXM6IAo+ICJGb3IgZXhhbXBsZSwgd2hlbiBhIGxvY2sgaXMgYWNxdWlyZWQgYnkg YSBjbGllbnQsIHRoZSBsb2NrIAo+IHBlcnNpc3RzIHVudGlsIGVpdGhlciBpdCBpcyBleHBsaWNp dGx5IHJlbGVhc2VkIG9yIHRoZSBzZXJ2ZXIgCj4gZGV0ZXJtaW5lcyB0aGF0IHRoZSBjb25uZWN0 aW9uIGhhcyBiZWVuIHRlcm1pbmF0ZWQuIgo+IAo+IFNlYy4gMi4zLiBBdXRoZW50aWNhdGlvbiBz YXlzOiAKPiAiVGhlIGFjY2VzcyBwZXJtaXNzaW9ucyBvZiBhIGdpdmVuIGNsaWVudCwgaWRlbnRp ZmllZCBieSBpdHMgCj4gTkVUQ09ORiB1c2VybmFtZSwgYXJlIHBhcnQgb2YgdGhlIGNvbmZpZ3Vy YXRpb24gb2YgdGhlIE5FVENPTkYgCj4gc2VydmVyLiBUaGVzZSBwZXJtaXNzaW9ucyBNVVNUIGJl IGVuZm9yY2VkIGR1cmluZyB0aGUgcmVtYWluZGVyIAo+IG9mIHRoZSBORVRDT05GIHNlc3Npb24u Igo+IAo+IFNlYy4gNy41IHNheXM6Cj4gIlRoZSA8a2lsbC1zZXNzaW9uPiBvcGVyYXRpb24gY2Fu IGJlIHVzZWQgdG8gZm9yY2UgdGhlIAo+IHJlbGVhc2Ugb2YgYSBsb2NrIG93bmVkIGJ5IGFub3Ro ZXIgTkVUQ09ORiBzZXNzaW9uLiIKPiAKPiBIb3cgYSBjbGllbnQgY2FuIHJlbGVhc2UgYSBsb2Nr IHdoaWNoIGlzIG93bmVkIGJ5IGFub3RoZXIgCj4gc2Vzc2lvbiBuZWVkcyB0byBiZSBlbGFib3Jh dGVkLiBFLmcuIFBhcnRpYWwgTG9jayBSRkMgc2F5czogCj4gIklmIG5lZWRlZCwgdGhlIHJldHVy bmVkIHNlc3Npb24taWQgbWF5IGJlIHVzZWQgdG8gPGtpbGwtc2Vzc2lvbj4gdGhlCj4gTkVUQ09O RiBzZXNzaW9uIGhvbGRpbmcgdGhlIGxvY2suIgo+IAo+IEkgYWN0dWFsbHkgd291bGQgc3VnZ2Vz dCB0byBkZWxldGUgdGhpcyBzZW50ZW5jZSBpbiBzZWN0aW9uIDcuNS4gCj4gYW5kIHN0aWNrIHRv IHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAyLjEuIAoKSSB0aGluayB0aGUgdGV4dCBpbiA3LjUg Z2l2ZXMgdXNlZnVsIGluZm9ybWF0aW9uLiAgSSBhbSBub3Qgc3VyZSB3aHkKeW91IHRoaW5rIGl0 IG5lZWRzIHRvIGJlIHJlbW92ZWQuCgo+IFNlY3Rpb24gNy43LiA8Z2V0Pgo+IAo+ICJmaWx0ZXI6 Cj4gICAgVGhpcyBwYXJhbWV0ZXIgc3BlY2lmaWVzIHRoZSBwb3J0aW9uIG9mIHRoZSBzeXN0ZW0K PiAgICBjb25maWd1cmF0aW9uIGFuZCBzdGF0ZSBkYXRhIHRvIHJldHJpZXZlLiAgSWYgdGhpcyBw YXJhbWV0ZXIgaXMKPiAgICBub3QgcHJlc2VudCwgYWxsIHRoZSBkZXZpY2UgY29uZmlndXJhdGlv biBhbmQgc3RhdGUgaW5mb3JtYXRpb24KPiAgICBpcyByZXR1cm5lZC4iCj4gCj4gRm9yIHRoZSBz YWtlIG9mIGNvbXBsZXRlbmVzcyBJIHdvdWxkIGFkZCB3aGF0IGhhcHBlbnMgCj4gaWYgdGhlIGZp bHRlciBwYXJhbWV0ZXIgaXMgYXZhaWxhYmxlIGJ1dCBlbXB0eS4KCklmIHRoZSBmaWx0ZXIgcGFy YW1ldGVyIGlzIHByZXNlbnQsIHRoZSAndHlwZScgYXR0cmlidXRlIHNwZWNpZmllcyBpZgppdCBp cyBhIHN1YnRyZWUgZmlsdGVyIG9yIHhwYXRoIGZpbHRlci4gIElmIG5vICd0eXBlJyBhdHRyaWJ1 dGUgaXMKcHJlc2VudCwgaXQgZGVmYXVsdHMgdG8gc3VidHJlZSBmaWx0ZXJpbmcuICBTZWN0aW9u IDYgZGVzY3JpYmVzIHRoaXMKYWxnb3JpdGhtLCBhbmQgc3BlY2lmaWNpYWxseSA2LjQuMiBzcGVj aWZpZXMgaG93IGFuIGVtcHR5IHN1YnRyZWUKZmlsdGVyIHdvcmtzLiAgSSBkb24ndCB0aGluayB3 ZSBzaG91bGQgc2F5IGFueXRoaW5nIGFib3V0IHNwZWNpYWwKZmlsdGVyIHZhbHVlcyBpbiA3Ljcu Cgo+IFNlY3Rpb24gOC40LjEuIERlc2NyaXB0aW9uCj4gCj4gcy9jb25maWd1cmF0aW9uLCAvY29u ZmlndXJhdGlvbi4gLwoKT0suCgo+IFNlY3Rpb24gOC40LjEuIERlc2NyaXB0aW9uIGFuZCA4LjYu MS4gRGVzY3JpcHRpb24KPiAKPiBPTEQ6Cj4gICAgVGhlIGN1cnJlbnQgdmVyc2lvbiBpcyAxLjEs IGFuZCBpcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuIEl0Cj4gZXh0ZW5kcy4uLgo+IE5FVzoK PiAgICBUaGUgdmVyc2lvbiAxLjEgaXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFuZCBleHRl bmRzLi4uCgpPaywgSSBkaWQ6ICBWZXJzaW9uIDEuMS4gaXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGFuZCBleHRlbmRzLi4uCgoKPiBTZWN0aW9uIDEyLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMKPiAKPiBBZGQgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy11c2FnZS0xMSBhcyBpbmZvcm1hdGl2 ZSByZWZlcmVuY2UuCgpXaHk/ICBUaGF0IGRvY3VtZW50IGlzIGludGVuZGVkIGZvciBZQU5HIG1v ZHVsZSB3cml0ZXJzLgoKPiBTZWN0aW9uIDkuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCj4gCj4g SSB3b3VsZCBzdWdnZXN0IHRvIGFkZCBhIGZldyBzZW50ZW5jZXMgZm9yIHRoZSBFT00gaGFuZGxp bmcgCj4gYW5kIHRoZSBwb3NzaWJsZSB0aHJlYWQgY29uY2VybmluZyBzZWN0aW9uIDMuIEl0IHdv dWxkIGJlIAo+IGludGVyZXN0aW5nIHRvIHJlY29tbWVuZCBhIHBvc3NpYmxlIHJlYWN0aW9uIGlm IHRoaXMgaGFwcGVucyAKPiBmcmVxdWVudGx5LCBlLmcuIHRvIGRyb3AgdGhlIE5FVENPTkYgc2Vz c2lvbi4KCkknbGwgYXdhaXQgdGhlIGN1cnJlbnQgTUwgZGlzY3Vzc2lvbi4uLgoKCj4gQXBwZW5k aXggQi4gWE1MIFNjaGVtYSBmb3IgTkVUQ09ORiBNZXNzYWdlcyBMYXllcgo+IAo+IHMvWE1MIFNj aGVtYSBmb3IgTkVUQ09ORiBNZXNzYWdlcyBMYXllci8KPiBYTUwgU2NoZW1hIGZvciBORVRDT05G IE1lc3NhZ2UgTGF5ZXIvCgpTZWUgYWJvdmUuCgoKL21hcnRpbgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcgbGlzdApOZXRjb25m QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgoK ------=_Part_3_1286377757401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayB0aGlzIFdHIG5lZWRzIHRvIG1ha2UgZGVjaXNpb25zIGFuZCBzdGljayB0byB0aGVt Ljxicj5DaGFuZ2luZyBlcnJvciBoYW5kbGluZyBmb3IgbWFsZm9ybWVkIFhNTCBpcyBub3QgYW4g ZWRpdG9yaWFsIGNoYW5nZS4gJm5ic3A7IFRoZSBXRyBkaWQgbm90IHJlYWNoIGNvbnNlbnN1cyBh bmQgdGhlIGNoYWlycyBkZWNsYXJlZCB0aGUgaXNzdWUgY2xvc2VkLiAmbmJzcDtXaHkgaXMgaXQg b3BlbiBhZ2Fpbj88YnI+PGJyPkFuZHk8YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08 YnI+RnJvbTogJnF1b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7bWJqQHRhaWwtZi5jb20m Z3Q7PGJyPkRhdGU6IFdlZCwgT2N0IDYsIDIwMTAgMDQ6Mzc8YnI+U3ViamVjdDogW05ldGNvbmZd IFdlIE5FRUQgUkVTUE9OU0VTOiBXRyBMYXN0IENhbGwgZW5kZWQgZm9yOmRyYWZ0LWlldGYtbmV0 Y29uZi00NzQxYmlzLTA0LnR4dDxicj5UbzogJmx0O21laG1ldC5lcnN1ZUBuc24uY29tJmd0Ozxi cj5DYzogJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+SGksPGJyPjxicj4mcXVv dDtFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpJnF1b3Q7ICZsdDttZWhtZXQuZXJzdWVA bnNuLmNvbSZndDsgd3JvdGU6PGJyPiZndDsgW0NvLWNoYWlyIGhhdCBvZmZdPGJyPiZndDsgPGJy PiZndDsgSSBoYWQgcmVhZCB0aGUgZG9jdW1lbnQgYnV0IHJlYWQgYWdhaW4uIDxicj4mZ3Q7IEkg Y291bGRuJiMzOTt0IGZpbmQgYW55IHNlcmlvdXMgaXNzdWVzIGFuZCBJIHRoaW5rIGl0IGlzIDxi cj4mZ3Q7IHJlYWR5IGZvciBwdWJsaWNhdGlvbiB0aG91Z2ggSSBoYXZlIGEgZmV3IHN1Z2dlc3Rp b25zPGJyPiZndDsgdG8gbWFrZSBpdCBtb3JlIGNvbnNpc3RlbnQgYW5kIHRvIGltcHJvdmUgdGhl IGNsYXJpdHkgPGJyPiZndDsgYXMgYSBzdGFuZGFyZC10cmFjayBkb2N1bWVudC48YnI+Jmd0OyA8 YnI+Jmd0OyA8YnI+Jmd0OyBTZWN0aW9uIDEuMS4gVGVybWlub2xvZ3k8YnI+Jmd0OyA8YnI+Jmd0 OyBJIHdvdWxkIHN1Z2dlc3QgdG8gYnJpbmcgdGhlIHRlcm1zIGNsaWVudC9tYW5hZ2VyLzxicj4m Z3Q7IGFwcGxpY2F0aW9uIHZzLiBhZ2VudC9zZXJ2ZXIvZGV2aWNlIGFzIGVhcmx5IGFzIDxicj4m Z3Q7IHBvc3NpYmxlIGludG8gcmVsYXRpb24uIFRoZSBkb2N1bWVudCBtYWlubHkgYXZvaWRzIDxi cj4mZ3Q7IHRoZSB1c2FnZSBvZiB0aGUgdGVybXMgbWFuYWdlciBhbmQgYWdlbnQgdGhvdWdoIDxi cj4mZ3Q7IHRoZXJlIGFyZSBzb21lIGxlZnRvdmVycy48YnI+Jmd0OyA8YnI+Jmd0OyBPTEQ6IDxi cj4mZ3Q7ICZuYnNwOyAmbmJzcDtjbGllbnQ6IEEgY2xpZW50IGludm9rZXMgcHJvdG9jb2wgb3Bl cmF0aW9ucyBvbiBhIHNlcnZlci48YnI+Jmd0OyBORVc6IDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtj bGllbnQ6IEEgY2xpZW50IChtYW5hZ2VyLCBhcHBsaWNhdGlvbikgaW52b2tlcyA8YnI+Jmd0OyAm bmJzcDsgJm5ic3A7cHJvdG9jb2wgb3BlcmF0aW9ucyBvbiBhIHNlcnZlciAoYWdlbnQsIGRldmlj ZSkuPGJyPiZndDsgPGJyPiZndDsgT0xEOiA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7c2VydmVyOiBB IHNlcnZlciBleGVjdXRlcyBwcm90b2NvbCBvcGVyYXRpb25zIGludm9rZWQgYnkgYSBjbGllbnQu PGJyPiZndDsgTkVXOiA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7c2VydmVyOiBBIHNlcnZlciAoYWdl bnQsIGRldmljZSkgZXhlY3V0ZXMgcHJvdG9jb2wgPGJyPiZndDsgJm5ic3A7ICZuYnNwO29wZXJh dGlvbnMgaW52b2tlZCBieSBhIGNsaWVudCAobWFuYWdlciwgYXBwbGljYXRpb24pLjxicj48YnI+ SSBhZ3JlZSB3aXRoIG15IGNvLWVkaXRvcnMgdGhhdCB3ZSBzaG91bGQgc3RpY2sgdG8gdGhlIGNs aWVudC9zZXJ2ZXI8YnI+dGVybWlub2xvZ3kuICZuYnNwO1RoZXJlIGFyZSBhIGNvdXBsZSBvZiBw bGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlIHdlPGJyPnNob3VsZCBjaGFuZ2UgdGhlIHRlcm1p bm9sb2d5IGZyb20gZS5nLiBhcHBsaWNhdGlvbiB0byBjbGllbnQuPGJyPjxicj4mZ3Q7IFNlY3Rp b24gMS4yLiBQcm90b2NvbCBPdmVydmlldzxicj4mZ3Q7IDxicj4mZ3Q7IFRvIGdldCBpdCBjb25z aXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IGl0IHdvdWxkIDxicj4mZ3Q7IGJl IGdvb2QgdG8gdXNlIG9ubHkgc2luZ3VsYXIgZm9yIGxheWVyIHRpdGxlcy48YnI+Jmd0OyA8YnI+ Jmd0OyBzL09wZXJhdGlvbnMvT3BlcmF0aW9uLzxicj4mZ3Q7IHMvTWVzc2FnZXMvTWVzc2FnZS88 YnI+Jmd0OyBzL1NlY3VyZSBUcmFuc3BvcnRzL1NlY3VyZSBUcmFuc3BvcnQvPGJyPiZndDsgcy9U aGUgTWVzc2FnZXMgbGF5ZXIvVGhlIE1lc3NhZ2UgbGF5ZXIvPGJyPiZndDsgcy9UaGUgT3BlcmF0 aW9ucyBsYXllci9UaGUgT3BlcmF0aW9uIGxheWVyLzxicj48YnI+SSBhZ3JlZSB0aGF0IHNpbmd1 bGFyIG1ha2VzIG1vcmUgc2Vuc2UuICZuYnNwO0kgc3VwcG9ydCB0aGlzIGNoYW5nZS4gJm5ic3A7 V2hhdDxicj5kbyBvdGhlcnMgdGhpbms/PGJyPjxicj4mZ3Q7IFNlY3Rpb24gMS40LiBTZXBhcmF0 aW9uIG9mIENvbmZpZ3VyYXRpb24gYW5kIFN0YXRlIERhdGE8YnI+Jmd0OyA8YnI+Jmd0OyBPTEQ6 PGJyPiZndDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlLCBpZiBhIGxvY2FsIGRhdGFiYXNlIG9m IHVzZXIgYXV0aGVudGljYXRpb24gZGF0YSBpczxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdG9yZWQg b24gdGhlIGRldmljZSwgaXQgaXMgYW4gaW1wbGVtZW50YXRpb24tZGVwZW5kZW50IG1hdHRlcjxi cj4mZ3Q7ICZuYnNwOyAmbmJzcDt3aGV0aGVyIGl0IGlzIGluY2x1ZGVkIGluIGNvbmZpZ3VyYXRp b24gZGF0YS48YnI+Jmd0OyBORVc6PGJyPiZndDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlLCBp ZiBhIGxvY2FsIGRhdGFiYXNlIG9mIHVzZXIgYXV0aGVudGljYXRpb24gZGF0YSBpczxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDtzdG9yZWQgb24gdGhlIGRldmljZSwgaXQgaXMgaW1wbGVtZW50YXRpb24t ZGVwZW5kZW50LCB3aGV0aGVyIDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtpdCBpcyBpbmNsdWRlZCBp biBjb25maWd1cmF0aW9uIGRhdGEuPGJyPjxicj5XaHkgaXMgdGhlIG5ldyB0ZXh0IGJldHRlcj88 YnI+PGJyPiZndDsgU2VjdGlvbiAzLiBYTUwgQ29uc2lkZXJhdGlvbnM8YnI+Jmd0OyA8YnI+Jmd0 OyBDb25jZXJuaW5nIHRoZSBtYWlsLXRocmVhZCBvbiAmcXVvdDtob3cgdG8gaGFuZGxlIFhNTCBw YXJzZSA8YnI+Jmd0OyBlcnJvcnMmcXVvdDsgSSBhZ3JlZSB3aXRoIHRoZSBsYXN0IHByb3Bvc2Vk IHRleHQuPGJyPiZndDsgPGJyPiZndDsgT0xEOjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtBbGwgTkVU Q09ORiBtZXNzYWdlcyBNVVNUIGJlIHdlbGwtZm9ybWVkIFhNTCwgZW5jb2RlZCBpbiBVVEYtOC48 YnI+Jmd0OyA8YnI+Jmd0OyBORVc6PGJyPiZndDsgJm5ic3A7ICZuYnNwO0FsbCBORVRDT05GIG1l c3NhZ2VzIE1VU1QgYmUgd2VsbC1mb3JtZWQgWE1MLCBlbmNvZGVkIGluIFVURi04LiAmbmJzcDs8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7SWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSBtZXNzYWdlIHRoYXQg aXMgbm90IHdlbGwtZm9ybWVkIFhNTCwgaXQgTVVTVDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZXBs eSB3aXRoIGFuICYjMzk7b3BlcmF0aW9uLWZhaWxlZCYjMzk7IGVycm9yLjxicj48YnI+VGhlIGNo YWlycyBtdXN0IHRlbGwgdXMgd2hhdCB0byBkbyB3aXRoIHRoaXMgaXNzdWUuPGJyPjxicj4mZ3Q7 IFNlY3Rpb24gMy4yLiBObyBEb2N1bWVudCBUeXBlIERlY2xhcmF0aW9uczxicj4mZ3Q7IDxicj4m Z3Q7IFRoZSB0aXRsZSBzb3VuZHMgbGlrZSBhIGNvbW1hbmQuPGJyPiZndDsgQ2hhbmdlIHRvICZx dW90O0RvY3VtZW50IFR5cGUgRGVjbGFyYXRpb25zJnF1b3Q7Ljxicj48YnI+T2suPGJyPjxicj4m Z3Q7IFNlY3Rpb24gNC4zLiAmbHQ7cnBjLWVycm9yJmd0OyBFbGVtZW50PGJyPiZndDsgPGJyPiZn dDsgcy9sYXllcjogTWVzc2FnZXMvbGF5ZXI6IE1lc3NhZ2UvPGJyPiZndDsgcy9sYXllcjogT3Bl cmF0aW9ucy9sYXllcjogT3BlcmF0aW9uLzxicj48YnI+U2VlIGFib3ZlLjxicj48YnI+Jmd0OyBT ZWN0aW9uIDUuMi4gRGF0YSBNb2RlbGluZzxicj4mZ3Q7IDxicj4mZ3Q7ICZxdW90O0RldmljZXMg YW5kIG1hbmFnZXJzIG1heSBzdXBwb3J0IG11bHRpcGxlIGRhdGEgbW9kZWxzLCAuLi4mcXVvdDs8 YnI+Jmd0OyA8YnI+Jmd0OyBzL21hbmFnZXJzL2FwcGxpY2F0aW9ucy88YnI+PGJyPkkmIzM5O2Qg cHJlZmVyICZxdW90O0NsaWVudHMgYW5kIHNlcnZlcnMgbWF5IHN1cHBvcnQuLi4mcXVvdDsuPGJy Pjxicj4mZ3Q7IFNlY3Rpb24gNy41LiAmbHQ7bG9jayZndDs8YnI+Jmd0OyA8YnI+Jmd0OyBUbyBk aWZmZXJlbnRpYXRlIGZyb20gUGFydGlhbCBMb2NrIFJGQyBjbGVhcmx5LCBJIHdvdWxkIDxicj4m Z3Q7IHVuZGVybGluZSB0aGF0IHRoZSBvcGVyYXRpb24gaXMgb24gdGhlIGVudGlyZSBjb25maWd1 cmF0aW9uIDxicj4mZ3Q7IGRhdGFzdG9yZS48YnI+Jmd0OyA8YnI+Jmd0OyBPTEQ6IDxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDtUaGUgbG9jayBvcGVyYXRpb24gYWxsb3dzIHRoZSBjbGllbnQgdG8gbG9j ayB0aGUgY29uZmlndXJhdGlvbjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtzeXN0ZW0gb2YgYSBkZXZp Y2UuPGJyPiZndDsgTkVXOjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgbG9jayBvcGVyYXRpb24g YWxsb3dzIHRoZSBjbGllbnQgdG8gbG9jayBhbiBlbnRpcmUgY29uZmlndXJhdGlvbjxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDtkYXRhc3RvcmUgb2YgYSBzZXJ2ZXIuPGJyPjxicj5Pay48YnI+PGJyPiZn dDsgSSBhbHNvIHdvdWxkIHN1Z2dlc3QgdG8ga2VlcCB1c2luZyB0aGUgdGVybSAmcXVvdDtjb25m aWd1cmF0aW9uIDxicj4mZ3Q7IGRhdGFzdG9yZSZxdW90OyBpbnN0ZWFkIG9mICZxdW90O2NvbmZp Z3VyYXRpb24mcXVvdDssIHdoaWNoIGlzIHVzZWQgaW4gb3RoZXIgPGJyPiZndDsgcGFydHMgb2Yg dGhlIGRvY3VtZW50IHRvIG1lYW4gYSBzcGVjaWZpYyBwYXJ0IG9mIHRoZSA8YnI+Jmd0OyBjb25m aWd1cmF0aW9uIG9mIGEgZGF0YXN0b3JlLjxicj48YnI+T2suPGJyPjxicj4mZ3Q7IEUuZy48YnI+ Jmd0OyAmcXVvdDtBbiBhdHRlbXB0IHRvIGxvY2sgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IE1VU1QuLi4mcXVvdDs8YnI+Jmd0OyAmcXVvdDtUaGUgdGFyZ2V0IGNvbmZpZ3VyYXRpb24gZGF0 YXN0b3JlIGlzICZsdDtjYW5kaWRhdGUmZ3Q7LC4uLiZxdW90Ozxicj4mZ3Q7ICZxdW90O1RoZSB0 YXJnZXQgcGFyYW1ldGVyIG5hbWVzIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSB0aGF0IHdp bGwgYmU8YnI+Jmd0OyBsb2NrZWQuJnF1b3Q7PGJyPiZndDsgPGJyPiZndDsgU2VjLiAxLjEuIHNh eXM6IDxicj4mZ3Q7ICZxdW90O3Nlc3Npb246IENsaWVudCBhbmQgc2VydmVyIGV4Y2hhbmdlIG1l c3NhZ2VzIHVzaW5nIGEgc2VjdXJlLCA8YnI+Jmd0OyBjb25uZWN0aW9uLW9yaWVudGVkIHNlc3Np b24uJnF1b3Q7PGJyPiZndDsgPGJyPiZndDsgU2VjLiAyLjEuIENvbm5lY3Rpb24tT3JpZW50ZWQg T3BlcmF0aW9uIHNheXM6IDxicj4mZ3Q7ICZxdW90O0ZvciBleGFtcGxlLCB3aGVuIGEgbG9jayBp cyBhY3F1aXJlZCBieSBhIGNsaWVudCwgdGhlIGxvY2sgPGJyPiZndDsgcGVyc2lzdHMgdW50aWwg ZWl0aGVyIGl0IGlzIGV4cGxpY2l0bHkgcmVsZWFzZWQgb3IgdGhlIHNlcnZlciA8YnI+Jmd0OyBk ZXRlcm1pbmVzIHRoYXQgdGhlIGNvbm5lY3Rpb24gaGFzIGJlZW4gdGVybWluYXRlZC4mcXVvdDs8 YnI+Jmd0OyA8YnI+Jmd0OyBTZWMuIDIuMy4gQXV0aGVudGljYXRpb24gc2F5czogPGJyPiZndDsg JnF1b3Q7VGhlIGFjY2VzcyBwZXJtaXNzaW9ucyBvZiBhIGdpdmVuIGNsaWVudCwgaWRlbnRpZmll ZCBieSBpdHMgPGJyPiZndDsgTkVUQ09ORiB1c2VybmFtZSwgYXJlIHBhcnQgb2YgdGhlIGNvbmZp Z3VyYXRpb24gb2YgdGhlIE5FVENPTkYgPGJyPiZndDsgc2VydmVyLiBUaGVzZSBwZXJtaXNzaW9u cyBNVVNUIGJlIGVuZm9yY2VkIGR1cmluZyB0aGUgcmVtYWluZGVyIDxicj4mZ3Q7IG9mIHRoZSBO RVRDT05GIHNlc3Npb24uJnF1b3Q7PGJyPiZndDsgPGJyPiZndDsgU2VjLiA3LjUgc2F5czo8YnI+ Jmd0OyAmcXVvdDtUaGUgJmx0O2tpbGwtc2Vzc2lvbiZndDsgb3BlcmF0aW9uIGNhbiBiZSB1c2Vk IHRvIGZvcmNlIHRoZSA8YnI+Jmd0OyByZWxlYXNlIG9mIGEgbG9jayBvd25lZCBieSBhbm90aGVy IE5FVENPTkYgc2Vzc2lvbi4mcXVvdDs8YnI+Jmd0OyA8YnI+Jmd0OyBIb3cgYSBjbGllbnQgY2Fu IHJlbGVhc2UgYSBsb2NrIHdoaWNoIGlzIG93bmVkIGJ5IGFub3RoZXIgPGJyPiZndDsgc2Vzc2lv biBuZWVkcyB0byBiZSBlbGFib3JhdGVkLiBFLmcuIFBhcnRpYWwgTG9jayBSRkMgc2F5czogPGJy PiZndDsgJnF1b3Q7SWYgbmVlZGVkLCB0aGUgcmV0dXJuZWQgc2Vzc2lvbi1pZCBtYXkgYmUgdXNl ZCB0byAmbHQ7a2lsbC1zZXNzaW9uJmd0OyB0aGU8YnI+Jmd0OyBORVRDT05GIHNlc3Npb24gaG9s ZGluZyB0aGUgbG9jay4mcXVvdDs8YnI+Jmd0OyA8YnI+Jmd0OyBJIGFjdHVhbGx5IHdvdWxkIHN1 Z2dlc3QgdG8gZGVsZXRlIHRoaXMgc2VudGVuY2UgaW4gc2VjdGlvbiA3LjUuIDxicj4mZ3Q7IGFu ZCBzdGljayB0byB0aGUgc3RhdGVtZW50IGluIHNlY3Rpb24gMi4xLiA8YnI+PGJyPkkgdGhpbmsg dGhlIHRleHQgaW4gNy41IGdpdmVzIHVzZWZ1bCBpbmZvcm1hdGlvbi4gJm5ic3A7SSBhbSBub3Qg c3VyZSB3aHk8YnI+eW91IHRoaW5rIGl0IG5lZWRzIHRvIGJlIHJlbW92ZWQuPGJyPjxicj4mZ3Q7 IFNlY3Rpb24gNy43LiAmbHQ7Z2V0Jmd0Ozxicj4mZ3Q7IDxicj4mZ3Q7ICZxdW90O2ZpbHRlcjo8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBwYXJhbWV0ZXIgc3BlY2lmaWVzIHRoZSBwb3J0aW9u IG9mIHRoZSBzeXN0ZW08YnI+Jmd0OyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiBhbmQgc3Rh dGUgZGF0YSB0byByZXRyaWV2ZS4gJm5ic3A7SWYgdGhpcyBwYXJhbWV0ZXIgaXM8YnI+Jmd0OyAm bmJzcDsgJm5ic3A7bm90IHByZXNlbnQsIGFsbCB0aGUgZGV2aWNlIGNvbmZpZ3VyYXRpb24gYW5k IHN0YXRlIGluZm9ybWF0aW9uPGJyPiZndDsgJm5ic3A7ICZuYnNwO2lzIHJldHVybmVkLiZxdW90 Ozxicj4mZ3Q7IDxicj4mZ3Q7IEZvciB0aGUgc2FrZSBvZiBjb21wbGV0ZW5lc3MgSSB3b3VsZCBh ZGQgd2hhdCBoYXBwZW5zIDxicj4mZ3Q7IGlmIHRoZSBmaWx0ZXIgcGFyYW1ldGVyIGlzIGF2YWls YWJsZSBidXQgZW1wdHkuPGJyPjxicj5JZiB0aGUgZmlsdGVyIHBhcmFtZXRlciBpcyBwcmVzZW50 LCB0aGUgJiMzOTt0eXBlJiMzOTsgYXR0cmlidXRlIHNwZWNpZmllcyBpZjxicj5pdCBpcyBhIHN1 YnRyZWUgZmlsdGVyIG9yIHhwYXRoIGZpbHRlci4gJm5ic3A7SWYgbm8gJiMzOTt0eXBlJiMzOTsg YXR0cmlidXRlIGlzPGJyPnByZXNlbnQsIGl0IGRlZmF1bHRzIHRvIHN1YnRyZWUgZmlsdGVyaW5n LiAmbmJzcDtTZWN0aW9uIDYgZGVzY3JpYmVzIHRoaXM8YnI+YWxnb3JpdGhtLCBhbmQgc3BlY2lm aWNpYWxseSA2LjQuMiBzcGVjaWZpZXMgaG93IGFuIGVtcHR5IHN1YnRyZWU8YnI+ZmlsdGVyIHdv cmtzLiAmbmJzcDtJIGRvbiYjMzk7dCB0aGluayB3ZSBzaG91bGQgc2F5IGFueXRoaW5nIGFib3V0 IHNwZWNpYWw8YnI+ZmlsdGVyIHZhbHVlcyBpbiA3LjcuPGJyPjxicj4mZ3Q7IFNlY3Rpb24gOC40 LjEuIERlc2NyaXB0aW9uPGJyPiZndDsgPGJyPiZndDsgcy9jb25maWd1cmF0aW9uLCAvY29uZmln dXJhdGlvbi4gLzxicj48YnI+T0suPGJyPjxicj4mZ3Q7IFNlY3Rpb24gOC40LjEuIERlc2NyaXB0 aW9uIGFuZCA4LjYuMS4gRGVzY3JpcHRpb248YnI+Jmd0OyA8YnI+Jmd0OyBPTEQ6PGJyPiZndDsg Jm5ic3A7ICZuYnNwO1RoZSBjdXJyZW50IHZlcnNpb24gaXMgMS4xLCBhbmQgaXMgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50LiBJdDxicj4mZ3Q7IGV4dGVuZHMuLi48YnI+Jmd0OyBORVc6PGJyPiZn dDsgJm5ic3A7ICZuYnNwO1RoZSB2ZXJzaW9uIDEuMSBpcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQgYW5kIGV4dGVuZHMuLi48YnI+PGJyPk9rLCBJIGRpZDogJm5ic3A7VmVyc2lvbiAxLjEuIGlz IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgZXh0ZW5kcy4uLjxicj48YnI+PGJyPiZndDsg U2VjdGlvbiAxMi4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyPiZndDsgPGJyPiZndDsgQWRk IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctdXNhZ2UtMTEgYXMgaW5mb3JtYXRpdmUgcmVmZXJlbmNl Ljxicj48YnI+V2h5PyAmbmJzcDtUaGF0IGRvY3VtZW50IGlzIGludGVuZGVkIGZvciBZQU5HIG1v ZHVsZSB3cml0ZXJzLjxicj48YnI+Jmd0OyBTZWN0aW9uIDkuIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zPGJyPiZndDsgPGJyPiZndDsgSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCBhIGZldyBzZW50ZW5j ZXMgZm9yIHRoZSBFT00gaGFuZGxpbmcgPGJyPiZndDsgYW5kIHRoZSBwb3NzaWJsZSB0aHJlYWQg Y29uY2VybmluZyBzZWN0aW9uIDMuIEl0IHdvdWxkIGJlIDxicj4mZ3Q7IGludGVyZXN0aW5nIHRv IHJlY29tbWVuZCBhIHBvc3NpYmxlIHJlYWN0aW9uIGlmIHRoaXMgaGFwcGVucyA8YnI+Jmd0OyBm cmVxdWVudGx5LCBlLmcuIHRvIGRyb3AgdGhlIE5FVENPTkYgc2Vzc2lvbi48YnI+PGJyPkkmIzM5 O2xsIGF3YWl0IHRoZSBjdXJyZW50IE1MIGRpc2N1c3Npb24uLi48YnI+PGJyPjxicj4mZ3Q7IEFw cGVuZGl4IEIuIFhNTCBTY2hlbWEgZm9yIE5FVENPTkYgTWVzc2FnZXMgTGF5ZXI8YnI+Jmd0OyA8 YnI+Jmd0OyBzL1hNTCBTY2hlbWEgZm9yIE5FVENPTkYgTWVzc2FnZXMgTGF5ZXIvPGJyPiZndDsg WE1MIFNjaGVtYSBmb3IgTkVUQ09ORiBNZXNzYWdlIExheWVyLzxicj48YnI+U2VlIGFib3ZlLjxi cj48YnI+PGJyPi9tYXJ0aW48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+TmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+TmV0Y29uZkBpZXRmLm9yZzxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+PGJy Pjxicj48YnI+ ------=_Part_3_1286377757401-- From lhotka@cesnet.cz Wed Oct 6 11:37:35 2010 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 86BE83A718C for ; Wed, 6 Oct 2010 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 RFG+GCVF2Vd5 for ; Wed, 6 Oct 2010 11:37:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A53243A717B for ; Wed, 6 Oct 2010 11:37:24 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 5B9582CDE059; Wed, 6 Oct 2010 20:37:52 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101006103533.GB52604@elstar.local> References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Oct 2010 20:37:51 +0200 Message-ID: <1286390271.13680.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 18:37:35 -0000 On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote: > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote: > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder wrote: > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > > > Section 9. Security Considerations > > > > > > > > > > > > I would suggest to add a few sentences for the EOM handling > > > > > > and the possible thread concerning section 3. It would be > > > > > > interesting to recommend a possible reaction if this happens > > > > > > frequently, e.g. to drop the NETCONF session. > > > > > > > > > > 4741bis does not have an EOM marker - so how can we discuss it in > > > > > the security considerations? > > > > > > > > EOM handling is for sure not part of NETCONF but the possible > > > > thread concerning EOM handling is. I think security considerations > > > > section should discuss the related security thread, as we did on > > > > NETCONF ML with a long mail thread. > > > > > > There is no EOM issue if you run NETCONF over BEEP. We should stick to > > > modularity and discuss things where they belong. Perhaps you want > > > different text than the one I currently image you want... > > > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the > > Messages, Operation or Content layer necessarily has an impact on > > operation and is a potential security hole. So I agree with Mehmet that > > 4741bis should not dismiss this issue completely. The protocol > > modularity has been damaged by the unfortunate EOM choice. > > > > Apart from Security Considerations, text in Sec. 3 should be changed as > > follows: > > > > OLD > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > > > NEW > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and > > MUST NOT contain the character sequence ']]>]]>'. > > Still I believe it is the transport that has to deal with this. If a > message contains ']]>]]>', a transport that can not handle this should > either not accept to transport that message or have a mechanism to > deal with it by quoting it or whatever. Pushing this issue up to the > content layer just on the ground that the mandatory SSH transport is > not totally robust seems odd from an architectural point of view. OK, but according to section 2.4 the mandatory transport protocol is RFC 4742, which does not handle the EOM issue properly. So sec. 2.4 in fact says that every compliant implementation MUST have that security hole. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From wwwrun@rfc-editor.org Wed Oct 6 12:17:19 2010 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 7F0BF3A7180; Wed, 6 Oct 2010 12:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 RS9gJWsRWpYJ; Wed, 6 Oct 2010 12:17:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 5DB8A3A722E; Wed, 6 Oct 2010 12:17:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 946C7E0739; Wed, 6 Oct 2010 12:18:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101006191805.946C7E0739@rfc-editor.org> Date: Wed, 6 Oct 2010 12:18:05 -0700 (PDT) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring 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, 06 Oct 2010 19:17:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6022 Title: YANG Module for NETCONF Monitoring Author: M. Scott, M. Bjorklund Status: Standards Track Stream: IETF Date: October 2010 Mailbox: mark.scott@ericsson.com, mbj@tail-f.com Pages: 28 Characters: 46988 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-monitoring-15.txt URL: http://www.rfc-editor.org/rfc/rfc6022.txt This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mehmet.ersue@nsn.com Wed Oct 6 13:11:24 2010 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 849FB3A71CC for ; Wed, 6 Oct 2010 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.098 X-Spam-Level: X-Spam-Status: No, score=-102.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 AgGfqVvUmqg9 for ; Wed, 6 Oct 2010 13:11:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0BF413A6FF3 for ; Wed, 6 Oct 2010 13:11:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o96KCLMr024257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Oct 2010 22:12:21 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96KCLPR029720 for ; Wed, 6 Oct 2010 22:12:21 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 22:12:21 +0200 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: Wed, 6 Oct 2010 22:12:18 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8E09@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101006191805.946C7E0739@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring Thread-Index: ActljVqmAhmEoEidQF2VjTTK9uY/ywABNq1Q References: <20101006191805.946C7E0739@rfc-editor.org> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 06 Oct 2010 20:12:21.0718 (UTC) FILETIME=[C8B5CF60:01CB6592] Subject: Re: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring 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, 06 Oct 2010 20:11:24 -0000 CONGRATULATIONS to everyone who contributed to this document. Special Thanks to the authors Mark and Martin. Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext rfc-editor@rfc-editor.org > Sent: Wednesday, October 06, 2010 9:18 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6022 >=20 > Title: YANG Module for NETCONF Monitoring > Author: M. Scott, M. Bjorklund > Status: Standards Track > Stream: IETF > Date: October 2010 > Mailbox: mark.scott@ericsson.com, > mbj@tail-f.com > Pages: 28 > Characters: 46988 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netconf-monitoring-15.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6022.txt >=20 > This document defines a Network Configuration Protocol (NETCONF) data > model to be used to monitor the NETCONF protocol. The monitoring > data model includes information about NETCONF datastores, sessions, > locks, and statistics. This data facilitates the management of a > NETCONF server. This document also defines methods for NETCONF > clients to discover data models supported by a NETCONF server and > defines a new NETCONF operation to retrieve them. > [STANDARDS TRACK] >=20 > This document is a product of the Network Configuration Working Group > of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Wed Oct 6 15:45:07 2010 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 BB38B3A71F1 for ; Wed, 6 Oct 2010 15:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.99 X-Spam-Level: X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ao5J3M3S11yn for ; Wed, 6 Oct 2010 15:45:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EAEAD3A6F50 for ; Wed, 6 Oct 2010 15:45:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37293C0019; Thu, 7 Oct 2010 00:46:06 +0200 (CEST) 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 WKTtZpMeCEbU; Thu, 7 Oct 2010 00:46:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF015C0008; Thu, 7 Oct 2010 00:46:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2CE401515EAA; Thu, 7 Oct 2010 00:45:35 +0200 (CEST) Date: Thu, 7 Oct 2010 00:45:35 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101006224535.GA55303@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> <1286390271.13680.12.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1286390271.13680.12.camel@missotis> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 22:45:07 -0000 On Wed, Oct 06, 2010 at 08:37:51PM +0200, Ladislav Lhotka wrote: > On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote: > > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote: > > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder wrote: > > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > > > > Section 9. Security Considerations > > > > > > > > > > > > > > I would suggest to add a few sentences for the EOM handling > > > > > > > and the possible thread concerning section 3. It would be > > > > > > > interesting to recommend a possible reaction if this happens > > > > > > > frequently, e.g. to drop the NETCONF session. > > > > > > > > > > > > 4741bis does not have an EOM marker - so how can we discuss it in > > > > > > the security considerations? > > > > > > > > > > EOM handling is for sure not part of NETCONF but the possible > > > > > thread concerning EOM handling is. I think security considerations > > > > > section should discuss the related security thread, as we did on > > > > > NETCONF ML with a long mail thread. > > > > > > > > There is no EOM issue if you run NETCONF over BEEP. We should stick to > > > > modularity and discuss things where they belong. Perhaps you want > > > > different text than the one I currently image you want... > > > > > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the > > > Messages, Operation or Content layer necessarily has an impact on > > > operation and is a potential security hole. So I agree with Mehmet that > > > 4741bis should not dismiss this issue completely. The protocol > > > modularity has been damaged by the unfortunate EOM choice. > > > > > > Apart from Security Considerations, text in Sec. 3 should be changed as > > > follows: > > > > > > OLD > > > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > > > > > NEW > > > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and > > > MUST NOT contain the character sequence ']]>]]>'. > > > > Still I believe it is the transport that has to deal with this. If a > > message contains ']]>]]>', a transport that can not handle this should > > either not accept to transport that message or have a mechanism to > > deal with it by quoting it or whatever. Pushing this issue up to the > > content layer just on the ground that the mandatory SSH transport is > > not totally robust seems odd from an architectural point of view. > > OK, but according to section 2.4 the mandatory transport protocol is RFC > 4742, which does not handle the EOM issue properly. So sec. 2.4 in fact > says that every compliant implementation MUST have that security hole. > I am willing to accept an addition to the security considerations that says that readers should consult the security considerations of the NETCONF transports in addition to the 4741bis security considerations section since the 4741bis security considerations only covers the base message layer and the base operations of NETCONF. A first quick attempt: This section provides security considerations for the base NETCONF message layer and the base operations of the NETCONF protocol. Security considerations for the NETCONF transports are provided in the transport documents and security considerations for the content manipulated by NETCONF can be found in the document defining data models. We could add this right at the beginning of section 9 and then it should be clear even to the causal reader that just reading section 9 of 4741bis is not sufficient to understand all security aspects of NETCONF. Note that this approach allows to add/fix security problems in all our transports without causing any text in 4741bis to become obsolete or incomplete. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Wed Oct 6 16:14:17 2010 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 61FFB3A7072 for ; Wed, 6 Oct 2010 16:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877] 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 htnkszPhrSMY for ; Wed, 6 Oct 2010 16:14:15 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id B5F663A707D for ; Wed, 6 Oct 2010 16:14:15 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o96NFAFO032016; Wed, 6 Oct 2010 16:15:14 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id rs04fg38f-6 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 16:15:13 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 16:17:17 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 6 Oct 2010 16:12:45 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "Ladislav Lhotka" Date: Wed, 6 Oct 2010 16:12:44 -0700 Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlqEeXwkDSRufBQT29v4XnWmLzHQAA6PTg Message-ID: References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> <1286390271.13680.12.camel@missotis> <20101006224535.GA55303@elstar.local> In-Reply-To: <20101006224535.GA55303@elstar.local> 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=2010-10-06_12:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060161 Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Wed, 06 Oct 2010 23:14:17 -0000 I agree with this solution proposal from Juergen. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Wednesday, October 06, 2010 3:46 PM To: Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf= -netconf-4741bis-04.txt On Wed, Oct 06, 2010 at 08:37:51PM +0200, Ladislav Lhotka wrote: > On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote: > > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote: > > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder wrote: > > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/M= unich) wrote: > > > > > > > Section 9. Security Considerations > > > > > > > > > > > > > > I would suggest to add a few sentences for the EOM handling > > > > > > > and the possible thread concerning section 3. It would be > > > > > > > interesting to recommend a possible reaction if this happens > > > > > > > frequently, e.g. to drop the NETCONF session. > > > > > >=20 > > > > > > 4741bis does not have an EOM marker - so how can we discuss it = in > > > > > > the security considerations? > > > > >=20 > > > > > EOM handling is for sure not part of NETCONF but the possible=20 > > > > > thread concerning EOM handling is. I think security consideration= s=20 > > > > > section should discuss the related security thread, as we did on= =20 > > > > > NETCONF ML with a long mail thread. > > > >=20 > > > > There is no EOM issue if you run NETCONF over BEEP. We should stick= to > > > > modularity and discuss things where they belong. Perhaps you want > > > > different text than the one I currently image you want... > > >=20 > > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in th= e > > > Messages, Operation or Content layer necessarily has an impact on > > > operation and is a potential security hole. So I agree with Mehmet th= at > > > 4741bis should not dismiss this issue completely. The protocol > > > modularity has been damaged by the unfortunate EOM choice. > > >=20 > > > Apart from Security Considerations, text in Sec. 3 should be changed = as > > > follows: > > >=20 > > > OLD > > >=20 > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > >=20 > > > NEW > > >=20 > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and > > > MUST NOT contain the character sequence ']]>]]>'. > >=20 > > Still I believe it is the transport that has to deal with this. If a > > message contains ']]>]]>', a transport that can not handle this should > > either not accept to transport that message or have a mechanism to > > deal with it by quoting it or whatever. Pushing this issue up to the > > content layer just on the ground that the mandatory SSH transport is > > not totally robust seems odd from an architectural point of view. >=20 > OK, but according to section 2.4 the mandatory transport protocol is RFC > 4742, which does not handle the EOM issue properly. So sec. 2.4 in fact > says that every compliant implementation MUST have that security hole. >=20 I am willing to accept an addition to the security considerations that says that readers should consult the security considerations of the NETCONF transports in addition to the 4741bis security considerations section since the 4741bis security considerations only covers the base message layer and the base operations of NETCONF. A first quick attempt: This section provides security considerations for the base NETCONF message layer and the base operations of the NETCONF protocol. Security considerations for the NETCONF transports are provided in the transport documents and security considerations for the content manipulated by NETCONF can be found in the document defining data models. We could add this right at the beginning of section 9 and then it should be clear even to the causal reader that just reading section 9 of 4741bis is not sufficient to understand all security aspects of NETCONF. Note that this approach allows to add/fix security problems in all our transports without causing any text in 4741bis to become obsolete or incomplete. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Wed Oct 6 16:28:10 2010 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 2842C3A71E6 for ; Wed, 6 Oct 2010 16:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.991 X-Spam-Level: X-Spam-Status: No, score=-101.991 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 t+4QU7tjjeEC for ; Wed, 6 Oct 2010 16:28:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 73F043A6B95 for ; Wed, 6 Oct 2010 16:28:08 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B7D7C0043; Thu, 7 Oct 2010 01:29:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JZ6LBM8R-BBB; Thu, 7 Oct 2010 01:29:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86CC2C003B; Thu, 7 Oct 2010 01:29:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 972631516433; Thu, 7 Oct 2010 01:28:35 +0200 (CEST) Date: Thu, 7 Oct 2010 01:28:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101006232835.GB55303@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Netconf References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> <1286390271.13680.12.camel@missotis> <20101006224535.GA55303@elstar.local> 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 Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt 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: Wed, 06 Oct 2010 23:28:10 -0000 On Thu, Oct 07, 2010 at 01:12:44AM +0200, Andy Bierman wrote: > > I agree with this solution proposal from Juergen. > I will mark that in my calendar. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 7 02:37:15 2010 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 AE2573A6EF5; Thu, 7 Oct 2010 02:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 5Km1ilBKa8r2; Thu, 7 Oct 2010 02:37:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A0ED33A6F00; Thu, 7 Oct 2010 02:37:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="241578918" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Oct 2010 05:37:57 -0400 X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="520213904" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Oct 2010 05:37:56 -0400 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: Thu, 7 Oct 2010 11:37:39 +0200 Message-ID: In-Reply-To: <20101006191805.946C7E0739@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring Thread-Index: ActljVs9Wg0ZF8b2TqymL43hlLH5cQAddC+g References: <20101006191805.946C7E0739@rfc-editor.org> From: "Romascanu, Dan (Dan)" To: , , Cc: netconf@ietf.org Subject: Re: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring 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, 07 Oct 2010 09:37:15 -0000 Congratulations to the authors, chairs and the whole WG for this achievement.=20 Regards, Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of=20 > rfc-editor@rfc-editor.org > Sent: Wednesday, October 06, 2010 9:18 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: [Netconf] RFC 6022 on YANG Module for NETCONF Monitoring >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > =20 > RFC 6022 >=20 > Title: YANG Module for NETCONF Monitoring=20 > Author: M. Scott, M. Bjorklund > Status: Standards Track > Stream: IETF > Date: October 2010 > Mailbox: mark.scott@ericsson.com,=20 > mbj@tail-f.com > Pages: 28 > Characters: 46988 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netconf-monitoring-15.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6022.txt >=20 > This document defines a Network Configuration Protocol=20 > (NETCONF) data model to be used to monitor the NETCONF=20 > protocol. The monitoring data model includes information=20 > about NETCONF datastores, sessions, locks, and statistics. =20 > This data facilitates the management of a NETCONF server. =20 > This document also defines methods for NETCONF clients to=20 > discover data models supported by a NETCONF server and=20 > defines a new NETCONF operation to retrieve them. > [STANDARDS TRACK] >=20 > This document is a product of the Network Configuration=20 > Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet=20 > standards track protocol for the Internet community,and=20 > requests discussion and suggestions for improvements. Please=20 > refer to the current edition of the Internet Official=20 > Protocol Standards (STD 1) for the standardization state and=20 > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see=20 > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to=20 > either the author of the RFC in question, or to=20 > rfc-editor@rfc-editor.org. Unless specifically noted=20 > otherwise on the RFC itself, all RFCs are for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Thu Oct 7 03:48:27 2010 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 5602D3A70CE for ; Thu, 7 Oct 2010 03:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 ycfrTXtoy14f for ; Thu, 7 Oct 2010 03:48:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 827EE3A7099 for ; Thu, 7 Oct 2010 03:48:24 -0700 (PDT) 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 o97AnJsg008683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 12:49:19 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o97AnDGw003587; Thu, 7 Oct 2010 12:49:18 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 12:48:48 +0200 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: Thu, 7 Oct 2010 12:48:33 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010D9558@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActlqEeXwkDSRufBQT29v4XnWmLzHQAA6PTgABhLdtA= References: <4C9B3E60.5030000@bwijnen.net><80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net><20101003172455.GA16616@elstar.local><80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net><20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz><20101006103533.GB52604@elstar.local> <1286390271.13680.12.camel@missotis><20101006224535.GA55303@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 07 Oct 2010 10:48:48.0975 (UTC) FILETIME=[39286DF0:01CB660D] Cc: ext Andy Bierman , Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 10:48:27 -0000 I agree and can go with this proposal too. (You don't need a calendar mark ;) Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Andy Bierman > Sent: Thursday, October 07, 2010 1:13 AM > To: Juergen Schoenwaelder; LadislavLhotka > Cc: Netconf > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt >=20 >=20 > I agree with this solution proposal from Juergen. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, October 06, 2010 3:46 PM > To: Ladislav Lhotka > Cc: Netconf > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt >=20 > On Wed, Oct 06, 2010 at 08:37:51PM +0200, Ladislav Lhotka wrote: > > On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote: > > > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote: > > > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder > wrote: > > > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > > > > > > > Section 9. Security Considerations > > > > > > > > > > > > > > > > I would suggest to add a few sentences for the EOM > handling > > > > > > > > and the possible thread concerning section 3. It would be > > > > > > > > interesting to recommend a possible reaction if this > happens > > > > > > > > frequently, e.g. to drop the NETCONF session. > > > > > > > > > > > > > > 4741bis does not have an EOM marker - so how can we discuss > it in > > > > > > > the security considerations? > > > > > > > > > > > > EOM handling is for sure not part of NETCONF but the possible > > > > > > thread concerning EOM handling is. I think security > considerations > > > > > > section should discuss the related security thread, as we did > on > > > > > > NETCONF ML with a long mail thread. > > > > > > > > > > There is no EOM issue if you run NETCONF over BEEP. We should > stick to > > > > > modularity and discuss things where they belong. Perhaps you > want > > > > > different text than the one I currently image you want... > > > > > > > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' > in the > > > > Messages, Operation or Content layer necessarily has an impact on > > > > operation and is a potential security hole. So I agree with > Mehmet that > > > > 4741bis should not dismiss this issue completely. The protocol > > > > modularity has been damaged by the unfortunate EOM choice. > > > > > > > > Apart from Security Considerations, text in Sec. 3 should be > changed as > > > > follows: > > > > > > > > OLD > > > > > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > > > > > > > NEW > > > > > > > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8, > and > > > > MUST NOT contain the character sequence ']]>]]>'. > > > > > > Still I believe it is the transport that has to deal with this. If > a > > > message contains ']]>]]>', a transport that can not handle this > should > > > either not accept to transport that message or have a mechanism to > > > deal with it by quoting it or whatever. Pushing this issue up to > the > > > content layer just on the ground that the mandatory SSH transport > is > > > not totally robust seems odd from an architectural point of view. > > > > OK, but according to section 2.4 the mandatory transport protocol is > RFC > > 4742, which does not handle the EOM issue properly. So sec. 2.4 in > fact > > says that every compliant implementation MUST have that security > hole. > > >=20 > I am willing to accept an addition to the security considerations that > says that readers should consult the security considerations of the > NETCONF transports in addition to the 4741bis security considerations > section since the 4741bis security considerations only covers the base > message layer and the base operations of NETCONF. A first quick > attempt: >=20 > This section provides security considerations for the base > NETCONF message layer and the base operations of the NETCONF > protocol. Security considerations for the NETCONF transports > are provided in the transport documents and security > considerations for the content manipulated by NETCONF can be > found in the document defining data models. >=20 > We could add this right at the beginning of section 9 and then it > should be clear even to the causal reader that just reading section 9 > of 4741bis is not sufficient to understand all security aspects of > NETCONF. >=20 > Note that this approach allows to add/fix security problems in all our > transports without causing any text in 4741bis to become obsolete or > incomplete. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 lhotka@cesnet.cz Thu Oct 7 04:02:10 2010 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 B56FF3A70F4 for ; Thu, 7 Oct 2010 04:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 rQJbJZbHVwTl for ; Thu, 7 Oct 2010 04:02:09 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id 32E643A70EA for ; Thu, 7 Oct 2010 04:02:09 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id E6CA53E01C9; Thu, 7 Oct 2010 13:03:07 +0200 (CEST) From: Ladislav Lhotka To: "Bert \(IETF\) Wijnen" , Netconf In-Reply-To: <4C9B3E60.5030000@bwijnen.net> References: <4C9B3E60.5030000@bwijnen.net> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.2.1 (i686-pc-linux-gnu) Date: Thu, 07 Oct 2010 13:03:06 +0200 Message-ID: <87r5g21d05.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for: draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 11:02:10 -0000 Hi, I hope it's not too late: I re-read again 4741bis-04 and I think it's fine with one exception: Either the EOM issue must be fixed in 4742bis or 4741bis should not require it as the mandatory transport protocol. Other comments: 1. Sec. 1.2: List item 2 refers to [8], which is the partial lock RFC. Instead, it should refer to RFC 5277 (notifications). 2. Sec. 1.3: The base NETCONF specification also corresponds to a capability, namely :base. OLD A NETCONF capability is a set of functionality that supplements the base NETCONF specification. NEW A NETCONF capability is an identified set of functionality. 3. Sec. 3: "All NETCONF messages MUST be well-formed XML, encoded in UTF-8." It should be clarified what this requirement means. My understanding is that PDUs exchanged between the client and server MUST contain well-formed messages. 4. Sec. 4.1: "If additional attributes are present in an element, a NETCONF peer MUST return them unmodified in the element. This includes any "xmlns" attributes." I think the requirement on "xmlns" attributes is quite problematic. These attributes have a very specific function, so if the server uses another prefixes or another default namespace, why should it send the "xmlns" attributes received in the RPC request? The client could thus pre-empt a prefix the server normally uses, e.g. by sending xmlns:nc="http://example.com/foo". 5. Sec. 5.2, 7.2 and elsewhere: I think it would be better to indicate the namespace in the names of XML elements or attributes, if there is any, e.g. rather than . This is especially important for attribute names because attributes with a non-null namespace URI are not common. 6. Sec. 6.2.5, fourth bullet on p. 26: "If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output." I don't understand what this means. Is it that the subtree pointed to by the instance indentifier may be included? 7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge operation may be ambiguous. In the example on p. 43, if the "running" datastore contained two interfaces Ethernet0/0 9216 Ethernet0/1 1500 the edit-config operation could mean two things: either change of the first interface or change of the other. 8. Sec. 7.5, p. 49: s/A lock MUST not/A lock MUST NOT/ 9. Sec. 8.1: "Each peer sends its element simultaneously ..." Why "simultaneously"? Should it be removed or changed to "asynchronously"? 10. Sec. 8.3.1: "A operation may be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration." What is the "value" of the candidate configuration? The first sentence in the next paragraph explains the operation correctly so this sentence could be removed. 11. Now that Appendix B declares itself as normative, I am wondering what object is supposed to be validated against the XSD schema. For example, the schema doesn't take into account the two variants of with different content model: server's must have exactly one session-id attribute whereas client's must not have it at all. The XSD has a content model that is correct neither for the server nor for the client: Lada On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" wrote: > It was pointed out to me that we did not get ANY comments to this WGLC. > Well, there was continued discussion on XML parse errors (which is > related partly to this document) on which we will come back tomorrow. > > But no other comments, Also not any " I read it, go ahead to the next step". > > Can the WG chairs assume that people have indeed read the latest version > of this document and are OK with it? > > Can you please ASAP tell us: I read the doc and I am fine with it!!! > > PLEASE > > Bert and Mehmet > > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > WG participants, this email starts a formal WG Last Call for revision 4 > > of the 4741bis document. The document is targeted as Proposed Standard > > to replace the current rfc4741. > > > > Please do review and tell us your position and comments. > > Please do so BEFORE 20 September 2010. > > > > Bert and Mehmet > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Monday, August 23, 2010 7:00 PM > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > 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-04.txt > > Pages : 121 > > Date : 2010-08-23 > > > > 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-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 mehmet.ersue@nsn.com Thu Oct 7 04:42:36 2010 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 D7A2C3A70FE for ; Thu, 7 Oct 2010 04:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 1kL4YtO9UCwy for ; Thu, 7 Oct 2010 04:42:35 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2387A3A7116 for ; Thu, 7 Oct 2010 04:42:34 -0700 (PDT) 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 o97BhO1p018788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 13:43:24 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o97BhNPQ005557; Thu, 7 Oct 2010 13:43:23 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 13:43:16 +0200 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: Thu, 7 Oct 2010 13:43:15 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> In-Reply-To: <87r5g21d05.fsf@cesnet.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActmD0E6eQSTnc6rQraaLNZR5y8x3wAAsm1Q References: <4C9B3E60.5030000@bwijnen.net> <87r5g21d05.fsf@cesnet.cz> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ladislav Lhotka" , "Netconf" X-OriginalArrivalTime: 07 Oct 2010 11:43:16.0618 (UTC) FILETIME=[D4D32EA0:01CB6614] Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 11:42:36 -0000 Hi Lada, > I re-read again 4741bis-04 and I think it's fine with one exception: > Either the EOM issue must be fixed in 4742bis or 4741bis should not > require it as the mandatory transport protocol. We discussed this several times and came several times to the=20 same conclusion.=20 A comprehensive solution would be needed to address the issue=20 restlessly. However, this would cause a V2.0 and it'll be=20 incompatible with V1.0. By our charter 4741bis and 4742bis do not have the mandate for=20 V2.0(!). Therefore we decided to keep the current solution and describe=20 the possible security thread unmistakably. Good or bad, IIRC this is the factual report of the situation. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ladislav Lhotka > Sent: Thursday, October 07, 2010 1:03 PM > To: Bert (IETF) Wijnen; Netconf > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt >=20 > Hi, >=20 > I hope it's not too late: >=20 > I re-read again 4741bis-04 and I think it's fine with one exception: > Either the EOM issue must be fixed in 4742bis or 4741bis should not > require it as the mandatory transport protocol. >=20 > Other comments: >=20 > 1. Sec. 1.2: List item 2 refers to [8], which is the partial lock > RFC. Instead, it should refer to RFC 5277 (notifications). >=20 > 2. Sec. 1.3: The base NETCONF specification also corresponds to a > capability, namely :base. >=20 > OLD >=20 > A NETCONF capability is a set of functionality that supplements the > base NETCONF specification. >=20 > NEW >=20 > A NETCONF capability is an identified set of functionality. >=20 > 3. Sec. 3: >=20 > "All NETCONF messages MUST be well-formed XML, encoded in UTF-8." >=20 > It should be clarified what this requirement means. My understanding > is that PDUs exchanged between the client and server MUST contain > well-formed messages. >=20 > 4. Sec. 4.1: >=20 > "If additional attributes are present in an element, a NETCONF > peer MUST return them unmodified in the element. This > includes any "xmlns" attributes." >=20 > I think the requirement on "xmlns" attributes is quite > problematic. These attributes have a very specific function, so if > the server uses another prefixes or another default namespace, why > should it send the "xmlns" attributes received in the RPC request? >=20 > The client could thus pre-empt a prefix the server normally uses, > e.g. by sending xmlns:nc=3D"http://example.com/foo". >=20 > 5. Sec. 5.2, 7.2 and elsewhere: >=20 > I think it would be better to indicate the namespace in the names of > XML elements or attributes, if there is any, e.g. rather > than . This is especially important for attribute names > because attributes with a non-null namespace URI are not common. >=20 > 6. Sec. 6.2.5, fourth bullet on p. 26: >=20 > "If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output." >=20 > I don't understand what this means. Is it that the subtree pointed > to > by the instance indentifier may be included? >=20 > 7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge > operation may be ambiguous. In the example on p. 43, if the > "running" > datastore contained two interfaces >=20 > > Ethernet0/0 > 9216 > > > Ethernet0/1 > 1500 > >=20 > the edit-config operation could mean two things: either change > of the first interface or change of the other. >=20 > 8. Sec. 7.5, p. 49: >=20 > s/A lock MUST not/A lock MUST NOT/ >=20 > 9. Sec. 8.1: >=20 > "Each peer sends its element simultaneously ..." >=20 > Why "simultaneously"? Should it be removed or changed to > "asynchronously"? >=20 > 10. Sec. 8.3.1: >=20 > "A operation may be performed at any time that causes the > device's running configuration to be set to the value of the > candidate configuration." >=20 > What is the "value" of the candidate configuration? The first > sentence in the next paragraph explains the operation correctly so > this sentence could be removed. >=20 > 11. Now that Appendix B declares itself as normative, I am wondering > what object is supposed to be validated against the XSD schema. For > example, the schema doesn't take into account the two variants of > with different content model: server's must have > exactly one session-id attribute whereas client's must not > have it at all. The XSD has a content model that is correct neither > for the server nor for the client: >=20 > type=3D"SessionId" minOccurs=3D"0"/> >=20 > Lada >=20 > On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" > wrote: > > It was pointed out to me that we did not get ANY comments to this > WGLC. > > Well, there was continued discussion on XML parse errors (which is > > related partly to this document) on which we will come back tomorrow. > > > > But no other comments, Also not any " I read it, go ahead to the next > step". > > > > Can the WG chairs assume that people have indeed read the latest > version > > of this document and are OK with it? > > > > Can you please ASAP tell us: I read the doc and I am fine with it!!! > > > > PLEASE > > > > Bert and Mehmet > > > > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > > WG participants, this email starts a formal WG Last Call for > revision 4 > > > of the 4741bis document. The document is targeted as Proposed > Standard > > > to replace the current rfc4741. > > > > > > Please do review and tell us your position and comments. > > > Please do so BEFORE 20 September 2010. > > > > > > Bert and Mehmet > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Monday, August 23, 2010 7:00 PM > > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > > > > 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-04.txt > > > Pages : 121 > > > Date : 2010-08-23 > > > > > > 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- > 04.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 >=20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@cesnet.cz Thu Oct 7 04:59:34 2010 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 327803A7106 for ; Thu, 7 Oct 2010 04:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 2RkNwH5TGK14 for ; Thu, 7 Oct 2010 04:59:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A4F8C3A6F20 for ; Thu, 7 Oct 2010 04:59:32 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 6550C2CDE059; Thu, 7 Oct 2010 14:00:25 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> References: <4C9B3E60.5030000@bwijnen.net> <87r5g21d05.fsf@cesnet.cz> <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 07 Oct 2010 14:00:24 +0200 Message-ID: <1286452824.2210.52.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 11:59:34 -0000 On Čt, 2010-10-07 at 13:43 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > > > I re-read again 4741bis-04 and I think it's fine with one exception: > > Either the EOM issue must be fixed in 4742bis or 4741bis should not > > require it as the mandatory transport protocol. > > We discussed this several times and came several times to the > same conclusion. > A comprehensive solution would be needed to address the issue > restlessly. However, this would cause a V2.0 and it'll be > incompatible with V1.0. Then my second alternative applies. I would find it very strange if the NETCONF protocol standard mandated the support of a transport protocol that's arguably broken, even though people differ in the assessment of how serious the flaw is. Lada > > By our charter 4741bis and 4742bis do not have the mandate for > V2.0(!). > Therefore we decided to keep the current solution and describe > the possible security thread unmistakably. > > Good or bad, IIRC this is the factual report of the situation. > > Cheers, > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of ext Ladislav Lhotka > > Sent: Thursday, October 07, 2010 1:03 PM > > To: Bert (IETF) Wijnen; Netconf > > Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended > for:draft- > > ietf-netconf-4741bis-04.txt > > > > Hi, > > > > I hope it's not too late: > > > > I re-read again 4741bis-04 and I think it's fine with one exception: > > Either the EOM issue must be fixed in 4742bis or 4741bis should not > > require it as the mandatory transport protocol. > > > > Other comments: > > > > 1. Sec. 1.2: List item 2 refers to [8], which is the partial lock > > RFC. Instead, it should refer to RFC 5277 (notifications). > > > > 2. Sec. 1.3: The base NETCONF specification also corresponds to a > > capability, namely :base. > > > > OLD > > > > A NETCONF capability is a set of functionality that supplements the > > base NETCONF specification. > > > > NEW > > > > A NETCONF capability is an identified set of functionality. > > > > 3. Sec. 3: > > > > "All NETCONF messages MUST be well-formed XML, encoded in UTF-8." > > > > It should be clarified what this requirement means. My > understanding > > is that PDUs exchanged between the client and server MUST contain > > well-formed messages. > > > > 4. Sec. 4.1: > > > > "If additional attributes are present in an element, a > NETCONF > > peer MUST return them unmodified in the element. This > > includes any "xmlns" attributes." > > > > I think the requirement on "xmlns" attributes is quite > > problematic. These attributes have a very specific function, so if > > the server uses another prefixes or another default namespace, why > > should it send the "xmlns" attributes received in the RPC request? > > > > The client could thus pre-empt a prefix the server normally uses, > > e.g. by sending xmlns:nc="http://example.com/foo". > > > > 5. Sec. 5.2, 7.2 and elsewhere: > > > > I think it would be better to indicate the namespace in the names > of > > XML elements or attributes, if there is any, e.g. > rather > > than . This is especially important for attribute names > > because attributes with a non-null namespace URI are not common. > > > > 6. Sec. 6.2.5, fourth bullet on p. 26: > > > > "If any sibling nodes of the selection node are instance identifier > > components for a conceptual data structure (e.g., list key leaf), > > then they MAY also be included in the filter output." > > > > I don't understand what this means. Is it that the subtree pointed > > to > > by the instance indentifier may be included? > > > > 7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge > > operation may be ambiguous. In the example on p. 43, if the > > "running" > > datastore contained two interfaces > > > > > > Ethernet0/0 > > 9216 > > > > > > Ethernet0/1 > > 1500 > > > > > > the edit-config operation could mean two things: either change > > > of the first interface or change of the other. > > > > 8. Sec. 7.5, p. 49: > > > > s/A lock MUST not/A lock MUST NOT/ > > > > 9. Sec. 8.1: > > > > "Each peer sends its element simultaneously ..." > > > > Why "simultaneously"? Should it be removed or changed to > > "asynchronously"? > > > > 10. Sec. 8.3.1: > > > > "A operation may be performed at any time that causes the > > device's running configuration to be set to the value of the > > candidate configuration." > > > > What is the "value" of the candidate configuration? The first > > sentence in the next paragraph explains the operation correctly so > > this sentence could be removed. > > > > 11. Now that Appendix B declares itself as normative, I am wondering > > what object is supposed to be validated against the XSD schema. For > > example, the schema doesn't take into account the two variants of > > with different content model: server's must have > > exactly one session-id attribute whereas client's must not > > have it at all. The XSD has a content model that is correct neither > > for the server nor for the client: > > > > > type="SessionId" minOccurs="0"/> > > > > Lada > > > > On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" > > wrote: > > > It was pointed out to me that we did not get ANY comments to this > > WGLC. > > > Well, there was continued discussion on XML parse errors (which is > > > related partly to this document) on which we will come back > tomorrow. > > > > > > But no other comments, Also not any " I read it, go ahead to the > next > > step". > > > > > > Can the WG chairs assume that people have indeed read the latest > > version > > > of this document and are OK with it? > > > > > > Can you please ASAP tell us: I read the doc and I am fine with it!!! > > > > > > PLEASE > > > > > > Bert and Mehmet > > > > > > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > > > WG participants, this email starts a formal WG Last Call for > > revision 4 > > > > of the 4741bis document. The document is targeted as Proposed > > Standard > > > > to replace the current rfc4741. > > > > > > > > Please do review and tell us your position and comments. > > > > Please do so BEFORE 20 September 2010. > > > > > > > > Bert and Mehmet > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Monday, August 23, 2010 7:00 PM > > > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > > > > > > > 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-04.txt > > > > Pages : 121 > > > > Date : 2010-08-23 > > > > > > > > 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- > > 04.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Thu Oct 7 08:10:38 2010 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 7F8673A6E6A for ; Thu, 7 Oct 2010 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0UWGxuQzaQEJ for ; Thu, 7 Oct 2010 08:10:34 -0700 (PDT) Received: from smtp104.sbc.mail.re3.yahoo.com (smtp104.sbc.mail.re3.yahoo.com [66.196.96.80]) by core3.amsl.com (Postfix) with SMTP id 804773A6F90 for ; Thu, 7 Oct 2010 08:10:33 -0700 (PDT) Received: (qmail 39862 invoked from network); 7 Oct 2010 15:11:33 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 07 Oct 2010 08:11:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: qRCirNMVM1kOp_JjgOE50WMbbW3pp3WeGC2coS8tR40HCZQ Q5g8SsNWDDOM_kzv6EiotK0dyfmiJArEV7mzOOMEGfpUA9EdMeKb_OH4CzBu P4J4aK0U4eNzjjTsVMvV5oU24CY4MjWUPvFEY2KPR_U_zuW4kUbBPxvcfKbi DuU1AvNC9NAGq67qVVUrUUr8M5qY73kO.Nnq6JL5X9ztJiqSrevaWgif5WGK n2nTp0p0oyR.JYpPuBzS0rpfogYojIcAxrF9xzWn0PL0IeSBfhP._OOncqEC oLBrVYKev_ShA61gJdI7hBXPQSrws1GGkF0N3zd36nWZTlXAxgItkpl0l3YA DKBNhmEbcWjV_wfPnusbC0nEUba88X3DuIAIe_EBPZwbYC9uo2nuygh4BPev WCDdgovo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CADE324.5090307@andybierman.com> Date: Thu, 07 Oct 2010 08:11:32 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <4C9B3E60.5030000@bwijnen.net> <87r5g21d05.fsf@cesnet.cz> <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 15:10:38 -0000 On 10/07/2010 04:43 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > >> I re-read again 4741bis-04 and I think it's fine with one exception: >> Either the EOM issue must be fixed in 4742bis or 4741bis should not >> require it as the mandatory transport protocol. > > We discussed this several times and came several times to the > same conclusion. > A comprehensive solution would be needed to address the issue > restlessly. However, this would cause a V2.0 and it'll be > incompatible with V1.0. > > By our charter 4741bis and 4742bis do not have the mandate for > V2.0(!). > Therefore we decided to keep the current solution and describe > the possible security thread unmistakably. > > Good or bad, IIRC this is the factual report of the situation. > thanks. Since ]]>]]> is not special in BEEP (for example), text about it does not belong in 4741bis. It is fine to say that a NETCONF client that sends ]]>]]> as content is broken. For any YANG content that may contain ]]>]]> unintentionally, the YANG 'binary' data type should be used, since XML element content does not allow ]]>]]>. We have NACM in the works to control what a session can do once it is authenticated, to address most data injection attacks. The only real exposure in the standard are the client-provided XML attributes that the server must return in the . Since the client controls this, the rule in 4742bis (MUST NOT send ]]>]]>) is sufficient to solve the problem. > Cheers, > Mehmet Andy > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of ext Ladislav Lhotka >> Sent: Thursday, October 07, 2010 1:03 PM >> To: Bert (IETF) Wijnen; Netconf >> Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended > for:draft- >> ietf-netconf-4741bis-04.txt >> >> Hi, >> >> I hope it's not too late: >> >> I re-read again 4741bis-04 and I think it's fine with one exception: >> Either the EOM issue must be fixed in 4742bis or 4741bis should not >> require it as the mandatory transport protocol. >> >> Other comments: >> >> 1. Sec. 1.2: List item 2 refers to [8], which is the partial lock >> RFC. Instead, it should refer to RFC 5277 (notifications). >> >> 2. Sec. 1.3: The base NETCONF specification also corresponds to a >> capability, namely :base. >> >> OLD >> >> A NETCONF capability is a set of functionality that supplements the >> base NETCONF specification. >> >> NEW >> >> A NETCONF capability is an identified set of functionality. >> >> 3. Sec. 3: >> >> "All NETCONF messages MUST be well-formed XML, encoded in UTF-8." >> >> It should be clarified what this requirement means. My > understanding >> is that PDUs exchanged between the client and server MUST contain >> well-formed messages. >> >> 4. Sec. 4.1: >> >> "If additional attributes are present in an element, a > NETCONF >> peer MUST return them unmodified in the element. This >> includes any "xmlns" attributes." >> >> I think the requirement on "xmlns" attributes is quite >> problematic. These attributes have a very specific function, so if >> the server uses another prefixes or another default namespace, why >> should it send the "xmlns" attributes received in the RPC request? >> >> The client could thus pre-empt a prefix the server normally uses, >> e.g. by sending xmlns:nc="http://example.com/foo". >> >> 5. Sec. 5.2, 7.2 and elsewhere: >> >> I think it would be better to indicate the namespace in the names > of >> XML elements or attributes, if there is any, e.g. > rather >> than. This is especially important for attribute names >> because attributes with a non-null namespace URI are not common. >> >> 6. Sec. 6.2.5, fourth bullet on p. 26: >> >> "If any sibling nodes of the selection node are instance identifier >> components for a conceptual data structure (e.g., list key leaf), >> then they MAY also be included in the filter output." >> >> I don't understand what this means. Is it that the subtree pointed >> to >> by the instance indentifier may be included? >> >> 7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge >> operation may be ambiguous. In the example on p. 43, if the >> "running" >> datastore contained two interfaces >> >> >> Ethernet0/0 >> 9216 >> >> >> Ethernet0/1 >> 1500 >> >> >> the edit-config operation could mean two things: either change > >> of the first interface or change of the other. >> >> 8. Sec. 7.5, p. 49: >> >> s/A lock MUST not/A lock MUST NOT/ >> >> 9. Sec. 8.1: >> >> "Each peer sends its element simultaneously ..." >> >> Why "simultaneously"? Should it be removed or changed to >> "asynchronously"? >> >> 10. Sec. 8.3.1: >> >> "A operation may be performed at any time that causes the >> device's running configuration to be set to the value of the >> candidate configuration." >> >> What is the "value" of the candidate configuration? The first >> sentence in the next paragraph explains the operation correctly so >> this sentence could be removed. >> >> 11. Now that Appendix B declares itself as normative, I am wondering >> what object is supposed to be validated against the XSD schema. For >> example, the schema doesn't take into account the two variants of >> with different content model: server's must have >> exactly one session-id attribute whereas client's must not >> have it at all. The XSD has a content model that is correct neither >> for the server nor for the client: >> >> > type="SessionId" minOccurs="0"/> >> >> Lada >> >> On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" >> wrote: >>> It was pointed out to me that we did not get ANY comments to this >> WGLC. >>> Well, there was continued discussion on XML parse errors (which is >>> related partly to this document) on which we will come back > tomorrow. >>> >>> But no other comments, Also not any " I read it, go ahead to the > next >> step". >>> >>> Can the WG chairs assume that people have indeed read the latest >> version >>> of this document and are OK with it? >>> >>> Can you please ASAP tell us: I read the doc and I am fine with it!!! >>> >>> PLEASE >>> >>> Bert and Mehmet >>> >>> On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: >>>> WG participants, this email starts a formal WG Last Call for >> revision 4 >>>> of the 4741bis document. The document is targeted as Proposed >> Standard >>>> to replace the current rfc4741. >>>> >>>> Please do review and tell us your position and comments. >>>> Please do so BEFORE 20 September 2010. >>>> >>>> Bert and Mehmet >>>> >>>> ----- Original Message ----- >>>> From: >>>> To: >>>> Cc: >>>> Sent: Monday, August 23, 2010 7:00 PM >>>> Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt >>>> >>>> >>>> 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-04.txt >>>> Pages : 121 >>>> Date : 2010-08-23 >>>> >>>> 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- >> 04.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 stone@openclovis.com Thu Oct 7 08:44:58 2010 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 A0D743A6EE5 for ; Thu, 7 Oct 2010 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=2.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 5CQdehs7cdq9 for ; Thu, 7 Oct 2010 08:44:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4D9743A6E12 for ; Thu, 7 Oct 2010 08:44:56 -0700 (PDT) Received: by iwn10 with SMTP id 10so1292930iwn.31 for ; Thu, 07 Oct 2010 08:45:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.72 with SMTP id l8mr1035633iby.95.1286466358621; Thu, 07 Oct 2010 08:45:58 -0700 (PDT) Received: by 10.231.37.68 with HTTP; Thu, 7 Oct 2010 08:45:58 -0700 (PDT) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> Date: Thu, 7 Oct 2010 11:45:58 -0400 Message-ID: From: Andrew Stone To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=005045013e1b523507049208ca4f Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 15:44:58 -0000 --005045013e1b523507049208ca4f Content-Type: text/plain; charset=ISO-8859-1 "A NETCONF message MAY begin with an XML declaration (see section 2.8 of [1 ])." Since the XML declaration is optional, shall we clarify which version of XML must be used if the declaration is NOT included? And perhaps require that servers handle all XML versions (1.0 and 1.1) following the protocol design philosophy that "receivers" should be generous in what they accept? If we do not require this, we could get clients that can't communicate with servers because the client sends XML ver 1.1 (say) and the server only accepts 1.0. Or just keep it simple and require that all NETCONF messages be XML version 1.1. Regards, Andrew On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Dear NETCONF Members, > > I hope this mail motivates the Netconf community to > comment or raises at least some discussion on the > content of 4741bis. > > As you know 4741bis is the base protocol document > for NETCONF. Please comment on the 4741bis draft. > It would be actually sufficient to say: "I read it > and it is ready to ship." > > > [Co-chair hat off] > > I had read the document but read again. > I couldn't find any serious issues and I think it is > ready for publication though I have a few suggestions > to make it more consistent and to improve the clarity > as a standard-track document. > > > Section 1.1. Terminology > > I would suggest to bring the terms client/manager/ > application vs. agent/server/device as early as > possible into relation. The document mainly avoids > the usage of the terms manager and agent though > there are some leftovers. > > OLD: > client: A client invokes protocol operations on a server. > NEW: > client: A client (manager, application) invokes > protocol operations on a server (agent, device). > > OLD: > server: A server executes protocol operations invoked by a client. > NEW: > server: A server (agent, device) executes protocol > operations invoked by a client (manager, application). > > > Section 1.2. Protocol Overview > > To get it consistent with the rest of the document it would > be good to use only singular for layer titles. > > s/Operations/Operation/ > s/Messages/Message/ > s/Secure Transports/Secure Transport/ > s/The Messages layer/The Message layer/ > s/The Operations layer/The Operation layer/ > > > Section 1.4. Separation of Configuration and State Data > > OLD: > For example, if a local database of user authentication data is > stored on the device, it is an implementation-dependent matter > whether it is included in configuration data. > NEW: > For example, if a local database of user authentication data is > stored on the device, it is implementation-dependent, whether > it is included in configuration data. > > > Section 3. XML Considerations > > Concerning the mail-thread on "how to handle XML parse > errors" I agree with the last proposed text. > > OLD: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > NEW: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > If a server receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. > > A few sentences on this issue should be added to > the security considerations section (see below). > > > Section 3.2. No Document Type Declarations > > The title sounds like a command. > Change to "Document Type Declarations". > > > Section 4.3. Element > > s/layer: Messages/layer: Message/ > s/layer: Operations/layer: Operation/ > > > Section 5.2. Data Modeling > > "Devices and managers may support multiple data models, ..." > > s/managers/applications/ > > > Section 7.5. > > To differentiate from Partial Lock RFC clearly, I would > underline that the operation is on the entire configuration > datastore. > > OLD: > The lock operation allows the client to lock the configuration > system of a device. > NEW: > The lock operation allows the client to lock an entire configuration > datastore of a server. > > I also would suggest to keep using the term "configuration > datastore" instead of "configuration", which is used in other > parts of the document to mean a specific part of the > configuration of a datastore. > > E.g. > "An attempt to lock the configuration datastore MUST..." > "The target configuration datastore is ,..." > "The target parameter names the configuration datastore that will be > locked." > > Sec. 1.1. says: > "session: Client and server exchange messages using a secure, > connection-oriented session." > > Sec. 2.1. Connection-Oriented Operation says: > "For example, when a lock is acquired by a client, the lock > persists until either it is explicitly released or the server > determines that the connection has been terminated." > > Sec. 2.3. Authentication says: > "The access permissions of a given client, identified by its > NETCONF username, are part of the configuration of the NETCONF > server. These permissions MUST be enforced during the remainder > of the NETCONF session." > > Sec. 7.5 says: > "The operation can be used to force the > release of a lock owned by another NETCONF session." > > How a client can release a lock which is owned by another > session needs to be elaborated. E.g. Partial Lock RFC says: > "If needed, the returned session-id may be used to the > NETCONF session holding the lock." > > I actually would suggest to delete this sentence in section 7.5. > and stick to the statement in section 2.1. > > > Section 7.7. > > "filter: > This parameter specifies the portion of the system > configuration and state data to retrieve. If this parameter is > not present, all the device configuration and state information > is returned." > > For the sake of completeness I would add what happens > if the filter parameter is available but empty. > > > Section 8.4.1. Description > > s/configuration, /configuration. / > > > Section 8.4.1. Description and 8.6.1. Description > > OLD: > The current version is 1.1, and is defined in this document. It > extends... > NEW: > The version 1.1 is defined in this document and extends... > > > Section 12.2. Informative References > > Add draft-ietf-netmod-yang-usage-11 as informative reference. > > > Section 9. Security Considerations > > I would suggest to add a few sentences for the EOM handling > and the possible thread concerning section 3. It would be > interesting to recommend a possible reaction if this happens > frequently, e.g. to drop the NETCONF session. > > > Appendix B. XML Schema for NETCONF Messages Layer > > s/XML Schema for NETCONF Messages Layer/ > XML Schema for NETCONF Message Layer/ > > > Cheers, > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of ext Bert (IETF) Wijnen > > Sent: Thursday, September 23, 2010 1:48 PM > > To: Netconf > > Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > > ietf-netconf-4741bis-04.txt > > > > > > It was pointed out to me that we did not get ANY comments to this > > WGLC. > > Well, there was continued discussion on XML parse errors (which is > > related partly to this document) on which we will come back tomorrow. > > > > But no other comments, Also not any " I read it, go ahead to the next > > step". > > > > Can the WG chairs assume that people have indeed read the latest > > version > > of this document and are OK with it? > > > > Can you please ASAP tell us: I read the doc and I am fine with it!!! > > > > PLEASE > > > > Bert and Mehmet > > > > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > > WG participants, this email starts a formal WG Last Call for > revision > > 4 > > > of the 4741bis document. The document is targeted as Proposed > > Standard > > > to replace the current rfc4741. > > > > > > Please do review and tell us your position and comments. > > > Please do so BEFORE 20 September 2010. > > > > > > Bert and Mehmet > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Monday, August 23, 2010 7:00 PM > > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > > > > 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-04.txt > > > Pages : 121 > > > Date : 2010-08-23 > > > > > > 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-04.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --005045013e1b523507049208ca4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
"A NETCONF message MAY begin with an XML declar=
ation (see section 2.8 of [1])."
S= ince the XML declaration is optional, shall we clarify which version of XML= must be used if the declaration is NOT included?

And perhaps requir= e that servers handle all XML versions (1.0 and 1.1) following the protocol= design philosophy that "receivers" should be generous in what th= ey accept?=A0 If we do not require this, we could get clients that can'= t communicate with servers because the client sends XML ver 1.1 (say) and t= he server only accepts 1.0.

Or just keep it simple and require that all NETCONF messages be XML ver= sion 1.1.

Regards,
Andrew


O= n Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com&= gt; wrote:
Dear NETCONF Memb= ers,

I hope this mail motivates the Netconf community to
comment or raises at least some discussion on the
content of 4741bis.

As you know 4741bis is the base protocol document
for NETCONF. Please comment on the 4741bis draft.
It would be actually sufficient to say: "I read it
and it is ready to ship."


[Co-chair hat off]

I had read the document but read again.
I couldn't find any serious issues and I think it is
ready for publication though I have a few suggestions
to make it more consistent and to improve the clarity
as a standard-track document.


Section 1.1. Terminology

I would suggest to bring the terms client/manager/
application vs. agent/server/device as early as
possible into relation. The document mainly avoids
the usage of the terms manager and agent though
there are some leftovers.

OLD:
=A0 client: A client invokes protocol operations on a server.
NEW:
=A0 client: A client (manager, application) invokes
=A0 protocol operations on a server (agent, device).

OLD:
=A0 server: A server executes protocol operations invoked by a client.
NEW:
=A0 server: A server (agent, device) executes protocol
=A0 operations invoked by a client (manager, application).


Section 1.2. Protocol Overview

To get it consistent with the rest of the document it would
be good to use only singular for layer titles.

s/Operations/Operation/
s/Messages/Message/
s/Secure Transports/Secure Transport/
s/The Messages layer/The Message layer/
s/The Operations layer/The Operation layer/


Section 1.4. Separation of Configuration and State Data

OLD:
=A0 For example, if a local database of user authentication data is
=A0 stored on the device, it is an implementation-dependent matter
=A0 whether it is included in configuration data.
NEW:
=A0 For example, if a local database of user authentication data is
=A0 stored on the device, it is implementation-dependent, whether
=A0 it is included in configuration data.


Section 3. XML Considerations

Concerning the mail-thread on "how to handle XML parse
errors" I agree with the last proposed text.

OLD:
=A0 All NETCONF messages MUST be well-formed XML, encoded in UTF-8.

NEW:
=A0 All NETCONF messages MUST be well-formed XML, encoded in UTF-8.
=A0 If a server receives a message that is not well-formed XML, it MUST =A0 reply with an 'operation-failed' error.

A few sentences on this issue should be added to
the security considerations section (see below).


Section 3.2. No Document Type Declarations

The title sounds like a command.
Change to "Document Type Declarations".


Section 4.3. <rpc-error> Element

s/layer: Messages/layer: Message/
s/layer: Operations/layer: Operation/


Section 5.2. Data Modeling

"Devices and managers may support multiple data models, ..."

s/managers/applications/


Section 7.5. <lock>

To differentiate from Partial Lock RFC clearly, I would
underline that the operation is on the entire configuration
datastore.

OLD:
=A0 The lock operation allows the client to lock the configuration
=A0 system of a device.
NEW:
=A0 The lock operation allows the client to lock an entire configuration =A0 datastore of a server.

I also would suggest to keep using the term "configuration
datastore" instead of "configuration", which is used in othe= r
parts of the document to mean a specific part of the
configuration of a datastore.

E.g.
"An attempt to lock the configuration datastore MUST..."
"The target configuration datastore is <candidate>,..."
"The target parameter names the configuration datastore that will be locked."

Sec. 1.1. says:
"session: Client and server exchange messages using a secure,
connection-oriented session."

Sec. 2.1. Connection-Oriented Operation says:
"For example, when a lock is acquired by a client, the lock
persists until either it is explicitly released or the server
determines that the connection has been terminated."

Sec. 2.3. Authentication says:
"The access permissions of a given client, identified by its
NETCONF username, are part of the configuration of the NETCONF
server. These permissions MUST be enforced during the remainder
of the NETCONF session."

Sec. 7.5 says:
"The <kill-session> operation can be used to force the
release of a lock owned by another NETCONF session."

How a client can release a lock which is owned by another
session needs to be elaborated. E.g. Partial Lock RFC says:
"If needed, the returned session-id may be used to <kill-session>= ; the
NETCONF session holding the lock."

I actually would suggest to delete this sentence in section 7.5.
and stick to the statement in section 2.1.


Section 7.7. <get>

"filter:
=A0 This parameter specifies the portion of the system
=A0 configuration and state data to retrieve. =A0If this parameter is
=A0 not present, all the device configuration and state information
=A0 is returned."

For the sake of completeness I would add what happens
if the filter parameter is available but empty.


Section 8.4.1. Description

s/configuration, /configuration. /


Section 8.4.1. Description and 8.6.1. Description

OLD:
=A0 The current version is 1.1, and is defined in this document. It
extends...
NEW:
=A0 The version 1.1 is defined in this document and extends...


Section 12.2. Informative References

Add draft-ietf-netmod-yang-usage-11 as informative reference.


Section 9. Security Considerations

I would suggest to add a few sentences for the EOM handling
and the possible thread concerning section 3. It would be
interesting to recommend a possible reaction if this happens
frequently, e.g. to drop the NETCONF session.


Appendix B. XML Schema for NETCONF Messages Layer

s/XML Schema for NETCONF Messages Layer/
XML Schema for NETCONF Message Layer/


Cheers,
Mehmet


> -----Original Message-----
> From: netconf-bounces@ietf= .org [mailto:netconf-bounce= s@ietf.org] On
> Behalf Of ext Bert (IETF) Wijnen
> Sent: Thursday, September 23, 2010 1:48 PM
> To: Netconf
> Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > ietf-netconf-4741bis-04.txt
>
>
> =A0 It was pointed out to me that we did not get ANY comments to this<= br> > WGLC.
> Well, there was continued discussion on XML parse errors (which is
> related partly to this document) on which we will come back tomorrow.<= br> >
> But no other comments, Also not any " I read it, go ahead to the = next
> step".
>
> Can the WG chairs assume that people have indeed read the latest
> version
> of this document and are OK with it?
>
> Can you please ASAP tell us: I read the doc and I am fine with it!!! >
> PLEASE
>
> Bert and Mehmet
>
> On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote:
> > WG participants, this email starts a formal WG Last Call for
revision
> 4
> > of the 4741bis document. The document is targeted as Proposed
> Standard
> > to replace the current rfc4741.
> >
> > Please do review and tell us your position and comments.
> > Please do so BEFORE 20 September 2010.
> >
> > Bert and Mehmet
> >
> > ----- Original Message -----
> > From:<Internet-Dra= fts@ietf.org>
> > To:<i-d-announce@ietf= .org>
> > Cc:<netconf@ietf.org&g= t;
> > Sent: Monday, August 23, 2010 7:00 PM
> > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> > directories.
> > This draft is a work item of the Network Configuration Working Gr= oup
> of the
> > IETF.
> >
> >
> > Title =A0 =A0 =A0 =A0 =A0 : Network Configuration Protocol (NETCO= NF)
> > Author(s) =A0 =A0 =A0 : R. Enns, et al.
> > Filename =A0 =A0 =A0 =A0: draft-ietf-netconf-4741bis-04.txt
> > Pages =A0 =A0 =A0 =A0 =A0 : 121
> > Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-08-23
> >
> > The Network Configuration Protocol (NETCONF) defined in this
document
> > provides mechanisms to install, manipulate, and delete the
> > configuration of network devices. =A0It uses an Extensible Markup=
> > Language (XML)-based data encoding for the configuration data as<= br> well
> > as the protocol messages. =A0The NETCONF protocol operations are<= br> > > realized as Remote Procedure Calls (RPC).
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-net= conf-4741bis-04.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--005045013e1b523507049208ca4f-- From ietf@andybierman.com Thu Oct 7 09:11:46 2010 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 CE4593A6E6D for ; Thu, 7 Oct 2010 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 4K3ClK5QNu8o for ; Thu, 7 Oct 2010 09:11:44 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ne1.yahoo.com (nm4-vm0.bullet.mail.ne1.yahoo.com [98.138.90.253]) by core3.amsl.com (Postfix) with SMTP id 428A43A6CE4 for ; Thu, 7 Oct 2010 09:11:44 -0700 (PDT) Received: from [98.138.90.52] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000 Received: from [98.138.89.164] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000 X-Yahoo-Newman-Id: 279209.89080.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 13663 invoked from network); 7 Oct 2010 16:12:46 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 07 Oct 2010 09:12:45 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8zLyR0cVM1lWLRrQ5sxMoBYugObh7mP6kdZWLZLKQB.aumH 4o9vtzy8hFN3Cyk3QUdHn9yO6w.G8tZvJ.wdmA2.ZwScIXTJiJ32SQdwrPQr GJeHOOOgzYvDMUmArmszC6kyYdeOqnK.kJ.ita1q.2jIhg5dgJsOVS8GarIk UEGj54k4fkf6bqrFEihgMNcmK1kU1N8ZwuCj8C27cAWnQXB68BJkJibfs4l6 OCUJ34mhosJQ64JGH5oAK_JU5Jj7uM.haPwgx.7VJDrPmvIeUyzsNbU3Nyn3 yD0A2qZ_O2g.Rtcr6U_s9tJF9Xtpm.Krf2EXK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CADF17D.4030207@andybierman.com> Date: Thu, 07 Oct 2010 09:12:45 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Andrew Stone References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 16:11:46 -0000 On 10/07/2010 08:45 AM, Andrew Stone wrote: > "A NETCONF message MAY begin with an XML declaration (see section 2.8 of [1 ])." > > > Since the XML declaration is optional, shall we clarify which version of > XML must be used if the declaration is NOT included? > > And perhaps require that servers handle all XML versions (1.0 and 1.1) > following the protocol design philosophy that "receivers" should be > generous in what they accept? If we do not require this, we could get > clients that can't communicate with servers because the client sends XML > ver 1.1 (say) and the server only accepts 1.0. > > Or just keep it simple and require that all NETCONF messages be XML > version 1.1. I sort of object to this change. (3/4 objection?) It would be OK to say a server MUST support 1.0 and SHOULD or MAY support 1.1. It seems like the version MUST be present if a server is required to support multiple versions of XML. > > Regards, > Andrew Andy > > > On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > Dear NETCONF Members, > > I hope this mail motivates the Netconf community to > comment or raises at least some discussion on the > content of 4741bis. > > As you know 4741bis is the base protocol document > for NETCONF. Please comment on the 4741bis draft. > It would be actually sufficient to say: "I read it > and it is ready to ship." > > > [Co-chair hat off] > > I had read the document but read again. > I couldn't find any serious issues and I think it is > ready for publication though I have a few suggestions > to make it more consistent and to improve the clarity > as a standard-track document. > > > Section 1.1. Terminology > > I would suggest to bring the terms client/manager/ > application vs. agent/server/device as early as > possible into relation. The document mainly avoids > the usage of the terms manager and agent though > there are some leftovers. > > OLD: > client: A client invokes protocol operations on a server. > NEW: > client: A client (manager, application) invokes > protocol operations on a server (agent, device). > > OLD: > server: A server executes protocol operations invoked by a client. > NEW: > server: A server (agent, device) executes protocol > operations invoked by a client (manager, application). > > > Section 1.2. Protocol Overview > > To get it consistent with the rest of the document it would > be good to use only singular for layer titles. > > s/Operations/Operation/ > s/Messages/Message/ > s/Secure Transports/Secure Transport/ > s/The Messages layer/The Message layer/ > s/The Operations layer/The Operation layer/ > > > Section 1.4. Separation of Configuration and State Data > > OLD: > For example, if a local database of user authentication data is > stored on the device, it is an implementation-dependent matter > whether it is included in configuration data. > NEW: > For example, if a local database of user authentication data is > stored on the device, it is implementation-dependent, whether > it is included in configuration data. > > > Section 3. XML Considerations > > Concerning the mail-thread on "how to handle XML parse > errors" I agree with the last proposed text. > > OLD: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > NEW: > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > If a server receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. > > A few sentences on this issue should be added to > the security considerations section (see below). > > > Section 3.2. No Document Type Declarations > > The title sounds like a command. > Change to "Document Type Declarations". > > > Section 4.3. Element > > s/layer: Messages/layer: Message/ > s/layer: Operations/layer: Operation/ > > > Section 5.2. Data Modeling > > "Devices and managers may support multiple data models, ..." > > s/managers/applications/ > > > Section 7.5. > > To differentiate from Partial Lock RFC clearly, I would > underline that the operation is on the entire configuration > datastore. > > OLD: > The lock operation allows the client to lock the configuration > system of a device. > NEW: > The lock operation allows the client to lock an entire configuration > datastore of a server. > > I also would suggest to keep using the term "configuration > datastore" instead of "configuration", which is used in other > parts of the document to mean a specific part of the > configuration of a datastore. > > E.g. > "An attempt to lock the configuration datastore MUST..." > "The target configuration datastore is ,..." > "The target parameter names the configuration datastore that will be > locked." > > Sec. 1.1. says: > "session: Client and server exchange messages using a secure, > connection-oriented session." > > Sec. 2.1. Connection-Oriented Operation says: > "For example, when a lock is acquired by a client, the lock > persists until either it is explicitly released or the server > determines that the connection has been terminated." > > Sec. 2.3. Authentication says: > "The access permissions of a given client, identified by its > NETCONF username, are part of the configuration of the NETCONF > server. These permissions MUST be enforced during the remainder > of the NETCONF session." > > Sec. 7.5 says: > "The operation can be used to force the > release of a lock owned by another NETCONF session." > > How a client can release a lock which is owned by another > session needs to be elaborated. E.g. Partial Lock RFC says: > "If needed, the returned session-id may be used to the > NETCONF session holding the lock." > > I actually would suggest to delete this sentence in section 7.5. > and stick to the statement in section 2.1. > > > Section 7.7. > > "filter: > This parameter specifies the portion of the system > configuration and state data to retrieve. If this parameter is > not present, all the device configuration and state information > is returned." > > For the sake of completeness I would add what happens > if the filter parameter is available but empty. > > > Section 8.4.1. Description > > s/configuration, /configuration. / > > > Section 8.4.1. Description and 8.6.1. Description > > OLD: > The current version is 1.1, and is defined in this document. It > extends... > NEW: > The version 1.1 is defined in this document and extends... > > > Section 12.2. Informative References > > Add draft-ietf-netmod-yang-usage-11 as informative reference. > > > Section 9. Security Considerations > > I would suggest to add a few sentences for the EOM handling > and the possible thread concerning section 3. It would be > interesting to recommend a possible reaction if this happens > frequently, e.g. to drop the NETCONF session. > > > Appendix B. XML Schema for NETCONF Messages Layer > > s/XML Schema for NETCONF Messages Layer/ > XML Schema for NETCONF Message Layer/ > > > Cheers, > Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org ] On > > Behalf Of ext Bert (IETF) Wijnen > > Sent: Thursday, September 23, 2010 1:48 PM > > To: Netconf > > Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- > > ietf-netconf-4741bis-04.txt > > > > > > It was pointed out to me that we did not get ANY comments to this > > WGLC. > > Well, there was continued discussion on XML parse errors (which is > > related partly to this document) on which we will come back tomorrow. > > > > But no other comments, Also not any " I read it, go ahead to the next > > step". > > > > Can the WG chairs assume that people have indeed read the latest > > version > > of this document and are OK with it? > > > > Can you please ASAP tell us: I read the doc and I am fine with it!!! > > > > PLEASE > > > > Bert and Mehmet > > > > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > > > WG participants, this email starts a formal WG Last Call for > revision > > 4 > > > of the 4741bis document. The document is targeted as Proposed > > Standard > > > to replace the current rfc4741. > > > > > > Please do review and tell us your position and comments. > > > Please do so BEFORE 20 September 2010. > > > > > > Bert and Mehmet > > > > > > ----- Original Message ----- > > > From:> > > > To:> > > > Cc:> > > > Sent: Monday, August 23, 2010 7:00 PM > > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > > > > > > > > > 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-04.txt > > > Pages : 121 > > > Date : 2010-08-23 > > > > > > 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-04.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 Thu Oct 7 09:16:39 2010 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 BEE7C3A6FA6 for ; Thu, 7 Oct 2010 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 bS7Y5a-g2oxw for ; Thu, 7 Oct 2010 09:16:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AE7423A7075 for ; Thu, 7 Oct 2010 09:16:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o97GHZpS021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 18:17:35 +0200 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 o97GHW6P010888; Thu, 7 Oct 2010 18:17:35 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 18:17:36 +0200 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: Thu, 7 Oct 2010 18:17:32 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010D98EE@DEMUEXC006.nsn-intra.net> In-Reply-To: <4CADE324.5090307@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt Thread-Index: ActmMe+39qk0KIVQSdqCDdHSQ3vEPQABvg3w References: <4C9B3E60.5030000@bwijnen.net> <87r5g21d05.fsf@cesnet.cz> <80A0822C5E9A4440A5117C2F4CD36A64010D95FF@DEMUEXC006.nsn-intra.net> <4CADE324.5090307@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 07 Oct 2010 16:17:36.0065 (UTC) FILETIME=[276B7B10:01CB663B] Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 16:16:40 -0000 > From: ext Andy Bierman [mailto:ietf@andybierman.com] > On 10/07/2010 04:43 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Lada, > > > >> I re-read again 4741bis-04 and I think it's fine with one exception: > >> Either the EOM issue must be fixed in 4742bis or 4741bis should not > >> require it as the mandatory transport protocol. > > > > We discussed this several times and came several times to the > > same conclusion. > > A comprehensive solution would be needed to address the issue > > restlessly. However, this would cause a V2.0 and it'll be > > incompatible with V1.0. > > > > By our charter 4741bis and 4742bis do not have the mandate for > > V2.0(!). > > Therefore we decided to keep the current solution and describe > > the possible security thread unmistakably. > > > > Good or bad, IIRC this is the factual report of the situation. > > >=20 > thanks. > Since ]]>]]> is not special in BEEP (for example), text about it does > not > belong in 4741bis. Yes. =20 > It is fine to say that a NETCONF client that sends ]]>]]> as content is > broken. This is clearly stated in 4742bis. =20 > For any YANG content that may contain ]]>]]> unintentionally, the YANG > 'binary' data type > should be used, since XML element content does not allow ]]>]]>. I am not sure whether this belongs to 4742bis but this can be=20 added as appropriate. =20 > We have NACM in the works to control what a session can do once it is > authenticated, > to address most data injection attacks. >=20 > The only real exposure in the standard are the client-provided XML > attributes that > the server must return in the . Since the client controls > this, the rule > in 4742bis (MUST NOT send ]]>]]>) is sufficient to solve the problem. >=20 > > Cheers, > > Mehmet >=20 > Andy ME/> =20 >=20 > > > > > >> -----Original Message----- > >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >> Behalf Of ext Ladislav Lhotka > >> Sent: Thursday, October 07, 2010 1:03 PM > >> To: Bert (IETF) Wijnen; Netconf > >> Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended > > for:draft- > >> ietf-netconf-4741bis-04.txt > >> > >> Hi, > >> > >> I hope it's not too late: > >> > >> I re-read again 4741bis-04 and I think it's fine with one exception: > >> Either the EOM issue must be fixed in 4742bis or 4741bis should not > >> require it as the mandatory transport protocol. > >> > >> Other comments: > >> > >> 1. Sec. 1.2: List item 2 refers to [8], which is the partial lock > >> RFC. Instead, it should refer to RFC 5277 (notifications). > >> > >> 2. Sec. 1.3: The base NETCONF specification also corresponds to a > >> capability, namely :base. > >> > >> OLD > >> > >> A NETCONF capability is a set of functionality that supplements > the > >> base NETCONF specification. > >> > >> NEW > >> > >> A NETCONF capability is an identified set of functionality. > >> > >> 3. Sec. 3: > >> > >> "All NETCONF messages MUST be well-formed XML, encoded in UTF- > 8." > >> > >> It should be clarified what this requirement means. My > > understanding > >> is that PDUs exchanged between the client and server MUST > contain > >> well-formed messages. > >> > >> 4. Sec. 4.1: > >> > >> "If additional attributes are present in an element, a > > NETCONF > >> peer MUST return them unmodified in the element. > This > >> includes any "xmlns" attributes." > >> > >> I think the requirement on "xmlns" attributes is quite > >> problematic. These attributes have a very specific function, so > if > >> the server uses another prefixes or another default namespace, > why > >> should it send the "xmlns" attributes received in the RPC > request? > >> > >> The client could thus pre-empt a prefix the server normally > uses, > >> e.g. by sending xmlns:nc=3D"http://example.com/foo". > >> > >> 5. Sec. 5.2, 7.2 and elsewhere: > >> > >> I think it would be better to indicate the namespace in the > names > > of > >> XML elements or attributes, if there is any, e.g. > > rather > >> than. This is especially important for attribute names > >> because attributes with a non-null namespace URI are not common. > >> > >> 6. Sec. 6.2.5, fourth bullet on p. 26: > >> > >> "If any sibling nodes of the selection node are instance > identifier > >> components for a conceptual data structure (e.g., list key > leaf), > >> then they MAY also be included in the filter output." > >> > >> I don't understand what this means. Is it that the subtree > pointed > >> to > >> by the instance indentifier may be included? > >> > >> 7. Sec. 7.2: Without the notion of (mandatory) list keys, the merge > >> operation may be ambiguous. In the example on p. 43, if the > >> "running" > >> datastore contained two interfaces > >> > >> > >> Ethernet0/0 > >> 9216 > >> > >> > >> Ethernet0/1 > >> 1500 > >> > >> > >> the edit-config operation could mean two things: either change > > > >> of the first interface or change of the other. > >> > >> 8. Sec. 7.5, p. 49: > >> > >> s/A lock MUST not/A lock MUST NOT/ > >> > >> 9. Sec. 8.1: > >> > >> "Each peer sends its element simultaneously ..." > >> > >> Why "simultaneously"? Should it be removed or changed to > >> "asynchronously"? > >> > >> 10. Sec. 8.3.1: > >> > >> "A operation may be performed at any time that causes > the > >> device's running configuration to be set to the value of the > >> candidate configuration." > >> > >> What is the "value" of the candidate configuration? The first > >> sentence in the next paragraph explains the operation correctly > so > >> this sentence could be removed. > >> > >> 11. Now that Appendix B declares itself as normative, I am wondering > >> what object is supposed to be validated against the XSD schema. > For > >> example, the schema doesn't take into account the two variants > of > >> with different content model: server's must > have > >> exactly one session-id attribute whereas client's must > not > >> have it at all. The XSD has a content model that is correct > neither > >> for the server nor for the client: > >> > >> >> type=3D"SessionId" minOccurs=3D"0"/> > >> > >> Lada > >> > >> On Thu, 23 Sep 2010 13:47:44 +0200, "Bert (IETF) Wijnen" > >> wrote: > >>> It was pointed out to me that we did not get ANY comments to > this > >> WGLC. > >>> Well, there was continued discussion on XML parse errors (which is > >>> related partly to this document) on which we will come back > > tomorrow. > >>> > >>> But no other comments, Also not any " I read it, go ahead to the > > next > >> step". > >>> > >>> Can the WG chairs assume that people have indeed read the latest > >> version > >>> of this document and are OK with it? > >>> > >>> Can you please ASAP tell us: I read the doc and I am fine with > it!!! > >>> > >>> PLEASE > >>> > >>> Bert and Mehmet > >>> > >>> On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: > >>>> WG participants, this email starts a formal WG Last Call for > >> revision 4 > >>>> of the 4741bis document. The document is targeted as Proposed > >> Standard > >>>> to replace the current rfc4741. > >>>> > >>>> Please do review and tell us your position and comments. > >>>> Please do so BEFORE 20 September 2010. > >>>> > >>>> Bert and Mehmet > >>>> > >>>> ----- Original Message ----- > >>>> From: > >>>> To: > >>>> Cc: > >>>> Sent: Monday, August 23, 2010 7:00 PM > >>>> Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt > >>>> > >>>> > >>>> 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-04.txt > >>>> Pages : 121 > >>>> Date : 2010-08-23 > >>>> > >>>> 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- > >> 04.txt > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> 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 > >> _______________________________________________ > >> 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 stone@openclovis.com Thu Oct 7 10:14:27 2010 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 15CAC3A7025 for ; Thu, 7 Oct 2010 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 e0LdNCvWFIxi for ; Thu, 7 Oct 2010 10:14:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2B2733A712D for ; Thu, 7 Oct 2010 10:14:24 -0700 (PDT) Received: by iwn10 with SMTP id 10so80470iwn.31 for ; Thu, 07 Oct 2010 10:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.168.21 with SMTP id s21mr1153661iby.123.1286471726666; Thu, 07 Oct 2010 10:15:26 -0700 (PDT) Received: by 10.231.37.68 with HTTP; Thu, 7 Oct 2010 10:15:26 -0700 (PDT) In-Reply-To: <4CADF17D.4030207@andybierman.com> References: <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <4CADF17D.4030207@andybierman.com> Date: Thu, 7 Oct 2010 13:15:26 -0400 Message-ID: From: Andrew Stone To: Andy Bierman Content-Type: multipart/alternative; boundary=001636c92e9c48137b04920a0acd Cc: Netconf Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.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: Thu, 07 Oct 2010 17:14:27 -0000 --001636c92e9c48137b04920a0acd Content-Type: text/plain; charset=ISO-8859-1 I'm not really advocating right now. Just pointing out a "hole" or "ambiguity" that could cause client/server communications issues and some possible solutions. And trying to raise awareness; if we want cross-vendor client/server compatibility this issue needs to be clarified. There does not seem to be a good way for the client/server to negotiate XML versions since the capabilities in the message is itself XML. Nor is there a good way to return an "XML version unsupported" error, both because there is no general catchall "error" message and also because the returned error would be in some version of XML itself and therefore potentially unreadable by the receiver. Note as a corollary, what to do with malformed XML seems undefined. So it seems like to achieve cross vendor compatibility we must either require that servers (or clients actually) handle all XML versions, or pick one version and REQUIRE it, or add some version negotiation messages. Some specific ideas. 1. Require that certain messages be XML 1.0 (hello with another "capabilities" tag describing the support XML versions), so can be understood by all servers. This is sort of a pain from a software perspective because a lot of XML 1.1 libraries automatically optimize to . 2. Require that servers try to parse using both formats (if it gets a parse error, try the other format) if the XML header is not there. But it would require analysis to show that this would result in provably correct behavior (i.e. no possible XML 1.1 string could be successfully parsed by XML 1.0 in a semantically different way, and vice versa). It also puts a computational and code size burden on servers, pushing NETCONF away from highly embedded devices -- XML is already very expensive to parse why make it worse? Of course a smart server could "learn" what the client is likely using. Is XML 1.1 a superset of XML 1.0 (I'm not positive but its definitely pretty close)? 3. Require that the "hello" message contain the XML declaration (containing the version), and assume that as the default for this session. Of course this also means that servers must be required to speak both XML versions (or we have to add an unsupported XML version error message), but at least the client is free to use whatever is convenient. 4. Drop the connection on parse error -- client side could then reconnect with a different XML version. But establishing connections is expensive and just dropping the connection is an ambiguous response -- the connection could be closed for many reasons, like server overload or idle timeout, or any other transport level issue. So I think this solution is not so good. Regards, Andrew On Thu, Oct 7, 2010 at 12:12 PM, Andy Bierman wrote: > On 10/07/2010 08:45 AM, Andrew Stone wrote: > >> "A NETCONF message MAY begin with an XML declaration (see section 2.8 of >> [1 ])." >> >> >> >> Since the XML declaration is optional, shall we clarify which version of >> XML must be used if the declaration is NOT included? >> >> And perhaps require that servers handle all XML versions (1.0 and 1.1) >> following the protocol design philosophy that "receivers" should be >> generous in what they accept? If we do not require this, we could get >> clients that can't communicate with servers because the client sends XML >> ver 1.1 (say) and the server only accepts 1.0. >> >> Or just keep it simple and require that all NETCONF messages be XML >> version 1.1. >> > > > I sort of object to this change. (3/4 objection?) > > It would be OK to say a server MUST support 1.0 and SHOULD or MAY support > 1.1. > It seems like the version MUST be present if a server is required to > support > multiple versions of XML. > > > >> Regards, >> Andrew >> > > > Andy > > > >> >> On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich) >> > wrote: >> >> Dear NETCONF Members, >> >> I hope this mail motivates the Netconf community to >> comment or raises at least some discussion on the >> content of 4741bis. >> >> As you know 4741bis is the base protocol document >> for NETCONF. Please comment on the 4741bis draft. >> It would be actually sufficient to say: "I read it >> and it is ready to ship." >> >> >> [Co-chair hat off] >> >> I had read the document but read again. >> I couldn't find any serious issues and I think it is >> ready for publication though I have a few suggestions >> to make it more consistent and to improve the clarity >> as a standard-track document. >> >> >> Section 1.1. Terminology >> >> I would suggest to bring the terms client/manager/ >> application vs. agent/server/device as early as >> possible into relation. The document mainly avoids >> the usage of the terms manager and agent though >> there are some leftovers. >> >> OLD: >> client: A client invokes protocol operations on a server. >> NEW: >> client: A client (manager, application) invokes >> protocol operations on a server (agent, device). >> >> OLD: >> server: A server executes protocol operations invoked by a client. >> NEW: >> server: A server (agent, device) executes protocol >> operations invoked by a client (manager, application). >> >> >> Section 1.2. Protocol Overview >> >> To get it consistent with the rest of the document it would >> be good to use only singular for layer titles. >> >> s/Operations/Operation/ >> s/Messages/Message/ >> s/Secure Transports/Secure Transport/ >> s/The Messages layer/The Message layer/ >> s/The Operations layer/The Operation layer/ >> >> >> Section 1.4. Separation of Configuration and State Data >> >> OLD: >> For example, if a local database of user authentication data is >> stored on the device, it is an implementation-dependent matter >> whether it is included in configuration data. >> NEW: >> For example, if a local database of user authentication data is >> stored on the device, it is implementation-dependent, whether >> it is included in configuration data. >> >> >> Section 3. XML Considerations >> >> Concerning the mail-thread on "how to handle XML parse >> errors" I agree with the last proposed text. >> >> OLD: >> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. >> >> NEW: >> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. >> If a server receives a message that is not well-formed XML, it MUST >> reply with an 'operation-failed' error. >> >> A few sentences on this issue should be added to >> the security considerations section (see below). >> >> >> Section 3.2. No Document Type Declarations >> >> The title sounds like a command. >> Change to "Document Type Declarations". >> >> >> Section 4.3. Element >> >> s/layer: Messages/layer: Message/ >> s/layer: Operations/layer: Operation/ >> >> >> Section 5.2. Data Modeling >> >> "Devices and managers may support multiple data models, ..." >> >> s/managers/applications/ >> >> >> Section 7.5. >> >> To differentiate from Partial Lock RFC clearly, I would >> underline that the operation is on the entire configuration >> datastore. >> >> OLD: >> The lock operation allows the client to lock the configuration >> system of a device. >> NEW: >> The lock operation allows the client to lock an entire configuration >> datastore of a server. >> >> I also would suggest to keep using the term "configuration >> datastore" instead of "configuration", which is used in other >> parts of the document to mean a specific part of the >> configuration of a datastore. >> >> E.g. >> "An attempt to lock the configuration datastore MUST..." >> "The target configuration datastore is ,..." >> "The target parameter names the configuration datastore that will be >> locked." >> >> Sec. 1.1. says: >> "session: Client and server exchange messages using a secure, >> connection-oriented session." >> >> Sec. 2.1. Connection-Oriented Operation says: >> "For example, when a lock is acquired by a client, the lock >> persists until either it is explicitly released or the server >> determines that the connection has been terminated." >> >> Sec. 2.3. Authentication says: >> "The access permissions of a given client, identified by its >> NETCONF username, are part of the configuration of the NETCONF >> server. These permissions MUST be enforced during the remainder >> of the NETCONF session." >> >> Sec. 7.5 says: >> "The operation can be used to force the >> release of a lock owned by another NETCONF session." >> >> How a client can release a lock which is owned by another >> session needs to be elaborated. E.g. Partial Lock RFC says: >> "If needed, the returned session-id may be used to the >> NETCONF session holding the lock." >> >> I actually would suggest to delete this sentence in section 7.5. >> and stick to the statement in section 2.1. >> >> >> Section 7.7. >> >> "filter: >> This parameter specifies the portion of the system >> configuration and state data to retrieve. If this parameter is >> not present, all the device configuration and state information >> is returned." >> >> For the sake of completeness I would add what happens >> if the filter parameter is available but empty. >> >> >> Section 8.4.1. Description >> >> s/configuration, /configuration. / >> >> >> Section 8.4.1. Description and 8.6.1. Description >> >> OLD: >> The current version is 1.1, and is defined in this document. It >> extends... >> NEW: >> The version 1.1 is defined in this document and extends... >> >> >> Section 12.2. Informative References >> >> Add draft-ietf-netmod-yang-usage-11 as informative reference. >> >> >> Section 9. Security Considerations >> >> I would suggest to add a few sentences for the EOM handling >> and the possible thread concerning section 3. It would be >> interesting to recommend a possible reaction if this happens >> frequently, e.g. to drop the NETCONF session. >> >> >> Appendix B. XML Schema for NETCONF Messages Layer >> >> s/XML Schema for NETCONF Messages Layer/ >> XML Schema for NETCONF Message Layer/ >> >> >> Cheers, >> Mehmet >> >> >> > -----Original Message----- >> > From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org ] On >> > Behalf Of ext Bert (IETF) Wijnen >> > Sent: Thursday, September 23, 2010 1:48 PM >> > To: Netconf >> > Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft- >> > ietf-netconf-4741bis-04.txt >> > >> > >> > It was pointed out to me that we did not get ANY comments to this >> > WGLC. >> > Well, there was continued discussion on XML parse errors (which is >> > related partly to this document) on which we will come back >> tomorrow. >> > >> > But no other comments, Also not any " I read it, go ahead to the >> next >> > step". >> > >> > Can the WG chairs assume that people have indeed read the latest >> > version >> > of this document and are OK with it? >> > >> > Can you please ASAP tell us: I read the doc and I am fine with it!!! >> > >> > PLEASE >> > >> > Bert and Mehmet >> > >> > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote: >> > > WG participants, this email starts a formal WG Last Call for >> revision >> > 4 >> > > of the 4741bis document. The document is targeted as Proposed >> > Standard >> > > to replace the current rfc4741. >> > > >> > > Please do review and tell us your position and comments. >> > > Please do so BEFORE 20 September 2010. >> > > >> > > Bert and Mehmet >> > > >> > > ----- Original Message ----- >> > > From:> >> > > To:> >> > > Cc:> >> > > Sent: Monday, August 23, 2010 7:00 PM >> > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt >> > > >> > > >> > > 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-04.txt >> > > Pages : 121 >> > > Date : 2010-08-23 >> > > >> > > 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-04.txt >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > _______________________________________________ >> > > 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 >> _______________________________________________ >> 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 >> > > --001636c92e9c48137b04920a0acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not really advocating right now.=A0 Just pointing out a "hole&= quot; or "ambiguity" that could cause client/server communication= s issues and some possible solutions.=A0

And trying to raise awaren= ess; if we want cross-vendor client/server compatibility this issue needs t= o be clarified.

There does not seem to be a good way for the client/server to negotiate= XML versions since the capabilities in the <hello> message is itself= XML.=A0 Nor is there a good way to return an "XML version unsupported= " error, both because there is no general catchall "error" m= essage and also because the returned error would be in some version of XML = itself and therefore potentially unreadable by the receiver.

Note as a corollary, what to do with malformed XML seems undefined.
=
So it seems like to achieve cross vendor compatibility we must either= =20 require that servers (or clients actually) handle all XML versions, or pick= one version and REQUIRE it, or add some version negotiation messages.

Some specific ideas.

1. Require that certain messages be XML 1.0= (hello with another "capabilities" tag describing the support XM= L versions), so can be understood by all servers.=A0 This is sort of a pain= from a software perspective because a lot of XML 1.1 libraries automatical= ly optimize <a></a> to <a/>.=A0

2. Require that servers try to parse using both formats (if it gets a p= arse error, try the other format) if the XML header is not there.=A0 But it= would require analysis to show that this would result in provably correct = behavior (i.e. no possible XML 1.1 string could be successfully parsed by X= ML 1.0 in a semantically different way, and vice versa).=A0 It also puts a = computational and code size burden on servers, pushing NETCONF away from hi= ghly embedded devices -- XML is already very expensive to parse why make it= worse?=A0 Of course a smart server could "learn" what the client= is likely using.=A0 Is XML 1.1 a superset of XML 1.0 (I'm not positive= but its definitely pretty close)?

3. Require that the "hello" message contain the XML declarati= on (containing the version), and assume that as the default for this sessio= n.=A0 Of course this also means that servers must be required to speak both= XML versions (or we have to add an unsupported XML version error message),= but at least the client is free to use whatever is convenient.

4. Drop the connection on parse error -- client side could then reconne= ct with a different XML version.=A0 But establishing connections is expensi= ve and just dropping the connection is an ambiguous response -- the connect= ion could be closed for many reasons, like server overload or idle timeout,= or any other transport level issue.=A0 So I think this solution is not so = good.

Regards,
Andrew


On Thu, Oct 7,= 2010 at 12:12 PM, Andy Bierman <ietf@andybierman.com> wrote:
On 10/07/2010 08:45 AM, Andrew Stone wrote:
"A NETCONF message MAY begin with an XML declaration (see section 2.8 = of [1 =A0<http://tools.ietf.org/html/draft-ietf-netcon= f-4741bis-04#ref-1>])."



Since the XML declaration is optional, shall we clarify which version of XML must be used if the declaration is NOT included?

And perhaps require that servers handle all XML versions (1.0 and 1.1)
following the protocol design philosophy that "receivers" should = be
generous in what they accept? =A0If we do not require this, we could get clients that can't communicate with servers because the client sends XM= L
ver 1.1 (say) and the server only accepts 1.0.

Or just keep it simple and require that all NETCONF messages be XML
version 1.1.


I sort of object to this change. (3/4 objection?)

It would be OK to say a server MUST support 1.0 and SHOULD or MAY support 1= .1.
It seems like the version MUST be present if a server is required to suppor= t
multiple versions of XML.



Regards,
Andrew


Andy




On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich)
<mehmet.ersue@= nsn.com <mailto:mehmet.ersue@nsn.com>> wrote:

=A0 =A0Dear NETCONF Members,

=A0 =A0I hope this mail motivates the Netconf community to
=A0 =A0comment or raises at least some discussion on the
=A0 =A0content of 4741bis.

=A0 =A0As you know 4741bis is the base protocol document
=A0 =A0for NETCONF. Please comment on the 4741bis draft.
=A0 =A0It would be actually sufficient to say: "I read it
=A0 =A0and it is ready to ship."


=A0 =A0[Co-chair hat off]

=A0 =A0I had read the document but read again.
=A0 =A0I couldn't find any serious issues and I think it is
=A0 =A0ready for publication though I have a few suggestions
=A0 =A0to make it more consistent and to improve the clarity
=A0 =A0as a standard-track document.


=A0 =A0Section 1.1. Terminology

=A0 =A0I would suggest to bring the terms client/manager/
=A0 =A0application vs. agent/server/device as early as
=A0 =A0possible into relation. The document mainly avoids
=A0 =A0the usage of the terms manager and agent though
=A0 =A0there are some leftovers.

=A0 =A0OLD:
=A0 =A0 =A0 client: A client invokes protocol operations on a server.
=A0 =A0NEW:
=A0 =A0 =A0 client: A client (manager, application) invokes
=A0 =A0 =A0 protocol operations on a server (agent, device).

=A0 =A0OLD:
=A0 =A0 =A0 server: A server executes protocol operations invoked by a cli= ent.
=A0 =A0NEW:
=A0 =A0 =A0 server: A server (agent, device) executes protocol
=A0 =A0 =A0 operations invoked by a client (manager, application).


=A0 =A0Section 1.2. Protocol Overview

=A0 =A0To get it consistent with the rest of the document it would
=A0 =A0be good to use only singular for layer titles.

=A0 =A0s/Operations/Operation/
=A0 =A0s/Messages/Message/
=A0 =A0s/Secure Transports/Secure Transport/
=A0 =A0s/The Messages layer/The Message layer/
=A0 =A0s/The Operations layer/The Operation layer/


=A0 =A0Section 1.4. Separation of Configuration and State Data

=A0 =A0OLD:
=A0 =A0 =A0 For example, if a local database of user authentication data i= s
=A0 =A0 =A0 stored on the device, it is an implementation-dependent matter=
=A0 =A0 =A0 whether it is included in configuration data.
=A0 =A0NEW:
=A0 =A0 =A0 For example, if a local database of user authentication data i= s
=A0 =A0 =A0 stored on the device, it is implementation-dependent, whether<= br> =A0 =A0 =A0 it is included in configuration data.


=A0 =A0Section 3. XML Considerations

=A0 =A0Concerning the mail-thread on "how to handle XML parse
=A0 =A0errors" I agree with the last proposed text.

=A0 =A0OLD:
=A0 =A0 =A0 All NETCONF messages MUST be well-formed XML, encoded in UTF-8= .

=A0 =A0NEW:
=A0 =A0 =A0 All NETCONF messages MUST be well-formed XML, encoded in UTF-8= .
=A0 =A0 =A0 If a server receives a message that is not well-formed XML, it= MUST
=A0 =A0 =A0 reply with an 'operation-failed' error.

=A0 =A0A few sentences on this issue should be added to
=A0 =A0the security considerations section (see below).


=A0 =A0Section 3.2. No Document Type Declarations

=A0 =A0The title sounds like a command.
=A0 =A0Change to "Document Type Declarations".


=A0 =A0Section 4.3. <rpc-error> Element

=A0 =A0s/layer: Messages/layer: Message/
=A0 =A0s/layer: Operations/layer: Operation/


=A0 =A0Section 5.2. Data Modeling

=A0 =A0"Devices and managers may support multiple data models, ...&qu= ot;

=A0 =A0s/managers/applications/


=A0 =A0Section 7.5. <lock>

=A0 =A0To differentiate from Partial Lock RFC clearly, I would
=A0 =A0underline that the operation is on the entire configuration
=A0 =A0datastore.

=A0 =A0OLD:
=A0 =A0 =A0 The lock operation allows the client to lock the configuration=
=A0 =A0 =A0 system of a device.
=A0 =A0NEW:
=A0 =A0 =A0 The lock operation allows the client to lock an entire configu= ration
=A0 =A0 =A0 datastore of a server.

=A0 =A0I also would suggest to keep using the term "configuration
=A0 =A0datastore" instead of "configuration", which is used= in other
=A0 =A0parts of the document to mean a specific part of the
=A0 =A0configuration of a datastore.

=A0 =A0E.g.
=A0 =A0"An attempt to lock the configuration datastore MUST..."<= br> =A0 =A0"The target configuration datastore is <candidate>,...&q= uot;
=A0 =A0"The target parameter names the configuration datastore that w= ill be
=A0 =A0locked."

=A0 =A0Sec. 1.1. says:
=A0 =A0"session: Client and server exchange messages using a secure,<= br> =A0 =A0connection-oriented session."

=A0 =A0Sec. 2.1. Connection-Oriented Operation says:
=A0 =A0"For example, when a lock is acquired by a client, the lock =A0 =A0persists until either it is explicitly released or the server
=A0 =A0determines that the connection has been terminated."

=A0 =A0Sec. 2.3. Authentication says:
=A0 =A0"The access permissions of a given client, identified by its =A0 =A0NETCONF username, are part of the configuration of the NETCONF
=A0 =A0server. These permissions MUST be enforced during the remainder
=A0 =A0of the NETCONF session."

=A0 =A0Sec. 7.5 says:
=A0 =A0"The <kill-session> operation can be used to force the =A0 =A0release of a lock owned by another NETCONF session."

=A0 =A0How a client can release a lock which is owned by another
=A0 =A0session needs to be elaborated. E.g. Partial Lock RFC says:
=A0 =A0"If needed, the returned session-id may be used to <kill-se= ssion> the
=A0 =A0NETCONF session holding the lock."

=A0 =A0I actually would suggest to delete this sentence in section 7.5. =A0 =A0and stick to the statement in section 2.1.


=A0 =A0Section 7.7. <get>

=A0 =A0"filter:
=A0 =A0 =A0 This parameter specifies the portion of the system
=A0 =A0 =A0 configuration and state data to retrieve. =A0If this parameter= is
=A0 =A0 =A0 not present, all the device configuration and state informatio= n
=A0 =A0 =A0 is returned."

=A0 =A0For the sake of completeness I would add what happens
=A0 =A0if the filter parameter is available but empty.


=A0 =A0Section 8.4.1. Description

=A0 =A0s/configuration, /configuration. /


=A0 =A0Section 8.4.1. Description and 8.6.1. Description

=A0 =A0OLD:
=A0 =A0 =A0 The current version is 1.1, and is defined in this document. I= t
=A0 =A0extends...
=A0 =A0NEW:
=A0 =A0 =A0 The version 1.1 is defined in this document and extends...


=A0 =A0Section 12.2. Informative References

=A0 =A0Add draft-ietf-netmod-yang-usage-11 as informative reference.


=A0 =A0Section 9. Security Considerations

=A0 =A0I would suggest to add a few sentences for the EOM handling
=A0 =A0and the possible thread concerning section 3. It would be
=A0 =A0interesting to recommend a possible reaction if this happens
=A0 =A0frequently, e.g. to drop the NETCONF session.


=A0 =A0Appendix B. XML Schema for NETCONF Messages Layer

=A0 =A0s/XML Schema for NETCONF Messages Layer/
=A0 =A0XML Schema for NETCONF Message Layer/


=A0 =A0Cheers,
=A0 =A0Mehmet


=A0 =A0 > -----Original Message-----
=A0 =A0 > From: netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>
=A0 =A0[mailto:netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>] On
=A0 =A0 > Behalf Of ext Bert (IETF) Wijnen
=A0 =A0 > Sent: Thursday, September 23, 2010 1:48 PM
=A0 =A0 > To: Netconf
=A0 =A0 > Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:= draft-
=A0 =A0 > ietf-netconf-4741bis-04.txt
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > =A0 It was pointed out to me that we did not get ANY comments= to this
=A0 =A0 > WGLC.
=A0 =A0 > Well, there was continued discussion on XML parse errors (whi= ch is
=A0 =A0 > related partly to this document) on which we will come back t= omorrow.
=A0 =A0 >
=A0 =A0 > But no other comments, Also not any " I read it, go ahea= d to the next
=A0 =A0 > step".
=A0 =A0 >
=A0 =A0 > Can the WG chairs assume that people have indeed read the lat= est
=A0 =A0 > version
=A0 =A0 > of this document and are OK with it?
=A0 =A0 >
=A0 =A0 > Can you please ASAP tell us: I read the doc and I am fine wit= h it!!!
=A0 =A0 >
=A0 =A0 > PLEASE
=A0 =A0 >
=A0 =A0 > Bert and Mehmet
=A0 =A0 >
=A0 =A0 > On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote:
=A0 =A0 > > WG participants, this email starts a formal WG Last Call= for
=A0 =A0revision
=A0 =A0 > 4
=A0 =A0 > > of the 4741bis document. The document is targeted as Pro= posed
=A0 =A0 > Standard
=A0 =A0 > > to replace the current rfc4741.
=A0 =A0 > >
=A0 =A0 > > Please do review and tell us your position and comments.=
=A0 =A0 > > Please do so BEFORE 20 September 2010.
=A0 =A0 > >
=A0 =A0 > > Bert and Mehmet
=A0 =A0 > >
=A0 =A0 > > ----- Original Message -----
=A0 =A0 > > From:<Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>&= gt;
=A0 =A0 > > To:<i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
=A0 =A0 > > Cc:<netconf@ietf.org <mailto:netconf@ietf.org>>
=A0 =A0 > > Sent: Monday, August 23, 2010 7:00 PM
=A0 =A0 > > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis= -04.txt
=A0 =A0 > >
=A0 =A0 > >
=A0 =A0 > > A New Internet-Draft is available from the on-line Inter= net-Drafts
=A0 =A0 > > directories.
=A0 =A0 > > This draft is a work item of the Network Configuration W= orking
=A0 =A0Group
=A0 =A0 > of the
=A0 =A0 > > IETF.
=A0 =A0 > >
=A0 =A0 > >
=A0 =A0 > > Title =A0 =A0 =A0 =A0 =A0 : Network Configuration Protoc= ol (NETCONF)
=A0 =A0 > > Author(s) =A0 =A0 =A0 : R. Enns, et al.
=A0 =A0 > > Filename =A0 =A0 =A0 =A0: draft-ietf-netconf-4741bis-04.= txt
=A0 =A0 > > Pages =A0 =A0 =A0 =A0 =A0 : 121
=A0 =A0 > > Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-08-23
=A0 =A0 > >
=A0 =A0 > > The Network Configuration Protocol (NETCONF) defined in = this
=A0 =A0document
=A0 =A0 > > provides mechanisms to install, manipulate, and delete t= he
=A0 =A0 > > configuration of network devices. =A0It uses an Extensib= le Markup
=A0 =A0 > > Language (XML)-based data encoding for the configuration= data as
=A0 =A0well
=A0 =A0 > > as the protocol messages. =A0The NETCONF protocol operat= ions are
=A0 =A0 > > realized as Remote Procedure Calls (RPC).
=A0 =A0 > >
=A0 =A0 > > A URL for this Internet-Draft is:
=A0 =A0 > >
=A0 =A0http://www.ietf.org/internet-drafts/draft-= ietf-netconf-4741bis-04.txt
=A0 =A0 > >
=A0 =A0 > > Internet-Drafts are also available by anonymous FTP at:<= br> =A0 =A0 > > ftp://ftp.ietf.org/internet-drafts/
=A0 =A0 > >
=A0 =A0 > > _______________________________________________
=A0 =A0 > > Netconf mailing list
=A0 =A0 > > Ne= tconf@ietf.org <mailto:Netconf@ietf.org>

=A0 =A0 > > https://www.ietf.org/mailman/listinfo/netconf
=A0 =A0 > >
=A0 =A0 >
=A0 =A0 > _______________________________________________
=A0 =A0 > Netconf mailing list
=A0 =A0 > Netconf= @ietf.org <mailto:Netconf@ietf.org>

=A0 =A0 > https://www.ietf.org/mailman/listinfo/netconf
=A0 =A0_______________________________________________
=A0 =A0Netconf mailing list
=A0 =A0Netconf@ietf.= org <mailto:Ne= tconf@ietf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/netconf




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf


--001636c92e9c48137b04920a0acd-- From bertietf@bwijnen.net Mon Oct 11 14:04:55 2010 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 CE8C93A6B86 for ; Mon, 11 Oct 2010 14:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.141 X-Spam-Level: X-Spam-Status: No, score=-100.141 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 f5-X2jmuaHFL for ; Mon, 11 Oct 2010 14:04:55 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id A61DF3A681A for ; Mon, 11 Oct 2010 14:04:52 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1P5PZL-0008Ej-9o; Mon, 11 Oct 2010 23:06:03 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "Romascanu, Dan \(Dan\)" References: <4C977B5E.6080004@andybierman.com> In-Reply-To: <4C977B5E.6080004@andybierman.com> Date: Mon, 11 Oct 2010 23:05:22 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: netconf Subject: [Netconf] Ready for IESG agenda? [was AD review of draft-ietf-netconf-with-defaults-11] 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, 11 Oct 2010 21:04:56 -0000 So, my double check shows that we only got one set of comments (from our AD) and Andy agreed to some editorial edits for that. Andy, do you want to do so now? Or Dan, is it OK to await if the IESG has additional comments? Bert ----- Original Message ----- From: "Andy Bierman" To: "Romascanu, Dan (Dan)" Cc: "netconf" Sent: Monday, September 20, 2010 5:18 PM Subject: Re: [Netconf] AD review of draft-ietf-netconf-with-defaults-11 On 09/20/2010 07:30 AM, Romascanu, Dan (Dan) wrote: > I have reviewed draft-ietf-netconf-with-defaults-11 and I believe that > it is ready for IETF Last Call. I will send it soon to the IETF Last > Call. The comments below must be considered together with other comments > that may result from the IETF Last Call. The comments are divided into > Technical (T) and Editorial (E). > > T1. Section 1.3 > > 'Often > the default values are not interesting or specifically defined with a > "reasonable" value, so that the management user does not have to > handle them.' > > What does 'specifically defined with a "reasonable" value' mean? > I think it means there is a schema default value that is known, and its value will not cause any problems in the network. I agree the wording is strange. > > T2. Section 4.1 > > 'o SHOULD support the 'report-all' or 'report-all-tagged' defaults > handling mode.' > > What about the 'trim' and 'default' handling modes. Why SHOULD? MUST not > a server implementing the :with-defaults capability support at least one > of the defaults handling modes? > Sec. 2: A server MUST select one of the three basic modes defined in this section for handling default data. The standard does not say which of the 3 modes MUST be supported. Perhaps it is not clear that the original intent of the parameter was to return data with defaults -- as opposed to suppressing the default leafs. That MUST got watered down to a SHOULD. It is possible for a server to claim conformance just by advertising its basic-mode. A leaf set the the basic mode is supposed to be accepted by the server, but this will not be of any use to the client (pick 1 of 1 options). > T3. Section 4.3. Conformance > > 'Every NETCONF server SHOULD implement this capability.' > > I assume that the SHOULD is because version 1.0 does not include this > capability. What about 4741bis and later - for these is not this a MUST? > > A 4741bis client can use 'merge' and 'remove' to edit the database, and never be concerned with a default. If the client chooses to use 'create' and 'delete' (for no apparent reason), then the basic-mode is useful to know wrt/ editing a leaf with a default value. Even without this capability, the client can discover the basic-mode of a server if it can attempt a 'no-op' edit on a default leaf, by setting a missing default leaf to its default value, then retrieving it, and finally deleting it. The WG agreed on SHOULD, which is the right choice (IMO). > > > E1. Section 1.1 - > 'Schema default data > MAY or may not be stored as part of a configuration datastore, > depending on the basic mode used by a particular server.' > > MAY needs not be capitalized here. OK > > E2. Please expand at first occurrence - CLI, SNMP, OK > > E3. Section 1.3 > > The management application often needs a single, definitive and > complete set of configuration values that determine how the a > networking device works. > > s/the a networking device/the netowrking device/ OK -- remove 'a' Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Tue Oct 12 00:16:22 2010 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 7D5163A67B6 for ; Tue, 12 Oct 2010 00:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 7pdZ1rrw6aGb for ; Tue, 12 Oct 2010 00:16:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 269133A6405 for ; Tue, 12 Oct 2010 00:16:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="211505826" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Oct 2010 03:17:32 -0400 X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="521813220" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Oct 2010 03:17:31 -0400 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: Tue, 12 Oct 2010 09:17:09 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ready for IESG agenda? [was [Netconf] AD review of draft-ietf-netconf-with-defaults-11] Thread-Index: ActpjM0sprG03l0FRBuIL/blqlqCVAAUHasg References: <4C977B5E.6080004@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Andy Bierman" Cc: netconf Subject: Re: [Netconf] Ready for IESG agenda? [was AD review of draft-ietf-netconf-with-defaults-11] 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, 12 Oct 2010 07:16:22 -0000 I would prefer the edits to be made before I place the document in IESG review, so that the other ADs can do their review on a 'clean and stable' document. Andy, if possible, please issue a new version before this Thursday.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 > Sent: Monday, October 11, 2010 11:05 PM > To: Andy Bierman; Romascanu, Dan (Dan) > Cc: netconf > Subject: Ready for IESG agenda? [was [Netconf] AD review of=20 > draft-ietf-netconf-with-defaults-11] >=20 > So, my double check shows that we only got one set of=20 > comments (from our AD) and Andy agreed to some editorial=20 > edits for that. >=20 > Andy, do you want to do so now? > Or Dan, is it OK to await if the IESG has additional comments? >=20 > Bert > ----- Original Message ----- > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: "netconf" > Sent: Monday, September 20, 2010 5:18 PM > Subject: Re: [Netconf] AD review of=20 > draft-ietf-netconf-with-defaults-11 >=20 >=20 > On 09/20/2010 07:30 AM, Romascanu, Dan (Dan) wrote: > > I have reviewed draft-ietf-netconf-with-defaults-11 and I=20 > believe that > > it is ready for IETF Last Call. I will send it soon to the IETF Last > > Call. The comments below must be considered together with=20 > other comments > > that may result from the IETF Last Call. The comments are=20 > divided into > > Technical (T) and Editorial (E).=20 > >=20 > > T1. Section 1.3=20 > >=20 > > 'Often > > the default values are not interesting or specifically=20 > defined with a > > "reasonable" value, so that the management user does not have to > > handle them.' > >=20 > > What does 'specifically defined with a "reasonable" value' mean? > >=20 >=20 > I think it means there is a schema default value that is known, > and its value will not cause any problems in the network. > I agree the wording is strange. >=20 > >=20 > > T2. Section 4.1 > >=20 > > 'o SHOULD support the 'report-all' or 'report-all-tagged' defaults > > handling mode.' > >=20 > > What about the 'trim' and 'default' handling modes. Why=20 > SHOULD? MUST not > > a server implementing the :with-defaults capability support=20 > at least one > > of the defaults handling modes?=20 > >=20 >=20 > Sec. 2: >=20 > A server MUST select one of the three basic modes defined in this > section for handling default data. >=20 > The standard does not say which of the 3 modes MUST be supported. >=20 > Perhaps it is not clear that the original intent of the=20 > > parameter was to return data with defaults -- as opposed to=20 > suppressing > the default leafs. That MUST got watered down to a SHOULD. >=20 > It is possible for a server to claim conformance just by advertising > its basic-mode. A leaf set the the basic=20 > mode is supposed > to be accepted by the server, but this will not be of any use > to the client (pick 1 of 1 options). >=20 > > T3. Section 4.3. Conformance > >=20 > > 'Every NETCONF server SHOULD implement this capability.' > >=20 > > I assume that the SHOULD is because version 1.0 does not=20 > include this > > capability. What about 4741bis and later - for these is not=20 > this a MUST? > >=20 > >=20 >=20 > A 4741bis client can use 'merge' and 'remove' to edit the database, > and never be concerned with a default. If the client chooses to > use 'create' and 'delete' (for no apparent reason), then the=20 > basic-mode > is useful to know wrt/ editing a leaf with a default value. >=20 > Even without this capability, the client can discover the basic-mode > of a server if it can attempt a 'no-op' edit on a default leaf, by > setting a missing default leaf to its default value, then=20 > retrieving it, > and finally deleting it. >=20 > The WG agreed on SHOULD, which is the right choice (IMO). >=20 > >=20 > >=20 > > E1. Section 1.1 -=20 > > 'Schema default data > > MAY or may not be stored as part of a configuration datastore, > > depending on the basic mode used by a particular server.' > >=20 > > MAY needs not be capitalized here.=20 >=20 > OK >=20 > >=20 > > E2. Please expand at first occurrence - CLI, SNMP,=20 >=20 > OK >=20 > >=20 > > E3. Section 1.3 > >=20 > > The management application often needs a single,=20 > definitive and > > complete set of configuration values that determine how the a > > networking device works. > >=20 > > s/the a networking device/the netowrking device/ >=20 > OK -- remove 'a' >=20 >=20 >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From ietf@andybierman.com Tue Oct 12 08:45:51 2010 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 A24853A69E3 for ; Tue, 12 Oct 2010 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 aXKekbyhpvjt for ; Tue, 12 Oct 2010 08:45:50 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by core3.amsl.com (Postfix) with ESMTP id EE4233A69DB for ; Tue, 12 Oct 2010 08:45:48 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o9CFl1Hb026712 for ; Tue, 12 Oct 2010 11:47:03 -0400 Authentication-Results: cm-omr12 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.126.29.10] ([108.126.29.10:47612] helo=[108.126.29.10]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CD/EC-04579-BD284BC4; Tue, 12 Oct 2010 11:47:00 -0400 To: "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" , "=?utf-8?B?QmVydCBXaWpuZW4gKElFVEYp?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 12 Oct 2010 08:46:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4_1286898411035" Cc: netconf Subject: Re: [Netconf] =?utf-8?q?Ready_for_IESG_agenda=3F_=5Bwas__AD_review_of?= =?utf-8?q?_draft-ietf-netconf-with-defaults-11=5D?= 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, 12 Oct 2010 15:45:51 -0000 ------=_Part_4_1286898411035 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBtYXkgbm90IGdldCB0byB0aGlzIHVudGlsIHRodXJzZGF5LgpJIHdpbGwgdHJ5LgoKLS0tLS0g UmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiUm9tYXNjYW51LCBEYW4gKERhbikiIDxkcm9tYXNj YUBhdmF5YS5jb20+CkRhdGU6IFR1ZSwgT2N0IDEyLCAyMDEwIDAwOjE3ClN1YmplY3Q6IFJlYWR5 IGZvciBJRVNHIGFnZW5kYT8gW3dhcyBbTmV0Y29uZl0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bmV0Y29uZi13aXRoLWRlZmF1bHRzLTExXQpUbzogIkJlcnQgV2lqbmVuIChJRVRGKSIgPGJlcnRp ZXRmQGJ3aWpuZW4ubmV0PiwgIkFuZHkgQmllcm1hbiIgPGlldGZAYW5keWJpZXJtYW4uY29tPgpD YzogIm5ldGNvbmYiIDxuZXRjb25mQGlldGYub3JnPgoKCkkgd291bGQgcHJlZmVyIHRoZSBlZGl0 cyB0byBiZSBtYWRlIGJlZm9yZSBJIHBsYWNlIHRoZSBkb2N1bWVudCBpbiBJRVNHCnJldmlldywg c28gdGhhdCB0aGUgb3RoZXIgQURzIGNhbiBkbyB0aGVpciByZXZpZXcgb24gYSAnY2xlYW4gYW5k CnN0YWJsZScgZG9jdW1lbnQuIEFuZHksIGlmIHBvc3NpYmxlLCBwbGVhc2UgaXNzdWUgYSBuZXcg dmVyc2lvbiBiZWZvcmUKdGhpcyBUaHVyc2RheS4gCgpUaGFua3MgYW5kIFJlZ2FyZHMsCgpEYW4K IAoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEJlcnQgV2lqbmVuIChJRVRG KSBbbWFpbHRvOmJlcnRpZXRmQGJ3aWpuZW4ubmV0XSAKPiBTZW50OiBNb25kYXksIE9jdG9iZXIg MTEsIDIwMTAgMTE6MDUgUE0KPiBUbzogQW5keSBCaWVybWFuOyBSb21hc2NhbnUsIERhbiAoRGFu KQo+IENjOiBuZXRjb25mCj4gU3ViamVjdDogUmVhZHkgZm9yIElFU0cgYWdlbmRhPyBbd2FzIFtO ZXRjb25mXSBBRCByZXZpZXcgb2YgCj4gZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMt MTFdCj4gCj4gU28sIG15IGRvdWJsZSBjaGVjayBzaG93cyB0aGF0IHdlIG9ubHkgZ290IG9uZSBz ZXQgb2YgCj4gY29tbWVudHMgKGZyb20gb3VyIEFEKSBhbmQgQW5keSBhZ3JlZWQgdG8gc29tZSBl ZGl0b3JpYWwgCj4gZWRpdHMgZm9yIHRoYXQuCj4gCj4gQW5keSwgZG8geW91IHdhbnQgdG8gZG8g c28gbm93Pwo+IE9yIERhbiwgaXMgaXQgT0sgdG8gYXdhaXQgaWYgdGhlIElFU0cgaGFzIGFkZGl0 aW9uYWwgY29tbWVudHM/Cj4gCj4gQmVydAo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0K PiBGcm9tOiAiQW5keSBCaWVybWFuIiA8aWV0ZkBhbmR5Ymllcm1hbi5jb20+Cj4gVG86ICJSb21h c2NhbnUsIERhbiAoRGFuKSIgPGRyb21hc2NhQGF2YXlhLmNvbT4KPiBDYzogIm5ldGNvbmYiIDxu ZXRjb25mQGlldGYub3JnPgo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIwLCAyMDEwIDU6MTgg UE0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIEFEIHJldmlldyBvZiAKPiBkcmFmdC1pZXRmLW5l dGNvbmYtd2l0aC1kZWZhdWx0cy0xMQo+IAo+IAo+IE9uIDA5LzIwLzIwMTAgMDc6MzAgQU0sIFJv bWFzY2FudSwgRGFuIChEYW4pIHdyb3RlOgo+ID4gSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYt bmV0Y29uZi13aXRoLWRlZmF1bHRzLTExIGFuZCBJIAo+IGJlbGlldmUgdGhhdAo+ID4gaXQgaXMg cmVhZHkgZm9yIElFVEYgTGFzdCBDYWxsLiBJIHdpbGwgc2VuZCBpdCBzb29uIHRvIHRoZSBJRVRG IExhc3QKPiA+IENhbGwuIFRoZSBjb21tZW50cyBiZWxvdyBtdXN0IGJlIGNvbnNpZGVyZWQgdG9n ZXRoZXIgd2l0aCAKPiBvdGhlciBjb21tZW50cwo+ID4gdGhhdCBtYXkgcmVzdWx0IGZyb20gdGhl IElFVEYgTGFzdCBDYWxsLiBUaGUgY29tbWVudHMgYXJlIAo+IGRpdmlkZWQgaW50bwo+ID4gVGVj aG5pY2FsIChUKSBhbmQgRWRpdG9yaWFsIChFKS4gCj4gPiAKPiA+IFQxLiBTZWN0aW9uIDEuMyAK PiA+IAo+ID4gICAgJ09mdGVuCj4gPiAgICB0aGUgZGVmYXVsdCB2YWx1ZXMgYXJlIG5vdCBpbnRl cmVzdGluZyBvciBzcGVjaWZpY2FsbHkgCj4gZGVmaW5lZCB3aXRoIGEKPiA+ICAgICJyZWFzb25h YmxlIiB2YWx1ZSwgc28gdGhhdCB0aGUgbWFuYWdlbWVudCB1c2VyIGRvZXMgbm90IGhhdmUgdG8K PiA+ICAgIGhhbmRsZSB0aGVtLicKPiA+IAo+ID4gV2hhdCBkb2VzICdzcGVjaWZpY2FsbHkgZGVm aW5lZCB3aXRoIGEgInJlYXNvbmFibGUiIHZhbHVlJyBtZWFuPwo+ID4gCj4gCj4gSSB0aGluayBp dCBtZWFucyB0aGVyZSBpcyBhIHNjaGVtYSBkZWZhdWx0IHZhbHVlIHRoYXQgaXMga25vd24sCj4g YW5kIGl0cyB2YWx1ZSB3aWxsIG5vdCBjYXVzZSBhbnkgcHJvYmxlbXMgaW4gdGhlIG5ldHdvcmsu Cj4gSSBhZ3JlZSB0aGUgd29yZGluZyBpcyBzdHJhbmdlLgo+IAo+ID4gCj4gPiBUMi4gU2VjdGlv biA0LjEKPiA+IAo+ID4gJ28gIFNIT1VMRCBzdXBwb3J0IHRoZSAncmVwb3J0LWFsbCcgb3IgJ3Jl cG9ydC1hbGwtdGFnZ2VkJyBkZWZhdWx0cwo+ID4gICAgICAgaGFuZGxpbmcgbW9kZS4nCj4gPiAK PiA+IFdoYXQgYWJvdXQgdGhlICd0cmltJyBhbmQgJ2RlZmF1bHQnIGhhbmRsaW5nIG1vZGVzLiBX aHkgCj4gU0hPVUxEPyBNVVNUIG5vdAo+ID4gYSBzZXJ2ZXIgaW1wbGVtZW50aW5nIHRoZSA6d2l0 aC1kZWZhdWx0cyBjYXBhYmlsaXR5IHN1cHBvcnQgCj4gYXQgbGVhc3Qgb25lCj4gPiBvZiB0aGUg ZGVmYXVsdHMgaGFuZGxpbmcgbW9kZXM/IAo+ID4gCj4gCj4gU2VjLiAyOgo+IAo+ICAgIEEgc2Vy dmVyIE1VU1Qgc2VsZWN0IG9uZSBvZiB0aGUgdGhyZWUgYmFzaWMgbW9kZXMgZGVmaW5lZCBpbiB0 aGlzCj4gICAgc2VjdGlvbiBmb3IgaGFuZGxpbmcgZGVmYXVsdCBkYXRhLgo+IAo+IFRoZSBzdGFu ZGFyZCBkb2VzIG5vdCBzYXkgd2hpY2ggb2YgdGhlIDMgbW9kZXMgTVVTVCBiZSBzdXBwb3J0ZWQu Cj4gCj4gUGVyaGFwcyBpdCBpcyBub3QgY2xlYXIgdGhhdCB0aGUgb3JpZ2luYWwgaW50ZW50IG9m IHRoZSAKPiA8d2l0aC1kZWZhdWx0cz4KPiBwYXJhbWV0ZXIgd2FzIHRvIHJldHVybiBkYXRhIHdp dGggZGVmYXVsdHMgLS0gYXMgb3Bwb3NlZCB0byAKPiBzdXBwcmVzc2luZwo+IHRoZSBkZWZhdWx0 IGxlYWZzLiAgVGhhdCBNVVNUIGdvdCB3YXRlcmVkIGRvd24gdG8gYSBTSE9VTEQuCj4gCj4gSXQg aXMgcG9zc2libGUgZm9yIGEgc2VydmVyIHRvIGNsYWltIGNvbmZvcm1hbmNlIGp1c3QgYnkgYWR2 ZXJ0aXNpbmcKPiBpdHMgYmFzaWMtbW9kZS4gIEEgPHdpdGgtZGVmYXVsdHM+IGxlYWYgc2V0IHRo ZSB0aGUgYmFzaWMgCj4gbW9kZSBpcyBzdXBwb3NlZAo+IHRvIGJlIGFjY2VwdGVkIGJ5IHRoZSBz ZXJ2ZXIsIGJ1dCB0aGlzIHdpbGwgbm90IGJlIG9mIGFueSB1c2UKPiB0byB0aGUgY2xpZW50IChw aWNrIDEgb2YgMSBvcHRpb25zKS4KPiAKPiA+IFQzLiBTZWN0aW9uIDQuMy4gIENvbmZvcm1hbmNl Cj4gPiAKPiA+ICAgICdFdmVyeSBORVRDT05GIHNlcnZlciBTSE9VTEQgaW1wbGVtZW50IHRoaXMg Y2FwYWJpbGl0eS4nCj4gPiAKPiA+IEkgYXNzdW1lIHRoYXQgdGhlIFNIT1VMRCBpcyBiZWNhdXNl IHZlcnNpb24gMS4wIGRvZXMgbm90IAo+IGluY2x1ZGUgdGhpcwo+ID4gY2FwYWJpbGl0eS4gV2hh dCBhYm91dCA0NzQxYmlzIGFuZCBsYXRlciAtIGZvciB0aGVzZSBpcyBub3QgCj4gdGhpcyBhIE1V U1Q/Cj4gPiAKPiA+IAo+IAo+IEEgNDc0MWJpcyBjbGllbnQgY2FuIHVzZSAnbWVyZ2UnIGFuZCAn cmVtb3ZlJyB0byBlZGl0IHRoZSBkYXRhYmFzZSwKPiBhbmQgbmV2ZXIgYmUgY29uY2VybmVkIHdp dGggYSBkZWZhdWx0LiAgSWYgdGhlIGNsaWVudCBjaG9vc2VzIHRvCj4gdXNlICdjcmVhdGUnIGFu ZCAnZGVsZXRlJyAoZm9yIG5vIGFwcGFyZW50IHJlYXNvbiksIHRoZW4gdGhlIAo+IGJhc2ljLW1v ZGUKPiBpcyB1c2VmdWwgdG8ga25vdyB3cnQvIGVkaXRpbmcgYSBsZWFmIHdpdGggYSBkZWZhdWx0 IHZhbHVlLgo+IAo+IEV2ZW4gd2l0aG91dCB0aGlzIGNhcGFiaWxpdHksIHRoZSBjbGllbnQgY2Fu IGRpc2NvdmVyIHRoZSBiYXNpYy1tb2RlCj4gb2YgYSBzZXJ2ZXIgaWYgaXQgY2FuIGF0dGVtcHQg YSAnbm8tb3AnIGVkaXQgb24gYSBkZWZhdWx0IGxlYWYsIGJ5Cj4gc2V0dGluZyBhIG1pc3Npbmcg ZGVmYXVsdCBsZWFmIHRvIGl0cyBkZWZhdWx0IHZhbHVlLCB0aGVuIAo+IHJldHJpZXZpbmcgaXQs Cj4gYW5kIGZpbmFsbHkgZGVsZXRpbmcgaXQuCj4gCj4gVGhlIFdHIGFncmVlZCBvbiBTSE9VTEQs IHdoaWNoIGlzIHRoZSByaWdodCBjaG9pY2UgKElNTykuCj4gCj4gPiAKPiA+IAo+ID4gRTEuIFNl Y3Rpb24gMS4xIC0gCj4gPiAgICAgICAnU2NoZW1hIGRlZmF1bHQgZGF0YQo+ID4gICAgICAgTUFZ IG9yIG1heSBub3QgYmUgc3RvcmVkIGFzIHBhcnQgb2YgYSBjb25maWd1cmF0aW9uIGRhdGFzdG9y ZSwKPiA+ICAgICAgIGRlcGVuZGluZyBvbiB0aGUgYmFzaWMgbW9kZSB1c2VkIGJ5IGEgcGFydGlj dWxhciBzZXJ2ZXIuJwo+ID4gCj4gPiBNQVkgbmVlZHMgbm90IGJlIGNhcGl0YWxpemVkIGhlcmUu IAo+IAo+IE9LCj4gCj4gPiAKPiA+IEUyLiBQbGVhc2UgZXhwYW5kIGF0IGZpcnN0IG9jY3VycmVu Y2UgLSBDTEksIFNOTVAsIAo+IAo+IE9LCj4gCj4gPiAKPiA+IEUzLiBTZWN0aW9uIDEuMwo+ID4g Cj4gPiAgICAgICBUaGUgbWFuYWdlbWVudCBhcHBsaWNhdGlvbiBvZnRlbiBuZWVkcyBhIHNpbmds ZSwgCj4gZGVmaW5pdGl2ZSBhbmQKPiA+ICAgICAgIGNvbXBsZXRlIHNldCBvZiBjb25maWd1cmF0 aW9uIHZhbHVlcyB0aGF0IGRldGVybWluZSBob3cgdGhlIGEKPiA+ICAgICAgIG5ldHdvcmtpbmcg ZGV2aWNlIHdvcmtzLgo+ID4gCj4gPiBzL3RoZSBhIG5ldHdvcmtpbmcgZGV2aWNlL3RoZSBuZXRv d3JraW5nIGRldmljZS8KPiAKPiBPSyAtLSByZW1vdmUgJ2EnCj4gCj4gCj4gCj4gQW5keQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTmV0Y29uZiBt YWlsaW5nIGxpc3QKPiBOZXRjb25mQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mCj4gCgo= ------=_Part_4_1286898411035 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBtYXkgbm90IGdldCB0byB0aGlzIHVudGlsIHRodXJzZGF5Ljxicj5JIHdpbGwgdHJ5Ljxicj48 YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtSb21hc2NhbnUsIERh biAoRGFuKSZxdW90OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxicj5EYXRlOiBUdWUsIE9j dCAxMiwgMjAxMCAwMDoxNzxicj5TdWJqZWN0OiBSZWFkeSBmb3IgSUVTRyBhZ2VuZGE/IFt3YXMg W05ldGNvbmZdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0x MV08YnI+VG86ICZxdW90O0JlcnQgV2lqbmVuIChJRVRGKSZxdW90OyAmbHQ7YmVydGlldGZAYndp am5lbi5uZXQmZ3Q7LCAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5keWJpZXJt YW4uY29tJmd0Ozxicj5DYzogJnF1b3Q7bmV0Y29uZiZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9y ZyZndDs8YnI+PGJyPjxicj5JIHdvdWxkIHByZWZlciB0aGUgZWRpdHMgdG8gYmUgbWFkZSBiZWZv cmUgSSBwbGFjZSB0aGUgZG9jdW1lbnQgaW4gSUVTRzxicj5yZXZpZXcsIHNvIHRoYXQgdGhlIG90 aGVyIEFEcyBjYW4gZG8gdGhlaXIgcmV2aWV3IG9uIGEgJiMzOTtjbGVhbiBhbmQ8YnI+c3RhYmxl JiMzOTsgZG9jdW1lbnQuIEFuZHksIGlmIHBvc3NpYmxlLCBwbGVhc2UgaXNzdWUgYSBuZXcgdmVy c2lvbiBiZWZvcmU8YnI+dGhpcyBUaHVyc2RheS4gPGJyPjxicj5UaGFua3MgYW5kIFJlZ2FyZHMs PGJyPjxicj5EYW48YnI+IDxicj48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4mZ3Q7IEZyb206IEJlcnQgV2lqbmVuIChJRVRGKSBbbWFpbHRvOmJlcnRpZXRmQGJ3aWpuZW4u bmV0XSA8YnI+Jmd0OyBTZW50OiBNb25kYXksIE9jdG9iZXIgMTEsIDIwMTAgMTE6MDUgUE08YnI+ Jmd0OyBUbzogQW5keSBCaWVybWFuOyBSb21hc2NhbnUsIERhbiAoRGFuKTxicj4mZ3Q7IENjOiBu ZXRjb25mPGJyPiZndDsgU3ViamVjdDogUmVhZHkgZm9yIElFU0cgYWdlbmRhPyBbd2FzIFtOZXRj b25mXSBBRCByZXZpZXcgb2YgPGJyPiZndDsgZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVs dHMtMTFdPGJyPiZndDsgPGJyPiZndDsgU28sIG15IGRvdWJsZSBjaGVjayBzaG93cyB0aGF0IHdl IG9ubHkgZ290IG9uZSBzZXQgb2YgPGJyPiZndDsgY29tbWVudHMgKGZyb20gb3VyIEFEKSBhbmQg QW5keSBhZ3JlZWQgdG8gc29tZSBlZGl0b3JpYWwgPGJyPiZndDsgZWRpdHMgZm9yIHRoYXQuPGJy PiZndDsgPGJyPiZndDsgQW5keSwgZG8geW91IHdhbnQgdG8gZG8gc28gbm93Pzxicj4mZ3Q7IE9y IERhbiwgaXMgaXQgT0sgdG8gYXdhaXQgaWYgdGhlIElFU0cgaGFzIGFkZGl0aW9uYWwgY29tbWVu dHM/PGJyPiZndDsgPGJyPiZndDsgQmVydDxicj4mZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS08YnI+Jmd0OyBGcm9tOiAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5k eWJpZXJtYW4uY29tJmd0Ozxicj4mZ3Q7IFRvOiAmcXVvdDtSb21hc2NhbnUsIERhbiAoRGFuKSZx dW90OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxicj4mZ3Q7IENjOiAmcXVvdDtuZXRjb25m JnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4mZ3Q7IFNlbnQ6IE1vbmRheSwgU2Vw dGVtYmVyIDIwLCAyMDEwIDU6MTggUE08YnI+Jmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZdIEFE IHJldmlldyBvZiA8YnI+Jmd0OyBkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMTxi cj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDA5LzIwLzIwMTAgMDc6MzAgQU0sIFJvbWFzY2Fu dSwgRGFuIChEYW4pIHdyb3RlOjxicj4mZ3Q7ICZndDsgSSBoYXZlIHJldmlld2VkIGRyYWZ0LWll dGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExIGFuZCBJIDxicj4mZ3Q7IGJlbGlldmUgdGhhdDxi cj4mZ3Q7ICZndDsgaXQgaXMgcmVhZHkgZm9yIElFVEYgTGFzdCBDYWxsLiBJIHdpbGwgc2VuZCBp dCBzb29uIHRvIHRoZSBJRVRGIExhc3Q8YnI+Jmd0OyAmZ3Q7IENhbGwuIFRoZSBjb21tZW50cyBi ZWxvdyBtdXN0IGJlIGNvbnNpZGVyZWQgdG9nZXRoZXIgd2l0aCA8YnI+Jmd0OyBvdGhlciBjb21t ZW50czxicj4mZ3Q7ICZndDsgdGhhdCBtYXkgcmVzdWx0IGZyb20gdGhlIElFVEYgTGFzdCBDYWxs LiBUaGUgY29tbWVudHMgYXJlIDxicj4mZ3Q7IGRpdmlkZWQgaW50bzxicj4mZ3Q7ICZndDsgVGVj aG5pY2FsIChUKSBhbmQgRWRpdG9yaWFsIChFKS4gPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7 IFQxLiBTZWN0aW9uIDEuMyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyYjMzk7T2Z0ZW48YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgZGVmYXVsdCB2YWx1ZXMg YXJlIG5vdCBpbnRlcmVzdGluZyBvciBzcGVjaWZpY2FsbHkgPGJyPiZndDsgZGVmaW5lZCB3aXRo IGE8YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsmcXVvdDtyZWFzb25hYmxlJnF1b3Q7IHZhbHVl LCBzbyB0aGF0IHRoZSBtYW5hZ2VtZW50IHVzZXIgZG9lcyBub3QgaGF2ZSB0bzxicj4mZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwO2hhbmRsZSB0aGVtLiYjMzk7PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAm Z3Q7IFdoYXQgZG9lcyAmIzM5O3NwZWNpZmljYWxseSBkZWZpbmVkIHdpdGggYSAmcXVvdDtyZWFz b25hYmxlJnF1b3Q7IHZhbHVlJiMzOTsgbWVhbj88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7IDxicj4m Z3Q7IEkgdGhpbmsgaXQgbWVhbnMgdGhlcmUgaXMgYSBzY2hlbWEgZGVmYXVsdCB2YWx1ZSB0aGF0 IGlzIGtub3duLDxicj4mZ3Q7IGFuZCBpdHMgdmFsdWUgd2lsbCBub3QgY2F1c2UgYW55IHByb2Js ZW1zIGluIHRoZSBuZXR3b3JrLjxicj4mZ3Q7IEkgYWdyZWUgdGhlIHdvcmRpbmcgaXMgc3RyYW5n ZS48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVDIuIFNlY3Rpb24gNC4xPGJy PiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICYjMzk7byAmbmJzcDtTSE9VTEQgc3VwcG9ydCB0aGUg JiMzOTtyZXBvcnQtYWxsJiMzOTsgb3IgJiMzOTtyZXBvcnQtYWxsLXRhZ2dlZCYjMzk7IGRlZmF1 bHRzPGJyPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoYW5kbGluZyBtb2RlLiYjMzk7 PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFdoYXQgYWJvdXQgdGhlICYjMzk7dHJpbSYjMzk7 IGFuZCAmIzM5O2RlZmF1bHQmIzM5OyBoYW5kbGluZyBtb2Rlcy4gV2h5IDxicj4mZ3Q7IFNIT1VM RD8gTVVTVCBub3Q8YnI+Jmd0OyAmZ3Q7IGEgc2VydmVyIGltcGxlbWVudGluZyB0aGUgOndpdGgt ZGVmYXVsdHMgY2FwYWJpbGl0eSBzdXBwb3J0IDxicj4mZ3Q7IGF0IGxlYXN0IG9uZTxicj4mZ3Q7 ICZndDsgb2YgdGhlIGRlZmF1bHRzIGhhbmRsaW5nIG1vZGVzPyA8YnI+Jmd0OyAmZ3Q7IDxicj4m Z3Q7IDxicj4mZ3Q7IFNlYy4gMjo8YnI+Jmd0OyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7QSBzZXJ2 ZXIgTVVTVCBzZWxlY3Qgb25lIG9mIHRoZSB0aHJlZSBiYXNpYyBtb2RlcyBkZWZpbmVkIGluIHRo aXM8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7c2VjdGlvbiBmb3IgaGFuZGxpbmcgZGVmYXVsdCBkYXRh Ljxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBzdGFuZGFyZCBkb2VzIG5vdCBzYXkgd2hpY2ggb2YgdGhl IDMgbW9kZXMgTVVTVCBiZSBzdXBwb3J0ZWQuPGJyPiZndDsgPGJyPiZndDsgUGVyaGFwcyBpdCBp cyBub3QgY2xlYXIgdGhhdCB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIHRoZSA8YnI+Jmd0OyAmbHQ7 d2l0aC1kZWZhdWx0cyZndDs8YnI+Jmd0OyBwYXJhbWV0ZXIgd2FzIHRvIHJldHVybiBkYXRhIHdp dGggZGVmYXVsdHMgLS0gYXMgb3Bwb3NlZCB0byA8YnI+Jmd0OyBzdXBwcmVzc2luZzxicj4mZ3Q7 IHRoZSBkZWZhdWx0IGxlYWZzLiAmbmJzcDtUaGF0IE1VU1QgZ290IHdhdGVyZWQgZG93biB0byBh IFNIT1VMRC48YnI+Jmd0OyA8YnI+Jmd0OyBJdCBpcyBwb3NzaWJsZSBmb3IgYSBzZXJ2ZXIgdG8g Y2xhaW0gY29uZm9ybWFuY2UganVzdCBieSBhZHZlcnRpc2luZzxicj4mZ3Q7IGl0cyBiYXNpYy1t b2RlLiAmbmJzcDtBICZsdDt3aXRoLWRlZmF1bHRzJmd0OyBsZWFmIHNldCB0aGUgdGhlIGJhc2lj IDxicj4mZ3Q7IG1vZGUgaXMgc3VwcG9zZWQ8YnI+Jmd0OyB0byBiZSBhY2NlcHRlZCBieSB0aGUg c2VydmVyLCBidXQgdGhpcyB3aWxsIG5vdCBiZSBvZiBhbnkgdXNlPGJyPiZndDsgdG8gdGhlIGNs aWVudCAocGljayAxIG9mIDEgb3B0aW9ucykuPGJyPiZndDsgPGJyPiZndDsgJmd0OyBUMy4gU2Vj dGlvbiA0LjMuICZuYnNwO0NvbmZvcm1hbmNlPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsmIzM5O0V2ZXJ5IE5FVENPTkYgc2VydmVyIFNIT1VMRCBpbXBsZW1lbnQgdGhp cyBjYXBhYmlsaXR5LiYjMzk7PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEkgYXNzdW1lIHRo YXQgdGhlIFNIT1VMRCBpcyBiZWNhdXNlIHZlcnNpb24gMS4wIGRvZXMgbm90IDxicj4mZ3Q7IGlu Y2x1ZGUgdGhpczxicj4mZ3Q7ICZndDsgY2FwYWJpbGl0eS4gV2hhdCBhYm91dCA0NzQxYmlzIGFu ZCBsYXRlciAtIGZvciB0aGVzZSBpcyBub3QgPGJyPiZndDsgdGhpcyBhIE1VU1Q/PGJyPiZndDsg Jmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IEEgNDc0MWJpcyBjbGllbnQgY2Fu IHVzZSAmIzM5O21lcmdlJiMzOTsgYW5kICYjMzk7cmVtb3ZlJiMzOTsgdG8gZWRpdCB0aGUgZGF0 YWJhc2UsPGJyPiZndDsgYW5kIG5ldmVyIGJlIGNvbmNlcm5lZCB3aXRoIGEgZGVmYXVsdC4gJm5i c3A7SWYgdGhlIGNsaWVudCBjaG9vc2VzIHRvPGJyPiZndDsgdXNlICYjMzk7Y3JlYXRlJiMzOTsg YW5kICYjMzk7ZGVsZXRlJiMzOTsgKGZvciBubyBhcHBhcmVudCByZWFzb24pLCB0aGVuIHRoZSA8 YnI+Jmd0OyBiYXNpYy1tb2RlPGJyPiZndDsgaXMgdXNlZnVsIHRvIGtub3cgd3J0LyBlZGl0aW5n IGEgbGVhZiB3aXRoIGEgZGVmYXVsdCB2YWx1ZS48YnI+Jmd0OyA8YnI+Jmd0OyBFdmVuIHdpdGhv dXQgdGhpcyBjYXBhYmlsaXR5LCB0aGUgY2xpZW50IGNhbiBkaXNjb3ZlciB0aGUgYmFzaWMtbW9k ZTxicj4mZ3Q7IG9mIGEgc2VydmVyIGlmIGl0IGNhbiBhdHRlbXB0IGEgJiMzOTtuby1vcCYjMzk7 IGVkaXQgb24gYSBkZWZhdWx0IGxlYWYsIGJ5PGJyPiZndDsgc2V0dGluZyBhIG1pc3NpbmcgZGVm YXVsdCBsZWFmIHRvIGl0cyBkZWZhdWx0IHZhbHVlLCB0aGVuIDxicj4mZ3Q7IHJldHJpZXZpbmcg aXQsPGJyPiZndDsgYW5kIGZpbmFsbHkgZGVsZXRpbmcgaXQuPGJyPiZndDsgPGJyPiZndDsgVGhl IFdHIGFncmVlZCBvbiBTSE9VTEQsIHdoaWNoIGlzIHRoZSByaWdodCBjaG9pY2UgKElNTykuPGJy PiZndDsgPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgRTEuIFNlY3Rp b24gMS4xIC0gPGJyPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzM5O1NjaGVtYSBk ZWZhdWx0IGRhdGE8YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1BWSBvciBtYXkg bm90IGJlIHN0b3JlZCBhcyBwYXJ0IG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUsPGJyPiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXBlbmRpbmcgb24gdGhlIGJhc2ljIG1vZGUg dXNlZCBieSBhIHBhcnRpY3VsYXIgc2VydmVyLiYjMzk7PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAm Z3Q7IE1BWSBuZWVkcyBub3QgYmUgY2FwaXRhbGl6ZWQgaGVyZS4gPGJyPiZndDsgPGJyPiZndDsg T0s8YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgRTIuIFBsZWFzZSBleHBhbmQg YXQgZmlyc3Qgb2NjdXJyZW5jZSAtIENMSSwgU05NUCwgPGJyPiZndDsgPGJyPiZndDsgT0s8YnI+ Jmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgRTMuIFNlY3Rpb24gMS4zPGJyPiZndDsg Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBtYW5hZ2VtZW50IGFw cGxpY2F0aW9uIG9mdGVuIG5lZWRzIGEgc2luZ2xlLCA8YnI+Jmd0OyBkZWZpbml0aXZlIGFuZDxi cj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcGxldGUgc2V0IG9mIGNvbmZpZ3Vy YXRpb24gdmFsdWVzIHRoYXQgZGV0ZXJtaW5lIGhvdyB0aGUgYTxicj4mZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgbmV0d29ya2luZyBkZXZpY2Ugd29ya3MuPGJyPiZndDsgJmd0OyA8YnI+ Jmd0OyAmZ3Q7IHMvdGhlIGEgbmV0d29ya2luZyBkZXZpY2UvdGhlIG5ldG93cmtpbmcgZGV2aWNl Lzxicj4mZ3Q7IDxicj4mZ3Q7IE9LIC0tIHJlbW92ZSAmIzM5O2EmIzM5Ozxicj4mZ3Q7IDxicj4m Z3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IEFuZHk8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJy PiZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4mZ3Q7IDxicj48YnI+PGJyPjxicj4= ------=_Part_4_1286898411035-- From root@core3.amsl.com Thu Oct 14 14:15:06 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 33D6C3A6B94; Thu, 14 Oct 2010 14:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101014211505.33D6C3A6B94@core3.amsl.com> Date: Thu, 14 Oct 2010 14:15:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-12.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: Thu, 14 Oct 2010 21:15:06 -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 : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-12.txt Pages : 32 Date : 2010-10-14 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-12.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-with-defaults-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-14140607.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Wed Oct 20 06:27:55 2010 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 49BF03A67D9 for ; Wed, 20 Oct 2010 06:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 7BKaL4LnXL46 for ; Wed, 20 Oct 2010 06:27:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1C46D3A67FE for ; Wed, 20 Oct 2010 06:27:53 -0700 (PDT) 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 o9KDTOL3016275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Oct 2010 15:29:24 +0200 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 o9KDTOh8002895; Wed, 20 Oct 2010 15:29:24 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 15:29:23 +0200 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: Wed, 20 Oct 2010 15:29:22 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011B6AC0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for NETCONF session in Beijing Thread-Index: ActwWs6YRe4rKHRpQuaC8q/7sxR6DQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 20 Oct 2010 13:29:24.0257 (UTC) FILETIME=[CF9A8910:01CB705A] Subject: [Netconf] Draft agenda for NETCONF session in Beijing 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, 20 Oct 2010 13:27:55 -0000 Dear NETCONF WG, we uploaded the draft agenda for NETCONF session in Beijing. Pls let us know any requests. http://www.ietf.org/proceedings/79/agenda/netconf.txt=20 Mehmet & Bert From bertietf@bwijnen.net Wed Oct 20 06:50:43 2010 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 0AEFD3A6975 for ; Wed, 20 Oct 2010 06:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.859 X-Spam-Level: X-Spam-Status: No, score=-98.859 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_40=-0.185, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 PuXM6QCGOZqs for ; Wed, 20 Oct 2010 06:50:42 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id 1B8563A682E for ; Wed, 20 Oct 2010 06:50:41 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1P8Z5R-0003fa-7R for netconf@ietf.org; Wed, 20 Oct 2010 15:52:13 +0200 Message-ID: <64A0B7E0557141968E99BCC4331E9C11@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 20 Oct 2010 15:52:05 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: [Netconf] status WGLC RFC4741bis 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, 20 Oct 2010 13:50:43 -0000 It seems that the WGLC discussion has now died out on the mailing list. >From re-reading all those comments, I also get the impression that there is consensus/agreement on the changes that need to be addressed. The editors (specifically Martin) is preparing a new revision based on the result of the discussions. Will probably show up later today. Our plan as WG-chairs is to allow the WG a few days to quickly check if the changes are OK. Then ask our Ad to bring it forward to IETF Last Call and IESG review. Thanks, Bert and Mehmet From root@core3.amsl.com Wed Oct 20 08:00:02 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 747EC3A682F; Wed, 20 Oct 2010 08:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101020150002.747EC3A682F@core3.amsl.com> Date: Wed, 20 Oct 2010 08:00:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-03.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: Wed, 20 Oct 2010 15:00:02 -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-03.txt Pages : 10 Date : 2010-10-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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20075407.I-D@ietf.org> --NextPart-- From biermana@Brocade.com Wed Oct 20 09:07:21 2010 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 DDE9D3A698F for ; Wed, 20 Oct 2010 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.188, 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 DE0L8VecI4Wc for ; Wed, 20 Oct 2010 09:07:19 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 768D53A696D for ; Wed, 20 Oct 2010 09:07:17 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9KFfJ6v012192 for ; Wed, 20 Oct 2010 09:08:50 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s21dug2du-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Oct 2010 09:08:50 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 09:13:09 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 20 Oct 2010 09:08:48 -0700 From: Andy Bierman To: Netconf Date: Wed, 20 Oct 2010 09:08:46 -0700 Thread-Topic: NACM draft Thread-Index: ActwcRNOGlw9rd0WSvicrmfq9c7d9g== 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_B11AB91666F22D498EEC66410EB3D3C4F412BEC6C2HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-20_08:2010-10-20, 2010-10-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010200085 X-Proofpoint-SSN: Sensitivity2 Subject: [Netconf] NACM draft 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, 20 Oct 2010 16:07:22 -0000 X-List-Received-Date: Wed, 20 Oct 2010 16:07:22 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F412BEC6C2HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There have not been any comments on this draft: http://www.ietf.org/id/draft-ietf-netconf-access-control-00.txt Juergen made a comment that the authentication objects should be removed. Nobody else commented on that, and so they were not removed from -00. There is no reason to publish a -01 draft since there has been no progress = on this document in 4 months. That means the draft is either ready for WGLC or the WG is ready to shut do= wn, since 4741bis and 4742bis are essentially done. Andy --_000_B11AB91666F22D498EEC66410EB3D3C4F412BEC6C2HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There have not been any comments on this draft:

ht= tp://www.ietf.org/id/draft-ietf-netconf-access-control-00.txt

 

Juergen made a comment that the authentication objects should be removed.

Nobody else commented on that, and so they were not re= moved from -00.

 

There is no reason to publish a -01 draft since there = has been no progress on this document in 4 months.

 

That means the draft is either ready for WGLC or the W= G is ready to shut down, since 4741bis and 4742bis
are essentially done.

 

 

Andy

 

--_000_B11AB91666F22D498EEC66410EB3D3C4F412BEC6C2HQ1EXCH01corp_-- From mehmet.ersue@nsn.com Wed Oct 20 09:26:39 2010 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 065553A6879 for ; Wed, 20 Oct 2010 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 b1Pkcver-3F3 for ; Wed, 20 Oct 2010 09:26:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3D0023A67FD for ; Wed, 20 Oct 2010 09:26:36 -0700 (PDT) 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 o9KGRVr9004135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Oct 2010 18:27:31 +0200 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 o9KGRV2H005163; Wed, 20 Oct 2010 18:27:31 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 18:27:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB7073.B124C544" Date: Wed, 20 Oct 2010 18:27:26 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status WGLC RFC4742bis WAS:FW: [Netconf] status WGLC RFC4741bis Thread-Index: ActwXg2dNN/X0wLqRUehDfoPVxLaGgAEa/FQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 20 Oct 2010 16:27:31.0423 (UTC) FILETIME=[B1A6A6F0:01CB7073] Cc: ext Margaret Wasserman Subject: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 20 Oct 2010 16:26:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7073.B124C544 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, same is with 4742bis WGLC discusion. We had only minor=20 changes after IETF 78. Our impression is that we have=20 consensus to see the draft as final. Margaret submitted the draft today making it ready for AD review. Please check the changes by 10/22 so that=20 we have a chance to re-submit before deadline. Thanks. Cheers, Mehmet -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Bert Wijnen (IETF) Sent: Wednesday, October 20, 2010 3:52 PM To: Netconf Subject: [Netconf] status WGLC RFC4741bis It seems that the WGLC discussion has now died out on the mailing list. >From re-reading all those comments, I also get the impression that=20 there is consensus/agreement on the changes that need to be addressed. The editors (specifically Martin) is preparing a new revision based on the result of the discussions. Will probably show up later today. Our plan as WG-chairs is to allow the WG a few days to quickly check if the changes are OK. Then ask our Ad to bring it forward to IETF Last Call and IESG review. Thanks, Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01CB7073.B124C544 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by DEMUEXC006.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 17:02:44 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01CB7067.D94F8200" Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 17:02:42 +0200 Received: from demumfd001.nsn-inter.net (DEMUMFD001 [93.183.12.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9KF2hDO002320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Oct 2010 17:02:43 +0200 Received: from mta1083.mail.ukl.yahoo.com (mta1083.mail.ukl.yahoo.com [77.238.184.211]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with SMTP id o9KF2c1w028303 for ; Wed, 20 Oct 2010 17:02:38 +0200 Received: (qmail 41696 invoked by uid 6007); 20 Oct 2010 15:02:37 -0000 Received: from 127.0.0.1 (EHLO mail.ietf.org) (64.170.98.32) by mta1083.mail.ukl.yahoo.com with SMTP; Wed, 20 Oct 2010 15:02:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4793A683A; Wed, 20 Oct 2010 08:00:05 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 747EC3A682F; Wed, 20 Oct 2010 08:00:02 -0700 (PDT) Content-class: urn:content-classes:message Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt Date: Wed, 20 Oct 2010 17:00:02 +0200 Message-ID: <20101020150002.747EC3A682F@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt Thread-Index: ActwZ9pV9DTjRdUYTBuK7G3tMtUz9w== List-Help: List-Subscribe: , List-Unsubscribe: , From: Sender: To: Cc: Reply-To: This is a multi-part message in MIME format. ------_=_NextPart_002_01CB7067.D94F8200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-03.txt Pages : 10 Date : 2010-10-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-03.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_002_01CB7067.D94F8200 Content-Type: application/octet-stream; name="draft-ietf-netconf-rfc4742bis-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-netconf-rfc4742bis-03.URL Content-Disposition: attachment; filename="draft-ietf-netconf-rfc4742bis-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5ldGNvbmYtcmZjNDc0MmJpcy0wMy50eHQNCg== ------_=_NextPart_002_01CB7067.D94F8200 Content-Type: text/plain; name="ATT861683.txt" Content-Transfer-Encoding: base64 Content-Description: ATT861683.txt Content-Disposition: attachment; filename="ATT861683.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_002_01CB7067.D94F8200-- ------_=_NextPart_001_01CB7073.B124C544-- From Richard.Dunsmore@us.fujitsu.com Wed Oct 20 09:26:50 2010 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 83B163A69CC for ; Wed, 20 Oct 2010 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.739 X-Spam-Level: X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 RiA+Q+4ySPKu for ; Wed, 20 Oct 2010 09:26:49 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by core3.amsl.com (Postfix) with ESMTP id 9D4923A69A0 for ; Wed, 20 Oct 2010 09:26:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,356,1283749200"; d="scan'208,217";a="403086401" Received: from rchemxp01.fnc.net.local ([168.127.134.111]) by fncnmp01.fnc.fujitsu.com with ESMTP; 20 Oct 2010 11:28:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7073.D02774E0" Date: Wed, 20 Oct 2010 11:28:22 -0500 Message-ID: <01F4E32C0948124DAA4C20DD6B52734201A5376B@rchemxp01.fnc.net.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: Actwc9AlqQGSnqUGSqGBktHvCb5LegAAAAAY From: "Dunsmore, Richard" To: "Netconf" Subject: [Netconf] Out of Office AutoReply: Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 20 Oct 2010 16:26:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7073.D02774E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am out of the office until 10/25 ------_=_NextPart_001_01CB7073.D02774E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: [Netconf] Status WGLC RFC4742bis WAS:FW: = status WGLC RFC4741bis

I am out of the office until 10/25

------_=_NextPart_001_01CB7073.D02774E0-- From lhotka@cesnet.cz Wed Oct 20 10:21:51 2010 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 56CD93A68F6 for ; Wed, 20 Oct 2010 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 r87-A+EuMZNx for ; Wed, 20 Oct 2010 10:21:50 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id AD08C3A68E0 for ; Wed, 20 Oct 2010 10:21:49 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 30C5F2CDE05B; Wed, 20 Oct 2010 19:23:22 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 20 Oct 2010 19:23:21 +0200 Message-ID: <1287595401.5999.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 20 Oct 2010 17:21:51 -0000 On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > same is with 4742bis WGLC discusion. We had only minor > changes after IETF 78. Our impression is that we have > consensus to see the draft as final. > > Margaret submitted the draft today making it ready for > AD review. Please check the changes by 10/22 so that > we have a chance to re-submit before deadline. Thanks. The justification for the EOM marker in sec. 3.1 is technically incorrect - and I objected against it previously: http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html Here is the change I propose (there's also a typo in "unambiguously"): OLD This character sequence cannot legally appear outside of a comment in an XML document, so it can be unambigiously used to identify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error. NEW This character sequence cannot legally appear outside of a comment, processing instruction and attribute value in an XML document, so it can be unambiguously used to identify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error. Lada > > Cheers, > Mehmet > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert Wijnen (IETF) > Sent: Wednesday, October 20, 2010 3:52 PM > To: Netconf > Subject: [Netconf] status WGLC RFC4741bis > > It seems that the WGLC discussion has now died out on the mailing list. > From re-reading all those comments, I also get the impression that > there is consensus/agreement on the changes that need to be addressed. > > The editors (specifically Martin) is preparing a new revision based > on the result of the discussions. Will probably show up later today. > > Our plan as WG-chairs is to allow the WG a few days to quickly check > if the changes are OK. Then ask our Ad to bring it forward to IETF > Last Call and IESG review. > > Thanks, > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > e-mail message attachment > > -------- Forwarded Message -------- > > From: Internet-Drafts@ietf.org > > Reply-to: > > To: i-d-announce@ietf.org > > Cc: netconf@ietf.org > > Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt > > Date: Wed, 20 Oct 2010 17:00:02 +0200 > > > > 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-03.txt > > Pages : 10 > > Date : 2010-10-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-03.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 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Wed Oct 20 12:45:02 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A556A3A68EC; Wed, 20 Oct 2010 12:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101020194502.A556A3A68EC@core3.amsl.com> Date: Wed, 20 Oct 2010 12:45:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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: Wed, 20 Oct 2010 19:45:02 -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-05.txt Pages : 121 Date : 2010-10-20 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-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-4741bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20124315.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Thu Oct 21 09:47:34 2010 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 9B5B03A6A3C for ; Thu, 21 Oct 2010 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 sM2fWddhzeD5 for ; Thu, 21 Oct 2010 09:47:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id E3CB53A683E for ; Thu, 21 Oct 2010 09:47:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9LGn6f0026052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 18:49:06 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9LGn6iD018150; Thu, 21 Oct 2010 18:49:06 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 18:49:06 +0200 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: Thu, 21 Oct 2010 18:49:04 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> In-Reply-To: <1287595401.5999.7.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: Actwe3/Tlh2/jQpXRgOSpEYrI43rPAAJbTYg References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ladislav Lhotka" X-OriginalArrivalTime: 21 Oct 2010 16:49:06.0495 (UTC) FILETIME=[DFFCB4F0:01CB713F] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 16:47:34 -0000 SGkgTGFkYSwNCg0KW3NwZWFraW5nIGFzIGEgY29udHJpYnV0b3JdDQoNCmlmIEkgdW5kZXJzdGFu ZCB5b3UgY29ycmVjdGx5IHlvdSB3YW50IHRvIGFsbG93IHRoZSBFT00gDQpub3Qgb25seSBpbiBj b21tZW50cyBidXQgYWxzbyBpbiBYTUwgYXR0cmlidXRlcyBhbmQgUElzLg0KDQpJbiBjYXNlIHRo ZSBhbnN3ZXIgaXMgbm86IEkgYXBwZWFyIHRvIG1pc3VuZGVyc3RhbmQgd2hhdCANCnlvdSB3ZXJl IHNheWluZy4gU28gcGxzIGV4cGxhaW4uDQoNCkluIGNhc2UgdGhlIGFuc3dlciBpcyB5ZXM6DQoN ClRoZW9yZXRpY2FsbHkgdGhlIEVPTSBzZXF1ZW5jZSBjYW4gYXBwZWFyIGV2ZXJ5d2hlcmUgaW4g DQphbiBYTUwgZG9jdW1lbnQuDQoNCkhvd2V2ZXIsIHRoZSB0cmFuc3BvcnQgbGF5ZXIgc2hvdWxk bid0IGRvIGZpbmUgZ3JhaW5lZCANCnBhcnNpbmcgb2YgdGhlIFhNTCBkb2N1bWVudCwgdG8gZmlu ZCBvdXQgd2hlcmUgdGhlIA0KYXR0cmlidXRlcyBvciBQSXMgYXJlLg0KVGhpcyBpcyB0aGUgcmVh c29uIHdoeSA0NzQyIGtlcHQgaXQgc2ltcGxlIGFuZCwgYXMgSSANCnRoaW5rLCBhcHByb3ByaWF0 ZSBmb3IgdGhlIHRyYW5zcG9ydCBsYXllci4gDQoNCkkgZG9uJ3Qgc2VlIGFueSBkaWZmZXJlbmNl IGJldHdlZW4gWE1MIGVsZW1lbnRzIGFuZCANClthdHRyaWJ1dGVzIG9yIFBJXS4gVGhleSBhbGwg YXJlIFhNTCBkYXRhLiBBbmQgRU9NIGNhbiANCmFwcGVhciBpbiBYTUwgZGF0YSBvciBhdCB0aGUg ZW5kIG9mIHRoZSBkb2N1bWVudC4NCklmIHNvbWVib2R5IHdhbnRzIHRvIGRpc3J1cHQgdGhlIHJw YyBjb21tYW5kIGhlIGNhbiANCmRvIGl0IG5vIG1hdHRlciBpbiBlbGVtZW50cyBvciBhdHRyaWJ1 dGVzLiANCg0KU28sIGF0IHRoZSBlbmQgSSBkb24ndCBzZWUgYW55IGJlbmVmaXQgaW4gcmVkdWNp bmcgdGhlIA0KcmVzdHJpY3Rpb24gYW5kIHRoaW5rOg0KVG8gYmUgb24gdGhlIHNhZmUgc2lkZSBh bmQgdG8ga2VlcCBpdCBzaW1wbGUgZm9yIHRoZSANCmltcGxlbWVudGVyIG9mIDQ3NDJiaXMgdGhl IHNlcXVlbmNlIG11c3Qgbm90IGFwcGVhciANCmluIHRoZSBYTUwgZG9jdW1lbnQgKGV4Y2VwdCBv dXRzaWRlIG9mIGNvbW1lbnRzKS4NCg0KW25vdyB0aGUgY2hhaXIgaGF0IG9uXToNCg0KUGxlYXNl IGtlZXAgaW4gbWluZCB0aGF0IHdlIGRvbid0IGhhdmUgdGhlIG1hbmRhdGUgDQpmb3IgdjIuMC4g V2UgYXJlIGp1c3QgZG9pbmcgYnVnLWZpeGluZy4NCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHYy LjAgc2hvdWxkIHNvbHZlIHRoaXMgaXNzdWUNCndpdGggYSB0aG9yb3VnaCBzb2x1dGlvbi4gV291 bGQgeW91IGxpa2UgdG8gcHJlcGFyZSANCmEgZmV3IHNsaWRlcyBmb3IgdGhlIE5FVENPTkYgc2Vz c2lvbiBpbiBCZWlqaW5nIGZvciANCmEgc29sdXRpb24sIHdoaWNoIGNvdWxkIGJlIHB1dCBsYXRl ciBpbnRvIHYyLjA/IA0KDQpDaGVlcnMsDQpNZWhtZXQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGV4dCBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAY2Vz bmV0LmN6XQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgNzoyMyBQTQ0KPiBU bzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiBDYzogTmV0Y29uZjsgZXh0IE1h cmdhcmV0IFdhc3Nlcm1hbg0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJG QzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dMQw0KPiBSRkM0NzQxYmlzDQo+IA0KPiBPbiBTdCwg MjAxMC0xMC0yMCBhdCAxODoyNyArMDIwMCwgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNo KQ0KPiB3cm90ZToNCj4gPiBIaSBBbGwsDQo+ID4NCj4gPiBzYW1lIGlzIHdpdGggNDc0MmJpcyBX R0xDIGRpc2N1c2lvbi4gV2UgaGFkIG9ubHkgbWlub3INCj4gPiBjaGFuZ2VzIGFmdGVyIElFVEYg NzguIE91ciBpbXByZXNzaW9uIGlzIHRoYXQgd2UgaGF2ZQ0KPiA+IGNvbnNlbnN1cyB0byBzZWUg dGhlIGRyYWZ0IGFzIGZpbmFsLg0KPiA+DQo+ID4gTWFyZ2FyZXQgc3VibWl0dGVkIHRoZSBkcmFm dCB0b2RheSBtYWtpbmcgaXQgcmVhZHkgZm9yDQo+ID4gQUQgcmV2aWV3LiBQbGVhc2UgY2hlY2sg dGhlIGNoYW5nZXMgYnkgMTAvMjIgc28gdGhhdA0KPiA+IHdlIGhhdmUgYSBjaGFuY2UgdG8gcmUt c3VibWl0IGJlZm9yZSBkZWFkbGluZS4gVGhhbmtzLg0KPiANCj4gVGhlIGp1c3RpZmljYXRpb24g Zm9yIHRoZSBFT00gbWFya2VyIGluIHNlYy4gMy4xIGlzIHRlY2huaWNhbGx5DQo+IGluY29ycmVj dCAtIGFuZCBJIG9iamVjdGVkIGFnYWluc3QgaXQgcHJldmlvdXNseToNCj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjI3Ny5odG1sDQo+ IA0KPiBIZXJlIGlzIHRoZSBjaGFuZ2UgSSBwcm9wb3NlICh0aGVyZSdzIGFsc28gYSB0eXBvIGlu ICJ1bmFtYmlndW91c2x5Iik6DQo+IA0KPiBPTEQNCj4gDQo+IFRoaXMgY2hhcmFjdGVyIHNlcXVl bmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudCBpbg0KPiBhbg0K PiBYTUwgZG9jdW1lbnQsIHNvIGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8gaWRlbnRp ZnkgdGhlIGVuZCBvZg0KPiB0aGUNCj4gY3VycmVudCBkb2N1bWVudCwgYWxsb3dpbmcgcmVzeW5j aHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYgZXhjaGFuZ2UgaW4NCj4gdGhlIGV2ZW50IG9mIGFu IFhNTCBzeW50YXggb3IgcGFyc2luZyBlcnJvci4NCj4gDQo+IE5FVw0KPiANCj4gVGhpcyBjaGFy YWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUgb2YgYSBjb21tZW50 LA0KPiBwcm9jZXNzaW5nIGluc3RydWN0aW9uIGFuZCBhdHRyaWJ1dGUgdmFsdWUgaW4gYW4gWE1M IGRvY3VtZW50LCBzbyBpdA0KPiBjYW4NCj4gYmUgdW5hbWJpZ3VvdXNseSB1c2VkIHRvIGlkZW50 aWZ5IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgZG9jdW1lbnQsDQo+IGFsbG93aW5nIHJlc3luY2hy b25pemF0aW9uIG9mIHRoZSBORVRDT05GIGV4Y2hhbmdlIGluIHRoZSBldmVudCBvZiBhbg0KPiBY TUwgc3ludGF4IG9yIHBhcnNpbmcgZXJyb3IuDQo+IA0KPiBMYWRhDQo+IA0KPiA+DQo+ID4gQ2hl ZXJzLA0KPiA+IE1laG1ldA0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYgT2YgZXh0IEJlcnQgV2lqbmVuIChJRVRGKQ0K PiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMCwgMjAxMCAzOjUyIFBNDQo+ID4gVG86IE5l dGNvbmYNCj4gPiBTdWJqZWN0OiBbTmV0Y29uZl0gc3RhdHVzIFdHTEMgUkZDNDc0MWJpcw0KPiA+ DQo+ID4gSXQgc2VlbXMgdGhhdCB0aGUgV0dMQyBkaXNjdXNzaW9uIGhhcyBub3cgZGllZCBvdXQg b24gdGhlIG1haWxpbmcNCj4gbGlzdC4NCj4gPiBGcm9tIHJlLXJlYWRpbmcgYWxsIHRob3NlIGNv bW1lbnRzLCBJIGFsc28gZ2V0IHRoZSBpbXByZXNzaW9uIHRoYXQNCj4gPiB0aGVyZSBpcyBjb25z ZW5zdXMvYWdyZWVtZW50IG9uIHRoZSBjaGFuZ2VzIHRoYXQgbmVlZCB0byBiZQ0KPiBhZGRyZXNz ZWQuDQo+ID4NCj4gPiBUaGUgZWRpdG9ycyAoc3BlY2lmaWNhbGx5IE1hcnRpbikgaXMgcHJlcGFy aW5nIGEgbmV3IHJldmlzaW9uIGJhc2VkDQo+ID4gb24gdGhlIHJlc3VsdCBvZiB0aGUgZGlzY3Vz c2lvbnMuIFdpbGwgcHJvYmFibHkgc2hvdyB1cCBsYXRlciB0b2RheS4NCj4gPg0KPiA+IE91ciBw bGFuIGFzIFdHLWNoYWlycyBpcyB0byBhbGxvdyB0aGUgV0cgYSBmZXcgZGF5cyB0byBxdWlja2x5 IGNoZWNrDQo+ID4gaWYgdGhlIGNoYW5nZXMgYXJlIE9LLiBUaGVuIGFzayBvdXIgQWQgdG8gYnJp bmcgaXQgZm9yd2FyZCB0byBJRVRGDQo+ID4gTGFzdCBDYWxsIGFuZCBJRVNHIHJldmlldy4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPiBCZXJ0IGFuZCBNZWhtZXQNCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KPiA+IGUtbWFpbCBtZXNzYWdlIGF0dGFjaG1lbnQNCj4gPiA+IC0t LS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+ID4gPiBGcm9tOiBJbnRlcm5ldC1E cmFmdHNAaWV0Zi5vcmcNCj4gPiA+IFJlcGx5LXRvOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KPiA+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gQ2M6IG5ldGNvbmZAaWV0 Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3 NDJiaXMtMDMudHh0DQo+ID4gPiBEYXRlOiBXZWQsIDIwIE9jdCAyMDEwIDE3OjAwOjAyICswMjAw DQo+ID4gPg0KPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiA+ID4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcNCj4g R3JvdXAgb2YgdGhlIElFVEYuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IAlUaXRsZSAgICAgICAgICAg OiBVc2luZyB0aGUgTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sIG92ZXINCj4gU2VjdXJl IFNoZWxsIChTU0gpDQo+ID4gPiAJQXV0aG9yKHMpICAgICAgIDogTS4gV2Fzc2VybWFuLCBULiBH b2RkYXJkDQo+ID4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3 NDJiaXMtMDMudHh0DQo+ID4gPiAJUGFnZXMgICAgICAgICAgIDogMTANCj4gPiA+IAlEYXRlICAg ICAgICAgICAgOiAyMDEwLTEwLTIwDQo+ID4gPg0KPiA+ID4gVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBtZXRob2QgZm9yIGludm9raW5nIGFuZCBydW5uaW5nIHRoZQ0KPiBORVRDT05GDQo+ID4g PiBwcm90b2NvbCB3aXRoaW4gYSBTZWN1cmUgU2hlbGwgKFNTSCkgc2Vzc2lvbiBhcyBhbiBTU0gg c3Vic3lzdGVtLg0KPiA+ID4NCj4gPiA+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlz Og0KPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1u ZXRjb25mLXJmYzQ3NDJiaXMtDQo+IDAzLnR4dA0KPiA+ID4NCj4gPiA+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiA+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gPg0KPiA+ID4gQmVsb3cgaXMgdGhlIGRh dGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPiA+ID4g aW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lv biBvZiB0aGUNCj4gPiA+IEludGVybmV0LURyYWZ0Lg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g PiBOZXRjb25mQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90a2EsIENFU05FVA0KPiBQR1Ag S2V5IElEOiBFNzRFOEMwQw0KDQo= From lhotka@cesnet.cz Thu Oct 21 10:08:36 2010 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 CD8C03A69F2 for ; Thu, 21 Oct 2010 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 9w1kZGbiSIDt for ; Thu, 21 Oct 2010 10:08:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id C35953A6A45 for ; Thu, 21 Oct 2010 10:08:34 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id EC5032CDE058; Thu, 21 Oct 2010 19:10:07 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 19:10:06 +0200 Message-ID: <1287681006.1606.106.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 17:08:36 -0000 Hi Mehmet, On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > > [speaking as a contributor] > > if I understand you correctly you want to allow the EOM > not only in comments but also in XML attributes and PIs. > > In case the answer is no: I appear to misunderstand what > you were saying. So pls explain. I certainly don't want to allow anything that isn't already allowed. :-) The current text says, as I understand it, that XML specification doesn't allow the EOM marker to appear outside comments in an XML document (and therefore it is a good choice). But this is not true: XML documents having the sequence in PIs and attribute values are well-formed as well. The only place where the sequence is really forbidden is element text. Lada > > In case the answer is yes: > > Theoretically the EOM sequence can appear everywhere in > an XML document. > > However, the transport layer shouldn't do fine grained > parsing of the XML document, to find out where the > attributes or PIs are. > This is the reason why 4742 kept it simple and, as I > think, appropriate for the transport layer. > > I don't see any difference between XML elements and > [attributes or PI]. They all are XML data. And EOM can > appear in XML data or at the end of the document. > If somebody wants to disrupt the rpc command he can > do it no matter in elements or attributes. > > So, at the end I don't see any benefit in reducing the > restriction and think: > To be on the safe side and to keep it simple for the > implementer of 4742bis the sequence must not appear > in the XML document (except outside of comments). > > [now the chair hat on]: > > Please keep in mind that we don't have the mandate > for v2.0. We are just doing bug-fixing. > > I agree with you that v2.0 should solve this issue > with a thorough solution. Would you like to prepare > a few slides for the NETCONF session in Beijing for > a solution, which could be put later into v2.0? > > Cheers, > Mehmet > > > > -----Original Message----- > > From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > Sent: Wednesday, October 20, 2010 7:23 PM > > To: Ersue, Mehmet (NSN - DE/Munich) > > Cc: Netconf; ext Margaret Wasserman > > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > > RFC4741bis > > > > On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > > Hi All, > > > > > > same is with 4742bis WGLC discusion. We had only minor > > > changes after IETF 78. Our impression is that we have > > > consensus to see the draft as final. > > > > > > Margaret submitted the draft today making it ready for > > > AD review. Please check the changes by 10/22 so that > > > we have a chance to re-submit before deadline. Thanks. > > > > The justification for the EOM marker in sec. 3.1 is technically > > incorrect - and I objected against it previously: > > http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html > > > > Here is the change I propose (there's also a typo in "unambiguously"): > > > > OLD > > > > This character sequence cannot legally appear outside of a comment in > > an > > XML document, so it can be unambigiously used to identify the end of > > the > > current document, allowing resynchronization of the NETCONF exchange in > > the event of an XML syntax or parsing error. > > > > NEW > > > > This character sequence cannot legally appear outside of a comment, > > processing instruction and attribute value in an XML document, so it > > can > > be unambiguously used to identify the end of the current document, > > allowing resynchronization of the NETCONF exchange in the event of an > > XML syntax or parsing error. > > > > Lada > > > > > > > > Cheers, > > > Mehmet > > > > > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > > Behalf Of ext Bert Wijnen (IETF) > > > Sent: Wednesday, October 20, 2010 3:52 PM > > > To: Netconf > > > Subject: [Netconf] status WGLC RFC4741bis > > > > > > It seems that the WGLC discussion has now died out on the mailing > > list. > > > From re-reading all those comments, I also get the impression that > > > there is consensus/agreement on the changes that need to be > > addressed. > > > > > > The editors (specifically Martin) is preparing a new revision based > > > on the result of the discussions. Will probably show up later today. > > > > > > Our plan as WG-chairs is to allow the WG a few days to quickly check > > > if the changes are OK. Then ask our Ad to bring it forward to IETF > > > Last Call and IESG review. > > > > > > Thanks, > > > Bert and Mehmet > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > e-mail message attachment > > > > -------- Forwarded Message -------- > > > > From: Internet-Drafts@ietf.org > > > > Reply-to: > > > > To: i-d-announce@ietf.org > > > > Cc: netconf@ietf.org > > > > Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt > > > > Date: Wed, 20 Oct 2010 17:00:02 +0200 > > > > > > > > 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-03.txt > > > > Pages : 10 > > > > Date : 2010-10-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- > > 03.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 > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Thu Oct 21 11:19:37 2010 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 CE4903A68C8 for ; Thu, 21 Oct 2010 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 dOghfYPjVG9Q for ; Thu, 21 Oct 2010 11:19:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C3D8F3A6975 for ; Thu, 21 Oct 2010 11:19:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9LIL7A8011330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 20:21:07 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9LIL70Z012952; Thu, 21 Oct 2010 20:21:07 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 20:21:07 +0200 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: Thu, 21 Oct 2010 20:21:05 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> In-Reply-To: <1287681006.1606.106.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxQtEJzWJC74Y2S4+q1mxJYNDC1wAAEBTQ References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ladislav Lhotka" X-OriginalArrivalTime: 21 Oct 2010 18:21:07.0647 (UTC) FILETIME=[BAD9A4F0:01CB714C] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:19:37 -0000 SGkgTGFkYSwNCg0KPiBIaSBNZWhtZXQsDQo+IA0KPiBPbiDEjHQsIDIwMTAtMTAtMjEgYXQgMTg6 NDkgKzAyMDAsIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4gd3JvdGU6DQo+ID4g SGkgTGFkYSwNCj4gPg0KPiA+IFtzcGVha2luZyBhcyBhIGNvbnRyaWJ1dG9yXQ0KPiA+DQo+ID4g aWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHkgeW91IHdhbnQgdG8gYWxsb3cgdGhlIEVPTQ0K PiA+IG5vdCBvbmx5IGluIGNvbW1lbnRzIGJ1dCBhbHNvIGluIFhNTCBhdHRyaWJ1dGVzIGFuZCBQ SXMuDQo+ID4NCj4gPiBJbiBjYXNlIHRoZSBhbnN3ZXIgaXMgbm86IEkgYXBwZWFyIHRvIG1pc3Vu ZGVyc3RhbmQgd2hhdA0KPiA+IHlvdSB3ZXJlIHNheWluZy4gU28gcGxzIGV4cGxhaW4uDQo+IA0K PiBJIGNlcnRhaW5seSBkb24ndCB3YW50IHRvIGFsbG93IGFueXRoaW5nIHRoYXQgaXNuJ3QgYWxy ZWFkeSBhbGxvd2VkLiA6LQ0KPiApDQo+IA0KPiBUaGUgY3VycmVudCB0ZXh0IHNheXMsIGFzIEkg dW5kZXJzdGFuZCBpdCwgdGhhdCBYTUwgc3BlY2lmaWNhdGlvbg0KPiBkb2Vzbid0IGFsbG93IHRo ZSBFT00gbWFya2VyIHRvIGFwcGVhciBvdXRzaWRlIGNvbW1lbnRzIGluIGFuIFhNTA0KPiBkb2N1 bWVudCAoYW5kIHRoZXJlZm9yZSBpdCBpcyBhIGdvb2QgY2hvaWNlKS4gQnV0IHRoaXMgaXMgbm90 IHRydWU6IFhNTA0KPiBkb2N1bWVudHMgaGF2aW5nIHRoZSBzZXF1ZW5jZSBpbiBQSXMgYW5kIGF0 dHJpYnV0ZSB2YWx1ZXMgYXJlDQo+IHdlbGwtZm9ybWVkIGFzIHdlbGwuIFRoZSBvbmx5IHBsYWNl IHdoZXJlIHRoZSBzZXF1ZW5jZSBpcyByZWFsbHkNCj4gZm9yYmlkZGVuIGlzIGVsZW1lbnQgdGV4 dC4NCg0KIlRoaXMgY2hhcmFjdGVyIHNlcXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBpbiBh biBYTUwgZG9jdW1lbnQsIHNvDQppdCBjYW4gYmUgdW5hbWJpZ2lvdXNseSB1c2VkIHRvIGluZGVu dGlmeSB0aGUgZW5kIG9mIHRoZSBjdXJyZW50DQpkb2N1bWVudCBpbiB0aGUgZXZlbnQgb2YgYW4g WE1MIHN5bnRheCBvciBwYXJzaW5nIGVycm9yLCBhbGxvd2luZw0KcmVzeW5jaHJvbml6YXRpb24g b2YgdGhlIE5FVENPTkYgZXhjaGFuZ2UuIg0KDQpUaGUgc2VudGVuY2UgaXMgYWN0dWFsbHkgc2lu Y2UgTWF5IDIwMDQgKHYwMSkgaW4gU1NIIGRvY3VtZW50IA0KYW5kIGRpZCBub3QgY2hhbmdlIHVu dGlsIHRvZGF5LiBJIGRvbid0IGtub3cgZXhhY3RseSB3aGF0IHRoZSANCmFpbSBvZiB0aGUgYXV0 aG9ycyB3YXMgdG8gd3JpdGUgaXQgdGhhdCB3YXkuIA0KDQpPbmUgb3B0aW9uIGlzIHRoZXkgd2Fu dGVkIHRvIHN0YXRlIHRoYXQgdGhlIEVPTSAiLi4uIE1VU1QgTk9UIA0KYXBwZWFyIG91dHNpZGUg b2YgYSBjb21tZW50IGluIGFuIFhNTCBkb2N1bWVudCIsIHdoaWNoIHdvdWxkIA0KYmUgYSBjb25z aXN0ZW50IHJlc3RyaWN0aW9uLg0KDQpUaGUgb3RoZXIgb3B0aW9uIGlzIGhvdyB5b3UgdW5kZXJz dGFuZCBpdDoNCiJYTUwgc3BlY2lmaWNhdGlvbiBkb2Vzbid0IGFsbG93IHRoZSBFT00gbWFya2Vy IHRvIGFwcGVhciANCm91dHNpZGUgY29tbWVudHMiDQoNCi4uLndoaWNoIGlzIG9idmlvdXNseSBu b3QgY29ycmVjdCBhbmQgY2FuIGJlIGFkZHJlc3NlZCBhcyANCnlvdSBzdWdnZXN0LiBCdXQgdGhp cyB3b3VsZCBtZWFuIGFkZGl0aW9uYWwgaW1wbGVtZW50YXRpb24gDQplZmZvcnQgZm9yIFNTSCB0 cmFuc3BvcnQuDQoNCk1hcmdhcmV0LCBUZWQsIEFuZHk6IA0KQ2FuIHlvdSBwbGVhc2UgY2xhcmlm eSB3aGF0IHRoZSBvcmlnaW5hbCBhaW0gd2FzPw0KDQpXaGF0IGRvIG90aGVycyBpbiB0aGUgV0cg dGhpbms/DQpQbGVhc2Ugc3RhdGUgeW91ciBvcGluaW9uIGJlZm9yZSBGcmlkYXkgRU9CLg0KDQpN ZWhtZXQNCg0KPiBMYWRhDQo+IA0KPiA+DQo+ID4gSW4gY2FzZSB0aGUgYW5zd2VyIGlzIHllczoN Cj4gPg0KPiA+IFRoZW9yZXRpY2FsbHkgdGhlIEVPTSBzZXF1ZW5jZSBjYW4gYXBwZWFyIGV2ZXJ5 d2hlcmUgaW4NCj4gPiBhbiBYTUwgZG9jdW1lbnQuDQo+ID4NCj4gPiBIb3dldmVyLCB0aGUgdHJh bnNwb3J0IGxheWVyIHNob3VsZG4ndCBkbyBmaW5lIGdyYWluZWQNCj4gPiBwYXJzaW5nIG9mIHRo ZSBYTUwgZG9jdW1lbnQsIHRvIGZpbmQgb3V0IHdoZXJlIHRoZQ0KPiA+IGF0dHJpYnV0ZXMgb3Ig UElzIGFyZS4NCj4gPiBUaGlzIGlzIHRoZSByZWFzb24gd2h5IDQ3NDIga2VwdCBpdCBzaW1wbGUg YW5kLCBhcyBJDQo+ID4gdGhpbmssIGFwcHJvcHJpYXRlIGZvciB0aGUgdHJhbnNwb3J0IGxheWVy Lg0KPiA+DQo+ID4gSSBkb24ndCBzZWUgYW55IGRpZmZlcmVuY2UgYmV0d2VlbiBYTUwgZWxlbWVu dHMgYW5kDQo+ID4gW2F0dHJpYnV0ZXMgb3IgUEldLiBUaGV5IGFsbCBhcmUgWE1MIGRhdGEuIEFu ZCBFT00gY2FuDQo+ID4gYXBwZWFyIGluIFhNTCBkYXRhIG9yIGF0IHRoZSBlbmQgb2YgdGhlIGRv Y3VtZW50Lg0KPiA+IElmIHNvbWVib2R5IHdhbnRzIHRvIGRpc3J1cHQgdGhlIHJwYyBjb21tYW5k IGhlIGNhbg0KPiA+IGRvIGl0IG5vIG1hdHRlciBpbiBlbGVtZW50cyBvciBhdHRyaWJ1dGVzLg0K PiA+DQo+ID4gU28sIGF0IHRoZSBlbmQgSSBkb24ndCBzZWUgYW55IGJlbmVmaXQgaW4gcmVkdWNp bmcgdGhlDQo+ID4gcmVzdHJpY3Rpb24gYW5kIHRoaW5rOg0KPiA+IFRvIGJlIG9uIHRoZSBzYWZl IHNpZGUgYW5kIHRvIGtlZXAgaXQgc2ltcGxlIGZvciB0aGUNCj4gPiBpbXBsZW1lbnRlciBvZiA0 NzQyYmlzIHRoZSBzZXF1ZW5jZSBtdXN0IG5vdCBhcHBlYXINCj4gPiBpbiB0aGUgWE1MIGRvY3Vt ZW50IChleGNlcHQgb3V0c2lkZSBvZiBjb21tZW50cykuDQo+ID4NCj4gPiBbbm93IHRoZSBjaGFp ciBoYXQgb25dOg0KPiA+DQo+ID4gUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHdlIGRvbid0IGhh dmUgdGhlIG1hbmRhdGUNCj4gPiBmb3IgdjIuMC4gV2UgYXJlIGp1c3QgZG9pbmcgYnVnLWZpeGlu Zy4NCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB2Mi4wIHNob3VsZCBzb2x2ZSB0aGlz IGlzc3VlDQo+ID4gd2l0aCBhIHRob3JvdWdoIHNvbHV0aW9uLiBXb3VsZCB5b3UgbGlrZSB0byBw cmVwYXJlDQo+ID4gYSBmZXcgc2xpZGVzIGZvciB0aGUgTkVUQ09ORiBzZXNzaW9uIGluIEJlaWpp bmcgZm9yDQo+ID4gYSBzb2x1dGlvbiwgd2hpY2ggY291bGQgYmUgcHV0IGxhdGVyIGludG8gdjIu MD8NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWhtZXQNCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogZXh0IExhZGlzbGF2IExob3RrYSBbbWFp bHRvOmxob3RrYUBjZXNuZXQuY3pdDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAs IDIwMTAgNzoyMyBQTQ0KPiA+ID4gVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkN Cj4gPiA+IENjOiBOZXRjb25mOyBleHQgTWFyZ2FyZXQgV2Fzc2VybWFuDQo+ID4gPiBTdWJqZWN0 OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dM Qw0KPiA+ID4gUkZDNDc0MWJpcw0KPiA+ID4NCj4gPiA+IE9uIFN0LCAyMDEwLTEwLTIwIGF0IDE4 OjI3ICswMjAwLCBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQo+ID4gPiB3cm90ZToN Cj4gPiA+ID4gSGkgQWxsLA0KPiA+ID4gPg0KPiA+ID4gPiBzYW1lIGlzIHdpdGggNDc0MmJpcyBX R0xDIGRpc2N1c2lvbi4gV2UgaGFkIG9ubHkgbWlub3INCj4gPiA+ID4gY2hhbmdlcyBhZnRlciBJ RVRGIDc4LiBPdXIgaW1wcmVzc2lvbiBpcyB0aGF0IHdlIGhhdmUNCj4gPiA+ID4gY29uc2Vuc3Vz IHRvIHNlZSB0aGUgZHJhZnQgYXMgZmluYWwuDQo+ID4gPiA+DQo+ID4gPiA+IE1hcmdhcmV0IHN1 Ym1pdHRlZCB0aGUgZHJhZnQgdG9kYXkgbWFraW5nIGl0IHJlYWR5IGZvcg0KPiA+ID4gPiBBRCBy ZXZpZXcuIFBsZWFzZSBjaGVjayB0aGUgY2hhbmdlcyBieSAxMC8yMiBzbyB0aGF0DQo+ID4gPiA+ IHdlIGhhdmUgYSBjaGFuY2UgdG8gcmUtc3VibWl0IGJlZm9yZSBkZWFkbGluZS4gVGhhbmtzLg0K PiA+ID4NCj4gPiA+IFRoZSBqdXN0aWZpY2F0aW9uIGZvciB0aGUgRU9NIG1hcmtlciBpbiBzZWMu IDMuMSBpcyB0ZWNobmljYWxseQ0KPiA+ID4gaW5jb3JyZWN0IC0gYW5kIEkgb2JqZWN0ZWQgYWdh aW5zdCBpdCBwcmV2aW91c2x5Og0KPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjI3Ny5odG1sDQo+ID4gPg0KPiA+ID4gSGVyZSBp cyB0aGUgY2hhbmdlIEkgcHJvcG9zZSAodGhlcmUncyBhbHNvIGEgdHlwbyBpbg0KPiAidW5hbWJp Z3VvdXNseSIpOg0KPiA+ID4NCj4gPiA+IE9MRA0KPiA+ID4NCj4gPiA+IFRoaXMgY2hhcmFjdGVy IHNlcXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudA0KPiBp bg0KPiA+ID4gYW4NCj4gPiA+IFhNTCBkb2N1bWVudCwgc28gaXQgY2FuIGJlIHVuYW1iaWdpb3Vz bHkgdXNlZCB0byBpZGVudGlmeSB0aGUgZW5kDQo+IG9mDQo+ID4gPiB0aGUNCj4gPiA+IGN1cnJl bnQgZG9jdW1lbnQsIGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBORVRDT05GDQo+ IGV4Y2hhbmdlIGluDQo+ID4gPiB0aGUgZXZlbnQgb2YgYW4gWE1MIHN5bnRheCBvciBwYXJzaW5n IGVycm9yLg0KPiA+ID4NCj4gPiA+IE5FVw0KPiA+ID4NCj4gPiA+IFRoaXMgY2hhcmFjdGVyIHNl cXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudCwNCj4gPiA+ IHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb24gYW5kIGF0dHJpYnV0ZSB2YWx1ZSBpbiBhbiBYTUwgZG9j dW1lbnQsIHNvDQo+IGl0DQo+ID4gPiBjYW4NCj4gPiA+IGJlIHVuYW1iaWd1b3VzbHkgdXNlZCB0 byBpZGVudGlmeSB0aGUgZW5kIG9mIHRoZSBjdXJyZW50IGRvY3VtZW50LA0KPiA+ID4gYWxsb3dp bmcgcmVzeW5jaHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYgZXhjaGFuZ2UgaW4gdGhlIGV2ZW50 IG9mDQo+IGFuDQo+ID4gPiBYTUwgc3ludGF4IG9yIHBhcnNpbmcgZXJyb3IuDQo+ID4gPg0KPiA+ ID4gTGFkYQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWhtZXQN Cj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+ID4gRnJvbTogbmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnXQ0KPiBPbg0KPiA+ID4gPiBCZWhhbGYgT2YgZXh0IEJlcnQgV2lqbmVuIChJ RVRGKQ0KPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgMzo1MiBQTQ0K PiA+ID4gPiBUbzogTmV0Y29uZg0KPiA+ID4gPiBTdWJqZWN0OiBbTmV0Y29uZl0gc3RhdHVzIFdH TEMgUkZDNDc0MWJpcw0KPiA+ID4gPg0KPiA+ID4gPiBJdCBzZWVtcyB0aGF0IHRoZSBXR0xDIGRp c2N1c3Npb24gaGFzIG5vdyBkaWVkIG91dCBvbiB0aGUgbWFpbGluZw0KPiA+ID4gbGlzdC4NCj4g PiA+ID4gRnJvbSByZS1yZWFkaW5nIGFsbCB0aG9zZSBjb21tZW50cywgSSBhbHNvIGdldCB0aGUg aW1wcmVzc2lvbg0KPiB0aGF0DQo+ID4gPiA+IHRoZXJlIGlzIGNvbnNlbnN1cy9hZ3JlZW1lbnQg b24gdGhlIGNoYW5nZXMgdGhhdCBuZWVkIHRvIGJlDQo+ID4gPiBhZGRyZXNzZWQuDQo+ID4gPiA+ DQo+ID4gPiA+IFRoZSBlZGl0b3JzIChzcGVjaWZpY2FsbHkgTWFydGluKSBpcyBwcmVwYXJpbmcg YSBuZXcgcmV2aXNpb24NCj4gYmFzZWQNCj4gPiA+ID4gb24gdGhlIHJlc3VsdCBvZiB0aGUgZGlz Y3Vzc2lvbnMuIFdpbGwgcHJvYmFibHkgc2hvdyB1cCBsYXRlcg0KPiB0b2RheS4NCj4gPiA+ID4N Cj4gPiA+ID4gT3VyIHBsYW4gYXMgV0ctY2hhaXJzIGlzIHRvIGFsbG93IHRoZSBXRyBhIGZldyBk YXlzIHRvIHF1aWNrbHkNCj4gY2hlY2sNCj4gPiA+ID4gaWYgdGhlIGNoYW5nZXMgYXJlIE9LLiBU aGVuIGFzayBvdXIgQWQgdG8gYnJpbmcgaXQgZm9yd2FyZCB0bw0KPiBJRVRGDQo+ID4gPiA+IExh c3QgQ2FsbCBhbmQgSUVTRyByZXZpZXcuDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcywNCj4gPiA+ ID4gQmVydCBhbmQgTWVobWV0DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiA+ IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQo+ID4gPiA+IGUtbWFpbCBtZXNzYWdlIGF0dGFjaG1lbnQNCj4gPiA+ ID4gPiAtLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KPiA+ID4gPiA+IEZyb206 IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZw0KPiA+ID4gPiA+IFJlcGx5LXRvOiA8aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPg0KPiA+ID4gPiA+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4g PiA+ID4gPiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IEktRCBBY3Rp b246ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMtMDMudHh0DQo+ID4gPiA+ID4gRGF0ZTog V2VkLCAyMCBPY3QgMjAxMCAxNzowMDowMiArMDIwMA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt DQo+IERyYWZ0cw0KPiA+ID4gZGlyZWN0b3JpZXMuDQo+ID4gPiA+ID4gVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcNCj4gPiA+IEdy b3VwIG9mIHRoZSBJRVRGLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAJVGl0bGUg ICAgICAgICAgIDogVXNpbmcgdGhlIE5FVENPTkYgQ29uZmlndXJhdGlvbiBQcm90b2NvbA0KPiBv dmVyDQo+ID4gPiBTZWN1cmUgU2hlbGwgKFNTSCkNCj4gPiA+ID4gPiAJQXV0aG9yKHMpICAgICAg IDogTS4gV2Fzc2VybWFuLCBULiBHb2RkYXJkDQo+ID4gPiA+ID4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTAzLnR4dA0KPiA+ID4gPiA+IAlQYWdlcyAg ICAgICAgICAgOiAxMA0KPiA+ID4gPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDEwLTEwLTIwDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3Ig aW52b2tpbmcgYW5kIHJ1bm5pbmcgdGhlDQo+ID4gPiBORVRDT05GDQo+ID4gPiA+ID4gcHJvdG9j b2wgd2l0aGluIGEgU2VjdXJlIFNoZWxsIChTU0gpIHNlc3Npb24gYXMgYW4gU1NIDQo+IHN1YnN5 c3RlbS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0 IGlzOg0KPiA+ID4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtbmV0Y29uZi0NCj4gcmZjNDc0MmJpcy0NCj4gPiA+IDAzLnR4dA0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPiA+ID4gPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBh IE1JTUUgY29tcGxpYW50IG1haWwNCj4gcmVhZGVyDQo+ID4gPiA+ID4gaW1wbGVtZW50YXRpb24g dG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZg0KPiB0aGUNCj4g PiA+ID4gPiBJbnRlcm5ldC1EcmFmdC4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g PiA+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ID4gTGFkaXNsYXYgTGhv dGthLCBDRVNORVQNCj4gPiA+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ID4NCj4gDQo+IC0tDQo+ IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg== From j.schoenwaelder@jacobs-university.de Thu Oct 21 11:25:07 2010 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 2D3DB3A6A4C for ; Thu, 21 Oct 2010 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0dOS+cPWvYKZ for ; Thu, 21 Oct 2010 11:25:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1BA83A6835 for ; Thu, 21 Oct 2010 11:25:05 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6097DC0008; Thu, 21 Oct 2010 20:26:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LroI2JqAky9U; Thu, 21 Oct 2010 20:26:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB9ABC0002; Thu, 21 Oct 2010 20:26:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D72A6156C2D4; Thu, 21 Oct 2010 20:26:00 +0200 (CEST) Date: Thu, 21 Oct 2010 20:26:00 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101021182600.GB27772@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Ersue, Mehmet (NSN - DE/Munich)" , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1287681006.1606.106.camel@missotis> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:25:07 -0000 On Thu, Oct 21, 2010 at 07:10:06PM +0200, Ladislav Lhotka wrote: > Hi Mehmet, > > On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Lada, > > > > [speaking as a contributor] > > > > if I understand you correctly you want to allow the EOM > > not only in comments but also in XML attributes and PIs. > > > > In case the answer is no: I appear to misunderstand what > > you were saying. So pls explain. > > I certainly don't want to allow anything that isn't already allowed. :-) > > The current text says, as I understand it, that XML specification > doesn't allow the EOM marker to appear outside comments in an XML > document (and therefore it is a good choice). But this is not true: XML > documents having the sequence in PIs and attribute values are > well-formed as well. The only place where the sequence is really > forbidden is element text. I think Lada has a valid point here. However, I do not like his rewrite - the "so it can be unambiguously used" part. What about this: This character sequence cannot legally appear outside of a comment, processing instruction and attribute value in an XML document. If the XML content carried by NETCONF does not include comments, processing instructions, or attribute values, this character sequence can be used to resynchronize a NETCONF exchange in the event of an XML syntax or parsing error. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Thu Oct 21 11:39:15 2010 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 32DBF3A689B for ; Thu, 21 Oct 2010 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 gAD-PRq0vUSm for ; Thu, 21 Oct 2010 11:39:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 841CA3A6866 for ; Thu, 21 Oct 2010 11:39:13 -0700 (PDT) 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 o9LIelu1025639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 20:40:47 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9LIeloI006148; Thu, 21 Oct 2010 20:40:47 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 20:40:46 +0200 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: Thu, 21 Oct 2010 20:40:45 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E53C9@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101021182600.GB27772@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxTYL5kPQHWHg/QcOhWNpPAxxoSgAAZcIA References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <20101021182600.GB27772@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Ladislav Lhotka" X-OriginalArrivalTime: 21 Oct 2010 18:40:46.0921 (UTC) FILETIME=[79C09390:01CB714F] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:39:15 -0000 PiA+IFRoZSBjdXJyZW50IHRleHQgc2F5cywgYXMgSSB1bmRlcnN0YW5kIGl0LCB0aGF0IFhNTCBz cGVjaWZpY2F0aW9uDQo+ID4gZG9lc24ndCBhbGxvdyB0aGUgRU9NIG1hcmtlciB0byBhcHBlYXIg b3V0c2lkZSBjb21tZW50cyBpbiBhbiBYTUwNCj4gPiBkb2N1bWVudCAoYW5kIHRoZXJlZm9yZSBp dCBpcyBhIGdvb2QgY2hvaWNlKS4gQnV0IHRoaXMgaXMgbm90IHRydWU6DQo+IFhNTA0KPiA+IGRv Y3VtZW50cyBoYXZpbmcgdGhlIHNlcXVlbmNlIGluIFBJcyBhbmQgYXR0cmlidXRlIHZhbHVlcyBh cmUNCj4gPiB3ZWxsLWZvcm1lZCBhcyB3ZWxsLiBUaGUgb25seSBwbGFjZSB3aGVyZSB0aGUgc2Vx dWVuY2UgaXMgcmVhbGx5DQo+ID4gZm9yYmlkZGVuIGlzIGVsZW1lbnQgdGV4dC4NCj4gDQo+IEkg dGhpbmsgTGFkYSBoYXMgYSB2YWxpZCBwb2ludCBoZXJlLiBIb3dldmVyLCBJIGRvIG5vdCBsaWtl IGhpcw0KPiByZXdyaXRlIC0gdGhlICJzbyBpdCBjYW4gYmUgdW5hbWJpZ3VvdXNseSB1c2VkIiBw YXJ0LiBXaGF0IGFib3V0DQo+IHRoaXM6DQo+IA0KPiAgIFRoaXMgY2hhcmFjdGVyIHNlcXVlbmNl IGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudCwNCj4gICBwcm9jZXNz aW5nIGluc3RydWN0aW9uIGFuZCBhdHRyaWJ1dGUgdmFsdWUgaW4gYW4gWE1MIGRvY3VtZW50LiAg SWYNCj4gICB0aGUgWE1MIGNvbnRlbnQgY2FycmllZCBieSBORVRDT05GIGRvZXMgbm90IGluY2x1 ZGUgY29tbWVudHMsDQo+ICAgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMsIG9yIGF0dHJpYnV0ZSB2 YWx1ZXMsIHRoaXMgY2hhcmFjdGVyDQo+ICAgc2VxdWVuY2UgY2FuIGJlIHVzZWQgdG8gcmVzeW5j aHJvbml6ZSBhIE5FVENPTkYgZXhjaGFuZ2UgaW4gdGhlDQo+ICAgZXZlbnQgb2YgYW4gWE1MIHN5 bnRheCBvciBwYXJzaW5nIGVycm9yLg0KDQpJIHRlbmQgdG8gYWdyZWUuIEJ1dCB3ZSBzdGlsbCBu ZWVkIHRvIGRlZmluZSB3aGF0IGhhcHBlbnMgaWYgDQp0aGUgWE1MIGNvbnRlbnQgY2FycmllZCBi eSBORVRDT05GICJkb2VzIiBpbmNsdWRlIGNvbW1lbnRzLA0KcHJvY2Vzc2luZyBpbnN0cnVjdGlv bnMsIG9yIGF0dHJpYnV0ZSB2YWx1ZXMuDQoNCk1laG1ldA0KDQo= From lhotka@cesnet.cz Thu Oct 21 11:40:58 2010 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 D532C3A689B for ; Thu, 21 Oct 2010 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 uHmBTe1zOAtp for ; Thu, 21 Oct 2010 11:40:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id EE5993A6866 for ; Thu, 21 Oct 2010 11:40:56 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3108D2CDE058; Thu, 21 Oct 2010 20:42:32 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 20:42:30 +0200 Message-ID: <1287686550.1606.117.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:40:58 -0000 On Čt, 2010-10-21 at 20:21 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > > > Hi Mehmet, > > > > On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > > Hi Lada, > > > > > > [speaking as a contributor] > > > > > > if I understand you correctly you want to allow the EOM > > > not only in comments but also in XML attributes and PIs. > > > > > > In case the answer is no: I appear to misunderstand what > > > you were saying. So pls explain. > > > > I certainly don't want to allow anything that isn't already allowed. :- > > ) > > > > The current text says, as I understand it, that XML specification > > doesn't allow the EOM marker to appear outside comments in an XML > > document (and therefore it is a good choice). But this is not true: XML > > documents having the sequence in PIs and attribute values are > > well-formed as well. The only place where the sequence is really > > forbidden is element text. > > "This character sequence cannot legally appear in an XML document, so > it can be unambigiously used to indentify the end of the current > document in the event of an XML syntax or parsing error, allowing > resynchronization of the NETCONF exchange." > > The sentence is actually since May 2004 (v01) in SSH document > and did not change until today. I don't know exactly what the > aim of the authors was to write it that way. Actually, RFC 4742 has this: "This character sequence cannot legally appear in an XML document, ..." So it really looks like slippery slope. Lada > > One option is they wanted to state that the EOM "... MUST NOT > appear outside of a comment in an XML document", which would > be a consistent restriction. > > The other option is how you understand it: > "XML specification doesn't allow the EOM marker to appear > outside comments" > > ...which is obviously not correct and can be addressed as > you suggest. But this would mean additional implementation > effort for SSH transport. > > Margaret, Ted, Andy: > Can you please clarify what the original aim was? > > What do others in the WG think? > Please state your opinion before Friday EOB. > > Mehmet > > > Lada > > > > > > > > In case the answer is yes: > > > > > > Theoretically the EOM sequence can appear everywhere in > > > an XML document. > > > > > > However, the transport layer shouldn't do fine grained > > > parsing of the XML document, to find out where the > > > attributes or PIs are. > > > This is the reason why 4742 kept it simple and, as I > > > think, appropriate for the transport layer. > > > > > > I don't see any difference between XML elements and > > > [attributes or PI]. They all are XML data. And EOM can > > > appear in XML data or at the end of the document. > > > If somebody wants to disrupt the rpc command he can > > > do it no matter in elements or attributes. > > > > > > So, at the end I don't see any benefit in reducing the > > > restriction and think: > > > To be on the safe side and to keep it simple for the > > > implementer of 4742bis the sequence must not appear > > > in the XML document (except outside of comments). > > > > > > [now the chair hat on]: > > > > > > Please keep in mind that we don't have the mandate > > > for v2.0. We are just doing bug-fixing. > > > > > > I agree with you that v2.0 should solve this issue > > > with a thorough solution. Would you like to prepare > > > a few slides for the NETCONF session in Beijing for > > > a solution, which could be put later into v2.0? > > > > > > Cheers, > > > Mehmet > > > > > > > > > > -----Original Message----- > > > > From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > > > Sent: Wednesday, October 20, 2010 7:23 PM > > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > > Cc: Netconf; ext Margaret Wasserman > > > > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > > > > RFC4741bis > > > > > > > > On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) > > > > wrote: > > > > > Hi All, > > > > > > > > > > same is with 4742bis WGLC discusion. We had only minor > > > > > changes after IETF 78. Our impression is that we have > > > > > consensus to see the draft as final. > > > > > > > > > > Margaret submitted the draft today making it ready for > > > > > AD review. Please check the changes by 10/22 so that > > > > > we have a chance to re-submit before deadline. Thanks. > > > > > > > > The justification for the EOM marker in sec. 3.1 is technically > > > > incorrect - and I objected against it previously: > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html > > > > > > > > Here is the change I propose (there's also a typo in > > "unambiguously"): > > > > > > > > OLD > > > > > > > > This character sequence cannot legally appear outside of a comment > > in > > > > an > > > > XML document, so it can be unambigiously used to identify the end > > of > > > > the > > > > current document, allowing resynchronization of the NETCONF > > exchange in > > > > the event of an XML syntax or parsing error. > > > > > > > > NEW > > > > > > > > This character sequence cannot legally appear outside of a comment, > > > > processing instruction and attribute value in an XML document, so > > it > > > > can > > > > be unambiguously used to identify the end of the current document, > > > > allowing resynchronization of the NETCONF exchange in the event of > > an > > > > XML syntax or parsing error. > > > > > > > > Lada > > > > > > > > > > > > > > Cheers, > > > > > Mehmet > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > > On > > > > > Behalf Of ext Bert Wijnen (IETF) > > > > > Sent: Wednesday, October 20, 2010 3:52 PM > > > > > To: Netconf > > > > > Subject: [Netconf] status WGLC RFC4741bis > > > > > > > > > > It seems that the WGLC discussion has now died out on the mailing > > > > list. > > > > > From re-reading all those comments, I also get the impression > > that > > > > > there is consensus/agreement on the changes that need to be > > > > addressed. > > > > > > > > > > The editors (specifically Martin) is preparing a new revision > > based > > > > > on the result of the discussions. Will probably show up later > > today. > > > > > > > > > > Our plan as WG-chairs is to allow the WG a few days to quickly > > check > > > > > if the changes are OK. Then ask our Ad to bring it forward to > > IETF > > > > > Last Call and IESG review. > > > > > > > > > > Thanks, > > > > > Bert and Mehmet > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > e-mail message attachment > > > > > > -------- Forwarded Message -------- > > > > > > From: Internet-Drafts@ietf.org > > > > > > Reply-to: > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: netconf@ietf.org > > > > > > Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt > > > > > > Date: Wed, 20 Oct 2010 17:00:02 +0200 > > > > > > > > > > > > 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-03.txt > > > > > > Pages : 10 > > > > > > Date : 2010-10-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- > > > > 03.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 > > > > > > > > -- > > > > Ladislav Lhotka, CESNET > > > > PGP Key ID: E74E8C0C > > > > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Oct 21 11:49:55 2010 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 AF6233A67B7 for ; Thu, 21 Oct 2010 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 h2rk0S9gRgeU for ; Thu, 21 Oct 2010 11:49:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 70EF53A6452 for ; Thu, 21 Oct 2010 11:49:54 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9C20A2CDE058; Thu, 21 Oct 2010 20:51:29 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101021182600.GB27772@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <20101021182600.GB27772@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 20:51:28 +0200 Message-ID: <1287687088.1606.122.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:49:55 -0000 On Čt, 2010-10-21 at 20:26 +0200, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 07:10:06PM +0200, Ladislav Lhotka wrote: > > Hi Mehmet, > > > > On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Hi Lada, > > > > > > [speaking as a contributor] > > > > > > if I understand you correctly you want to allow the EOM > > > not only in comments but also in XML attributes and PIs. > > > > > > In case the answer is no: I appear to misunderstand what > > > you were saying. So pls explain. > > > > I certainly don't want to allow anything that isn't already allowed. :-) > > > > The current text says, as I understand it, that XML specification > > doesn't allow the EOM marker to appear outside comments in an XML > > document (and therefore it is a good choice). But this is not true: XML > > documents having the sequence in PIs and attribute values are > > well-formed as well. The only place where the sequence is really > > forbidden is element text. > > I think Lada has a valid point here. However, I do not like his > rewrite - the "so it can be unambiguously used" part. What about I agree, the unambiguity now looks like a bad joke, but that has been my point for quite some time, too. > this: > > This character sequence cannot legally appear outside of a comment, > processing instruction and attribute value in an XML document. If > the XML content carried by NETCONF does not include comments, > processing instructions, or attribute values, this character > sequence can be used to resynchronize a NETCONF exchange in the > event of an XML syntax or parsing error. The Messages layer uses XML attributes by definition. For example, a really nasty (but compliant) client may use "]]>]]>" as a message-id. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Thu Oct 21 11:50:24 2010 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 97A5E3A6A84 for ; Thu, 21 Oct 2010 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.178, 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 WaTTiv-WPoFY for ; Thu, 21 Oct 2010 11:50:21 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 2B93A3A6A62 for ; Thu, 21 Oct 2010 11:50:19 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LIpBTJ008935; Thu, 21 Oct 2010 11:51:47 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s2u1k803r-42 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 11:51:46 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 11:55:55 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 21 Oct 2010 11:51:35 -0700 From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Ladislav Lhotka" Date: Thu, 21 Oct 2010 11:51:34 -0700 Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxQtEJzWJC74Y2S4+q1mxJYNDC1wAAEBTQAALQ+NA= Message-ID: References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-21_09:2010-10-21, 2010-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210150 X-Proofpoint-SSN: Sensitivity2 Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 18:50:24 -0000 SGksDQoNClRoZSBvcmlnaW5hbCBpbnRlbnQgd2FzIHRvIHVzZSBhIGNoYXIgc2VxdWVuY2UgdGhh dCB3YXMgbm90IGxlZ2FsIGluDQphbiBYTUwgaW5zdGFuY2UgZG9jdW1lbnQuICBOb2JvZHkgaW4g dGhlIFdHIGF0IHRoZSB0aW1lIGtuZXcgZm9yIHN1cmUsDQpzbyB3ZSBhc2tlZCB0aGUgWE1MIERp cmVjdG9yYXRlLiAgV2Ugd29ya2VkIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQNCnRoZSBdXT5d XT4gc2VxdWVuY2Ugd2FzIGEgc3VpdGFibGUgbWVzc2FnZSBib3VuZGFyeSBtYXJrZXIuDQoNCkkg d291bGQgbGlrZSB0byBoZWFyIGV2aWRlbmNlIHRoYXQgdGhpcyBFT00gc2VxdWVuY2UgaXMgY2F1 c2luZyBwcm9ibGVtcw0KZm9yIG9wZXJhdG9ycyB1c2luZyBORVRDT05GLiAgSXMgdGhpcyByZWFs bHkgYSBjb25jZXJuIHRvIG9wZXJhdG9ycz8NCldvdWxkIGEgc2lnbmlmaWNhbnQgcHJvdG9jb2wg Y2hhbmdlIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSBjYXVzZSBtb3JlDQpvcGVyYXRpb25hbCBwcm9i bGVtcyB0aGFuIGl0IHNvbHZlcz8NCg0KSSBkbyBub3QgYWdyZWUgdGhhdCB0aGlzIG11c3QgYmUg Zml4ZWQgaW4gTkVUQ09ORiAyLjAsIHdoZW5ldmVyIHRoYXQgaXMuDQpXZSBzaG91bGQgZGVjaWRl IGF0IHRoZSB0aW1lLCBhZnRlciBzb21lIG1vcmUgZGVwbG95bWVudCBleHBlcmllbmNlLg0KDQoN CkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMjEsIDIwMTAgMTE6MjEgQU0NClRvOiBleHQgTGFkaXNsYXYgTGhvdGthDQpDYzogZXh0IE1h cmdhcmV0IFdhc3Nlcm1hbjsgTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBTdGF0dXMg V0dMQyBSRkM0NzQyYmlzIFdBUzpGVzogc3RhdHVzIFdHTEMgUkZDNDc0MWJpcw0KDQpIaSBMYWRh LA0KDQo+IEhpIE1laG1ldCwNCj4gDQo+IE9uIMSMdCwgMjAxMC0xMC0yMSBhdCAxODo0OSArMDIw MCwgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiB3cm90ZToNCj4gPiBIaSBMYWRh LA0KPiA+DQo+ID4gW3NwZWFraW5nIGFzIGEgY29udHJpYnV0b3JdDQo+ID4NCj4gPiBpZiBJIHVu ZGVyc3RhbmQgeW91IGNvcnJlY3RseSB5b3Ugd2FudCB0byBhbGxvdyB0aGUgRU9NDQo+ID4gbm90 IG9ubHkgaW4gY29tbWVudHMgYnV0IGFsc28gaW4gWE1MIGF0dHJpYnV0ZXMgYW5kIFBJcy4NCj4g Pg0KPiA+IEluIGNhc2UgdGhlIGFuc3dlciBpcyBubzogSSBhcHBlYXIgdG8gbWlzdW5kZXJzdGFu ZCB3aGF0DQo+ID4geW91IHdlcmUgc2F5aW5nLiBTbyBwbHMgZXhwbGFpbi4NCj4gDQo+IEkgY2Vy dGFpbmx5IGRvbid0IHdhbnQgdG8gYWxsb3cgYW55dGhpbmcgdGhhdCBpc24ndCBhbHJlYWR5IGFs bG93ZWQuIDotDQo+ICkNCj4gDQo+IFRoZSBjdXJyZW50IHRleHQgc2F5cywgYXMgSSB1bmRlcnN0 YW5kIGl0LCB0aGF0IFhNTCBzcGVjaWZpY2F0aW9uDQo+IGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBt YXJrZXIgdG8gYXBwZWFyIG91dHNpZGUgY29tbWVudHMgaW4gYW4gWE1MDQo+IGRvY3VtZW50IChh bmQgdGhlcmVmb3JlIGl0IGlzIGEgZ29vZCBjaG9pY2UpLiBCdXQgdGhpcyBpcyBub3QgdHJ1ZTog WE1MDQo+IGRvY3VtZW50cyBoYXZpbmcgdGhlIHNlcXVlbmNlIGluIFBJcyBhbmQgYXR0cmlidXRl IHZhbHVlcyBhcmUNCj4gd2VsbC1mb3JtZWQgYXMgd2VsbC4gVGhlIG9ubHkgcGxhY2Ugd2hlcmUg dGhlIHNlcXVlbmNlIGlzIHJlYWxseQ0KPiBmb3JiaWRkZW4gaXMgZWxlbWVudCB0ZXh0Lg0KDQoi VGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIGluIGFuIFhNTCBk b2N1bWVudCwgc28NCml0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8gaW5kZW50aWZ5IHRo ZSBlbmQgb2YgdGhlIGN1cnJlbnQNCmRvY3VtZW50IGluIHRoZSBldmVudCBvZiBhbiBYTUwgc3lu dGF4IG9yIHBhcnNpbmcgZXJyb3IsIGFsbG93aW5nDQpyZXN5bmNocm9uaXphdGlvbiBvZiB0aGUg TkVUQ09ORiBleGNoYW5nZS4iDQoNClRoZSBzZW50ZW5jZSBpcyBhY3R1YWxseSBzaW5jZSBNYXkg MjAwNCAodjAxKSBpbiBTU0ggZG9jdW1lbnQgDQphbmQgZGlkIG5vdCBjaGFuZ2UgdW50aWwgdG9k YXkuIEkgZG9uJ3Qga25vdyBleGFjdGx5IHdoYXQgdGhlIA0KYWltIG9mIHRoZSBhdXRob3JzIHdh cyB0byB3cml0ZSBpdCB0aGF0IHdheS4gDQoNCk9uZSBvcHRpb24gaXMgdGhleSB3YW50ZWQgdG8g c3RhdGUgdGhhdCB0aGUgRU9NICIuLi4gTVVTVCBOT1QgDQphcHBlYXIgb3V0c2lkZSBvZiBhIGNv bW1lbnQgaW4gYW4gWE1MIGRvY3VtZW50Iiwgd2hpY2ggd291bGQgDQpiZSBhIGNvbnNpc3RlbnQg cmVzdHJpY3Rpb24uDQoNClRoZSBvdGhlciBvcHRpb24gaXMgaG93IHlvdSB1bmRlcnN0YW5kIGl0 Og0KIlhNTCBzcGVjaWZpY2F0aW9uIGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8gYXBw ZWFyIA0Kb3V0c2lkZSBjb21tZW50cyINCg0KLi4ud2hpY2ggaXMgb2J2aW91c2x5IG5vdCBjb3Jy ZWN0IGFuZCBjYW4gYmUgYWRkcmVzc2VkIGFzIA0KeW91IHN1Z2dlc3QuIEJ1dCB0aGlzIHdvdWxk IG1lYW4gYWRkaXRpb25hbCBpbXBsZW1lbnRhdGlvbiANCmVmZm9ydCBmb3IgU1NIIHRyYW5zcG9y dC4NCg0KTWFyZ2FyZXQsIFRlZCwgQW5keTogDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQg dGhlIG9yaWdpbmFsIGFpbSB3YXM/DQoNCldoYXQgZG8gb3RoZXJzIGluIHRoZSBXRyB0aGluaz8N ClBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYmVmb3JlIEZyaWRheSBFT0IuDQoNCk1laG1ldA0K DQo+IExhZGENCj4gDQo+ID4NCj4gPiBJbiBjYXNlIHRoZSBhbnN3ZXIgaXMgeWVzOg0KPiA+DQo+ ID4gVGhlb3JldGljYWxseSB0aGUgRU9NIHNlcXVlbmNlIGNhbiBhcHBlYXIgZXZlcnl3aGVyZSBp bg0KPiA+IGFuIFhNTCBkb2N1bWVudC4NCj4gPg0KPiA+IEhvd2V2ZXIsIHRoZSB0cmFuc3BvcnQg bGF5ZXIgc2hvdWxkbid0IGRvIGZpbmUgZ3JhaW5lZA0KPiA+IHBhcnNpbmcgb2YgdGhlIFhNTCBk b2N1bWVudCwgdG8gZmluZCBvdXQgd2hlcmUgdGhlDQo+ID4gYXR0cmlidXRlcyBvciBQSXMgYXJl Lg0KPiA+IFRoaXMgaXMgdGhlIHJlYXNvbiB3aHkgNDc0MiBrZXB0IGl0IHNpbXBsZSBhbmQsIGFz IEkNCj4gPiB0aGluaywgYXBwcm9wcmlhdGUgZm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQo+ID4N Cj4gPiBJIGRvbid0IHNlZSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIFhNTCBlbGVtZW50cyBhbmQN Cj4gPiBbYXR0cmlidXRlcyBvciBQSV0uIFRoZXkgYWxsIGFyZSBYTUwgZGF0YS4gQW5kIEVPTSBj YW4NCj4gPiBhcHBlYXIgaW4gWE1MIGRhdGEgb3IgYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQu DQo+ID4gSWYgc29tZWJvZHkgd2FudHMgdG8gZGlzcnVwdCB0aGUgcnBjIGNvbW1hbmQgaGUgY2Fu DQo+ID4gZG8gaXQgbm8gbWF0dGVyIGluIGVsZW1lbnRzIG9yIGF0dHJpYnV0ZXMuDQo+ID4NCj4g PiBTbywgYXQgdGhlIGVuZCBJIGRvbid0IHNlZSBhbnkgYmVuZWZpdCBpbiByZWR1Y2luZyB0aGUN Cj4gPiByZXN0cmljdGlvbiBhbmQgdGhpbms6DQo+ID4gVG8gYmUgb24gdGhlIHNhZmUgc2lkZSBh bmQgdG8ga2VlcCBpdCBzaW1wbGUgZm9yIHRoZQ0KPiA+IGltcGxlbWVudGVyIG9mIDQ3NDJiaXMg dGhlIHNlcXVlbmNlIG11c3Qgbm90IGFwcGVhcg0KPiA+IGluIHRoZSBYTUwgZG9jdW1lbnQgKGV4 Y2VwdCBvdXRzaWRlIG9mIGNvbW1lbnRzKS4NCj4gPg0KPiA+IFtub3cgdGhlIGNoYWlyIGhhdCBv bl06DQo+ID4NCj4gPiBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0aGUg bWFuZGF0ZQ0KPiA+IGZvciB2Mi4wLiBXZSBhcmUganVzdCBkb2luZyBidWctZml4aW5nLg0KPiA+ DQo+ID4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHYyLjAgc2hvdWxkIHNvbHZlIHRoaXMgaXNzdWUN Cj4gPiB3aXRoIGEgdGhvcm91Z2ggc29sdXRpb24uIFdvdWxkIHlvdSBsaWtlIHRvIHByZXBhcmUN Cj4gPiBhIGZldyBzbGlkZXMgZm9yIHRoZSBORVRDT05GIHNlc3Npb24gaW4gQmVpamluZyBmb3IN Cj4gPiBhIHNvbHV0aW9uLCB3aGljaCBjb3VsZCBiZSBwdXQgbGF0ZXIgaW50byB2Mi4wPw0KPiA+ DQo+ID4gQ2hlZXJzLA0KPiA+IE1laG1ldA0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBleHQgTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhv dGthQGNlc25ldC5jel0NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMCwgMjAxMCA3 OjIzIFBNDQo+ID4gPiBUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiA+ID4g Q2M6IE5ldGNvbmY7IGV4dCBNYXJnYXJldCBXYXNzZXJtYW4NCj4gPiA+IFN1YmplY3Q6IFJlOiBb TmV0Y29uZl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDDQo+ID4g PiBSRkM0NzQxYmlzDQo+ID4gPg0KPiA+ID4gT24gU3QsIDIwMTAtMTAtMjAgYXQgMTg6MjcgKzAy MDAsIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4gPiA+IHdyb3RlOg0KPiA+ID4g PiBIaSBBbGwsDQo+ID4gPiA+DQo+ID4gPiA+IHNhbWUgaXMgd2l0aCA0NzQyYmlzIFdHTEMgZGlz Y3VzaW9uLiBXZSBoYWQgb25seSBtaW5vcg0KPiA+ID4gPiBjaGFuZ2VzIGFmdGVyIElFVEYgNzgu IE91ciBpbXByZXNzaW9uIGlzIHRoYXQgd2UgaGF2ZQ0KPiA+ID4gPiBjb25zZW5zdXMgdG8gc2Vl IHRoZSBkcmFmdCBhcyBmaW5hbC4NCj4gPiA+ID4NCj4gPiA+ID4gTWFyZ2FyZXQgc3VibWl0dGVk IHRoZSBkcmFmdCB0b2RheSBtYWtpbmcgaXQgcmVhZHkgZm9yDQo+ID4gPiA+IEFEIHJldmlldy4g UGxlYXNlIGNoZWNrIHRoZSBjaGFuZ2VzIGJ5IDEwLzIyIHNvIHRoYXQNCj4gPiA+ID4gd2UgaGF2 ZSBhIGNoYW5jZSB0byByZS1zdWJtaXQgYmVmb3JlIGRlYWRsaW5lLiBUaGFua3MuDQo+ID4gPg0K PiA+ID4gVGhlIGp1c3RpZmljYXRpb24gZm9yIHRoZSBFT00gbWFya2VyIGluIHNlYy4gMy4xIGlz IHRlY2huaWNhbGx5DQo+ID4gPiBpbmNvcnJlY3QgLSBhbmQgSSBvYmplY3RlZCBhZ2FpbnN0IGl0 IHByZXZpb3VzbHk6DQo+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bmV0Y29uZi9jdXJyZW50L21zZzA2Mjc3Lmh0bWwNCj4gPiA+DQo+ID4gPiBIZXJlIGlzIHRoZSBj aGFuZ2UgSSBwcm9wb3NlICh0aGVyZSdzIGFsc28gYSB0eXBvIGluDQo+ICJ1bmFtYmlndW91c2x5 Iik6DQo+ID4gPg0KPiA+ID4gT0xEDQo+ID4gPg0KPiA+ID4gVGhpcyBjaGFyYWN0ZXIgc2VxdWVu Y2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUgb2YgYSBjb21tZW50DQo+IGluDQo+ID4g PiBhbg0KPiA+ID4gWE1MIGRvY3VtZW50LCBzbyBpdCBjYW4gYmUgdW5hbWJpZ2lvdXNseSB1c2Vk IHRvIGlkZW50aWZ5IHRoZSBlbmQNCj4gb2YNCj4gPiA+IHRoZQ0KPiA+ID4gY3VycmVudCBkb2N1 bWVudCwgYWxsb3dpbmcgcmVzeW5jaHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYNCj4gZXhjaGFu Z2UgaW4NCj4gPiA+IHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNpbmcgZXJyb3Iu DQo+ID4gPg0KPiA+ID4gTkVXDQo+ID4gPg0KPiA+ID4gVGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2Ug Y2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUgb2YgYSBjb21tZW50LA0KPiA+ID4gcHJvY2Vz c2luZyBpbnN0cnVjdGlvbiBhbmQgYXR0cmlidXRlIHZhbHVlIGluIGFuIFhNTCBkb2N1bWVudCwg c28NCj4gaXQNCj4gPiA+IGNhbg0KPiA+ID4gYmUgdW5hbWJpZ3VvdXNseSB1c2VkIHRvIGlkZW50 aWZ5IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgZG9jdW1lbnQsDQo+ID4gPiBhbGxvd2luZyByZXN5 bmNocm9uaXphdGlvbiBvZiB0aGUgTkVUQ09ORiBleGNoYW5nZSBpbiB0aGUgZXZlbnQgb2YNCj4g YW4NCj4gPiA+IFhNTCBzeW50YXggb3IgcGFyc2luZyBlcnJvci4NCj4gPiA+DQo+ID4gPiBMYWRh DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+IE1laG1ldA0KPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBG cm9tOiBuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmddDQo+IE9uDQo+ID4gPiA+IEJlaGFsZiBPZiBleHQgQmVydCBXaWpuZW4gKElFVEYpDQo+ ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMCwgMjAxMCAzOjUyIFBNDQo+ID4gPiA+ IFRvOiBOZXRjb25mDQo+ID4gPiA+IFN1YmplY3Q6IFtOZXRjb25mXSBzdGF0dXMgV0dMQyBSRkM0 NzQxYmlzDQo+ID4gPiA+DQo+ID4gPiA+IEl0IHNlZW1zIHRoYXQgdGhlIFdHTEMgZGlzY3Vzc2lv biBoYXMgbm93IGRpZWQgb3V0IG9uIHRoZSBtYWlsaW5nDQo+ID4gPiBsaXN0Lg0KPiA+ID4gPiBG cm9tIHJlLXJlYWRpbmcgYWxsIHRob3NlIGNvbW1lbnRzLCBJIGFsc28gZ2V0IHRoZSBpbXByZXNz aW9uDQo+IHRoYXQNCj4gPiA+ID4gdGhlcmUgaXMgY29uc2Vuc3VzL2FncmVlbWVudCBvbiB0aGUg Y2hhbmdlcyB0aGF0IG5lZWQgdG8gYmUNCj4gPiA+IGFkZHJlc3NlZC4NCj4gPiA+ID4NCj4gPiA+ ID4gVGhlIGVkaXRvcnMgKHNwZWNpZmljYWxseSBNYXJ0aW4pIGlzIHByZXBhcmluZyBhIG5ldyBy ZXZpc2lvbg0KPiBiYXNlZA0KPiA+ID4gPiBvbiB0aGUgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9u cy4gV2lsbCBwcm9iYWJseSBzaG93IHVwIGxhdGVyDQo+IHRvZGF5Lg0KPiA+ID4gPg0KPiA+ID4g PiBPdXIgcGxhbiBhcyBXRy1jaGFpcnMgaXMgdG8gYWxsb3cgdGhlIFdHIGEgZmV3IGRheXMgdG8g cXVpY2tseQ0KPiBjaGVjaw0KPiA+ID4gPiBpZiB0aGUgY2hhbmdlcyBhcmUgT0suIFRoZW4gYXNr IG91ciBBZCB0byBicmluZyBpdCBmb3J3YXJkIHRvDQo+IElFVEYNCj4gPiA+ID4gTGFzdCBDYWxs IGFuZCBJRVNHIHJldmlldy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiBCZXJ0 IGFuZCBNZWhtZXQNCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gTmV0Y29u ZkBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYNCj4gPiA+ID4gZS1tYWlsIG1lc3NhZ2UgYXR0YWNobWVudA0KPiA+ID4gPiA+IC0t LS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogSW50ZXJu ZXQtRHJhZnRzQGlldGYub3JnDQo+ID4gPiA+ID4gUmVwbHktdG86IDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQo+ID4gPiA+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gPiA+ IENjOiBuZXRjb25mQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogSS1EIEFjdGlvbjpkcmFm dC1pZXRmLW5ldGNvbmYtcmZjNDc0MmJpcy0wMy50eHQNCj4gPiA+ID4gPiBEYXRlOiBXZWQsIDIw IE9jdCAyMDEwIDE3OjAwOjAyICswMjAwDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC0NCj4gRHJh ZnRzDQo+ID4gPiBkaXJlY3Rvcmllcy4NCj4gPiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV29ya2luZw0KPiA+ID4gR3JvdXAgb2Yg dGhlIElFVEYuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IAlUaXRsZSAgICAgICAg ICAgOiBVc2luZyB0aGUgTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sDQo+IG92ZXINCj4g PiA+IFNlY3VyZSBTaGVsbCAoU1NIKQ0KPiA+ID4gPiA+IAlBdXRob3IocykgICAgICAgOiBNLiBX YXNzZXJtYW4sIFQuIEdvZGRhcmQNCj4gPiA+ID4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMtMDMudHh0DQo+ID4gPiA+ID4gCVBhZ2VzICAgICAgICAg ICA6IDEwDQo+ID4gPiA+ID4gCURhdGUgICAgICAgICAgICA6IDIwMTAtMTAtMjANCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBpbnZva2lu ZyBhbmQgcnVubmluZyB0aGUNCj4gPiA+IE5FVENPTkYNCj4gPiA+ID4gPiBwcm90b2NvbCB3aXRo aW4gYSBTZWN1cmUgU2hlbGwgKFNTSCkgc2Vzc2lvbiBhcyBhbiBTU0gNCj4gc3Vic3lzdGVtLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+ ID4gPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1u ZXRjb25mLQ0KPiByZmM0NzQyYmlzLQ0KPiA+ID4gMDMudHh0DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+ID4gPiA+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBj b21wbGlhbnQgbWFpbA0KPiByZWFkZXINCj4gPiA+ID4gPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRv bWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mDQo+IHRoZQ0KPiA+ID4gPiA+ IEludGVybmV0LURyYWZ0Lg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBO ZXRjb25mQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBMYWRpc2xhdiBMaG90a2EsIENF U05FVA0KPiA+ID4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPg0KPiANCj4gLS0NCj4gTGFkaXNs YXYgTGhvdGthLCBDRVNORVQNCj4gUEdQIEtleSBJRDogRTc0RThDMEMNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0 DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYNCg== From mehmet.ersue@nsn.com Thu Oct 21 12:09:25 2010 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 B4C2E3A690C for ; Thu, 21 Oct 2010 12:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 YJnGSqDApKUd for ; Thu, 21 Oct 2010 12:09:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6FA183A6802 for ; Thu, 21 Oct 2010 12:09:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9LJArtu015728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 21:10:53 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9LJAqsR008749; Thu, 21 Oct 2010 21:10:53 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 21:10:52 +0200 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: Thu, 21 Oct 2010 21:10:51 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E53CE@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxQtEJzWJC74Y2S4+q1mxJYNDC1wAAEBTQAALQ+NAAAMGO4A== References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net><1287595401.5999.7.camel@missotis><80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net><1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "ext Ladislav Lhotka" X-OriginalArrivalTime: 21 Oct 2010 19:10:52.0155 (UTC) FILETIME=[ADC16CB0:01CB7153] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:09:25 -0000 T0suIEhvd2V2ZXIsIGluZGVwZW5kZW50bHkgd2hhdCBoYXBwZW5lZCBlYXJsaWVyIHdlIHNob3Vs ZCBmaXggDQp0aGUgbWlzbGVhZGluZyB0ZXh0IG5vdy4gDQoNCkp1ZXJnZW4gd3JvdGU6DQoiIElm IHRoZSBYTUwgY29udGVudCBjYXJyaWVkIGJ5IE5FVENPTkYgZG9lcyBub3QgaW5jbHVkZSBjb21t ZW50cywNCiAgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMsIG9yIGF0dHJpYnV0ZSB2YWx1ZXMsIHRo aXMgY2hhcmFjdGVyDQogIHNlcXVlbmNlIGNhbiBiZSB1c2VkIHRvIHJlc3luY2hyb25pemUgYSBO RVRDT05GIGV4Y2hhbmdlIGluIHRoZQ0KICBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNp bmcgZXJyb3IuIg0KDQpJIGhhdmUgYW4gaXNzdWUgd2l0aCB0aGlzIHRleHQgc2luY2UgaXQgZG9l cyBub3Qgc3RhdGUgd2hhdCB0aGUgDQppbXBsZW1lbnRlciBzaG91bGQgZG8gaWYgdGhlIFhNTCBj b250ZW50IGNhcnJpZWQgYnkgTkVUQ09ORiBkb2VzIA0KaW5jbHVkZSBjb21tZW50cywgZXRjLiAN Cg0KQWZ0ZXIgYWxsLCBJIHRlbmQgdG8gYWdyZWUgd2l0aCBMYWRhIHRoYXQgaXQgd291bGQgYmUg Y29ycmVjdCBmcm9tIA0KWE1MIHNwZWNpZmljYXRpb24gcG92LiBpZiB3ZSBzdGF0ZToNCg0KIlRo aXMgY2hhcmFjdGVyIHNlcXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEg Y29tbWVudCwNCnByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb24gYW5kIGF0dHJpYnV0ZSB2YWx1ZSBpbiBh biBYTUwgZG9jdW1lbnQsIHNvIGl0IA0KY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGVuZCBv ZiB0aGUgY3VycmVudCBkb2N1bWVudCwgYWxsb3dpbmcgDQpyZXN5bmNocm9uaXphdGlvbiBvZiB0 aGUgTkVUQ09ORiBleGNoYW5nZSBpbiB0aGUgZXZlbnQgb2YgYW4gWE1MIA0Kc3ludGF4IG9yIHBh cnNpbmcgZXJyb3IuIg0KDQpzL3VuYW1iaWd1b3VzbHkvLw0KDQoNClBsZWFzZSBwcm9wb3NlIGNv bmNyZXRlIHRleHQgaWYgYW55Ym9keSB0aGlua3Mgc29tZXRoaW5nIGlzIGJldHRlcg0KdGhhbiB0 aGUgcHJvcG9zYWwgZnJvbSBMYWRhLg0KDQpDaGVlcnMsDQpNZWhtZXQNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGV4dCBBbmR5IEJpZXJtYW4gW21haWx0bzpiaWVy bWFuYUBCcm9jYWRlLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjEsIDIwMTAgODo1 MiBQTQ0KPiBUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKTsgZXh0IExhZGlzbGF2 IExob3RrYQ0KPiBDYzogZXh0IE1hcmdhcmV0IFdhc3Nlcm1hbjsgTmV0Y29uZg0KPiBTdWJqZWN0 OiBSRTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dM Qw0KPiBSRkM0NzQxYmlzDQo+IA0KPiBIaSwNCj4gDQo+IFRoZSBvcmlnaW5hbCBpbnRlbnQgd2Fz IHRvIHVzZSBhIGNoYXIgc2VxdWVuY2UgdGhhdCB3YXMgbm90IGxlZ2FsIGluDQo+IGFuIFhNTCBp bnN0YW5jZSBkb2N1bWVudC4gIE5vYm9keSBpbiB0aGUgV0cgYXQgdGhlIHRpbWUga25ldyBmb3Ig c3VyZSwNCj4gc28gd2UgYXNrZWQgdGhlIFhNTCBEaXJlY3RvcmF0ZS4gIFdlIHdvcmtlZCB1bmRl ciB0aGUgYXNzdW1wdGlvbiB0aGF0DQo+IHRoZSBdXT5dXT4gc2VxdWVuY2Ugd2FzIGEgc3VpdGFi bGUgbWVzc2FnZSBib3VuZGFyeSBtYXJrZXIuDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gaGVhciBl dmlkZW5jZSB0aGF0IHRoaXMgRU9NIHNlcXVlbmNlIGlzIGNhdXNpbmcNCj4gcHJvYmxlbXMNCj4g Zm9yIG9wZXJhdG9ycyB1c2luZyBORVRDT05GLiAgSXMgdGhpcyByZWFsbHkgYSBjb25jZXJuIHRv IG9wZXJhdG9ycz8NCj4gV291bGQgYSBzaWduaWZpY2FudCBwcm90b2NvbCBjaGFuZ2UgdG8gYWRk cmVzcyB0aGlzIGlzc3VlIGNhdXNlIG1vcmUNCj4gb3BlcmF0aW9uYWwgcHJvYmxlbXMgdGhhbiBp dCBzb2x2ZXM/DQo+IA0KPiBJIGRvIG5vdCBhZ3JlZSB0aGF0IHRoaXMgbXVzdCBiZSBmaXhlZCBp biBORVRDT05GIDIuMCwgd2hlbmV2ZXIgdGhhdA0KPiBpcy4NCj4gV2Ugc2hvdWxkIGRlY2lkZSBh dCB0aGUgdGltZSwgYWZ0ZXIgc29tZSBtb3JlIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4NCj4gDQo+ IA0KPiBBbmR5DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiBCZWhhbGYgT2YgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiBTZW50 OiBUaHVyc2RheSwgT2N0b2JlciAyMSwgMjAxMCAxMToyMSBBTQ0KPiBUbzogZXh0IExhZGlzbGF2 IExob3RrYQ0KPiBDYzogZXh0IE1hcmdhcmV0IFdhc3Nlcm1hbjsgTmV0Y29uZg0KPiBTdWJqZWN0 OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dM Qw0KPiBSRkM0NzQxYmlzDQo+IA0KPiBIaSBMYWRhLA0KPiANCj4gPiBIaSBNZWhtZXQsDQo+ID4N Cj4gPiBPbiDEjHQsIDIwMTAtMTAtMjEgYXQgMTg6NDkgKzAyMDAsIEVyc3VlLCBNZWhtZXQgKE5T TiAtIERFL011bmljaCkNCj4gPiB3cm90ZToNCj4gPiA+IEhpIExhZGEsDQo+ID4gPg0KPiA+ID4g W3NwZWFraW5nIGFzIGEgY29udHJpYnV0b3JdDQo+ID4gPg0KPiA+ID4gaWYgSSB1bmRlcnN0YW5k IHlvdSBjb3JyZWN0bHkgeW91IHdhbnQgdG8gYWxsb3cgdGhlIEVPTQ0KPiA+ID4gbm90IG9ubHkg aW4gY29tbWVudHMgYnV0IGFsc28gaW4gWE1MIGF0dHJpYnV0ZXMgYW5kIFBJcy4NCj4gPiA+DQo+ ID4gPiBJbiBjYXNlIHRoZSBhbnN3ZXIgaXMgbm86IEkgYXBwZWFyIHRvIG1pc3VuZGVyc3RhbmQg d2hhdA0KPiA+ID4geW91IHdlcmUgc2F5aW5nLiBTbyBwbHMgZXhwbGFpbi4NCj4gPg0KPiA+IEkg Y2VydGFpbmx5IGRvbid0IHdhbnQgdG8gYWxsb3cgYW55dGhpbmcgdGhhdCBpc24ndCBhbHJlYWR5 IGFsbG93ZWQuDQo+IDotDQo+ID4gKQ0KPiA+DQo+ID4gVGhlIGN1cnJlbnQgdGV4dCBzYXlzLCBh cyBJIHVuZGVyc3RhbmQgaXQsIHRoYXQgWE1MIHNwZWNpZmljYXRpb24NCj4gPiBkb2Vzbid0IGFs bG93IHRoZSBFT00gbWFya2VyIHRvIGFwcGVhciBvdXRzaWRlIGNvbW1lbnRzIGluIGFuIFhNTA0K PiA+IGRvY3VtZW50IChhbmQgdGhlcmVmb3JlIGl0IGlzIGEgZ29vZCBjaG9pY2UpLiBCdXQgdGhp cyBpcyBub3QgdHJ1ZToNCj4gWE1MDQo+ID4gZG9jdW1lbnRzIGhhdmluZyB0aGUgc2VxdWVuY2Ug aW4gUElzIGFuZCBhdHRyaWJ1dGUgdmFsdWVzIGFyZQ0KPiA+IHdlbGwtZm9ybWVkIGFzIHdlbGwu IFRoZSBvbmx5IHBsYWNlIHdoZXJlIHRoZSBzZXF1ZW5jZSBpcyByZWFsbHkNCj4gPiBmb3JiaWRk ZW4gaXMgZWxlbWVudCB0ZXh0Lg0KPiANCj4gIlRoaXMgY2hhcmFjdGVyIHNlcXVlbmNlIGNhbm5v dCBsZWdhbGx5IGFwcGVhciBpbiBhbiBYTUwgZG9jdW1lbnQsIHNvDQo+IGl0IGNhbiBiZSB1bmFt YmlnaW91c2x5IHVzZWQgdG8gaW5kZW50aWZ5IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQNCj4gZG9j dW1lbnQgaW4gdGhlIGV2ZW50IG9mIGFuIFhNTCBzeW50YXggb3IgcGFyc2luZyBlcnJvciwgYWxs b3dpbmcNCj4gcmVzeW5jaHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYgZXhjaGFuZ2UuIg0KPiAN Cj4gVGhlIHNlbnRlbmNlIGlzIGFjdHVhbGx5IHNpbmNlIE1heSAyMDA0ICh2MDEpIGluIFNTSCBk b2N1bWVudA0KPiBhbmQgZGlkIG5vdCBjaGFuZ2UgdW50aWwgdG9kYXkuIEkgZG9uJ3Qga25vdyBl eGFjdGx5IHdoYXQgdGhlDQo+IGFpbSBvZiB0aGUgYXV0aG9ycyB3YXMgdG8gd3JpdGUgaXQgdGhh dCB3YXkuDQo+IA0KPiBPbmUgb3B0aW9uIGlzIHRoZXkgd2FudGVkIHRvIHN0YXRlIHRoYXQgdGhl IEVPTSAiLi4uIE1VU1QgTk9UDQo+IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudCBpbiBhbiBY TUwgZG9jdW1lbnQiLCB3aGljaCB3b3VsZA0KPiBiZSBhIGNvbnNpc3RlbnQgcmVzdHJpY3Rpb24u DQo+IA0KPiBUaGUgb3RoZXIgb3B0aW9uIGlzIGhvdyB5b3UgdW5kZXJzdGFuZCBpdDoNCj4gIlhN TCBzcGVjaWZpY2F0aW9uIGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8gYXBwZWFyDQo+ IG91dHNpZGUgY29tbWVudHMiDQo+IA0KPiAuLi53aGljaCBpcyBvYnZpb3VzbHkgbm90IGNvcnJl Y3QgYW5kIGNhbiBiZSBhZGRyZXNzZWQgYXMNCj4geW91IHN1Z2dlc3QuIEJ1dCB0aGlzIHdvdWxk IG1lYW4gYWRkaXRpb25hbCBpbXBsZW1lbnRhdGlvbg0KPiBlZmZvcnQgZm9yIFNTSCB0cmFuc3Bv cnQuDQo+IA0KPiBNYXJnYXJldCwgVGVkLCBBbmR5Og0KPiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5 IHdoYXQgdGhlIG9yaWdpbmFsIGFpbSB3YXM/DQo+IA0KPiBXaGF0IGRvIG90aGVycyBpbiB0aGUg V0cgdGhpbms/DQo+IFBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYmVmb3JlIEZyaWRheSBFT0Iu DQo+IA0KPiBNZWhtZXQNCj4gDQo+ID4gTGFkYQ0KPiA+DQo+ID4gPg0KPiA+ID4gSW4gY2FzZSB0 aGUgYW5zd2VyIGlzIHllczoNCj4gPiA+DQo+ID4gPiBUaGVvcmV0aWNhbGx5IHRoZSBFT00gc2Vx dWVuY2UgY2FuIGFwcGVhciBldmVyeXdoZXJlIGluDQo+ID4gPiBhbiBYTUwgZG9jdW1lbnQuDQo+ ID4gPg0KPiA+ID4gSG93ZXZlciwgdGhlIHRyYW5zcG9ydCBsYXllciBzaG91bGRuJ3QgZG8gZmlu ZSBncmFpbmVkDQo+ID4gPiBwYXJzaW5nIG9mIHRoZSBYTUwgZG9jdW1lbnQsIHRvIGZpbmQgb3V0 IHdoZXJlIHRoZQ0KPiA+ID4gYXR0cmlidXRlcyBvciBQSXMgYXJlLg0KPiA+ID4gVGhpcyBpcyB0 aGUgcmVhc29uIHdoeSA0NzQyIGtlcHQgaXQgc2ltcGxlIGFuZCwgYXMgSQ0KPiA+ID4gdGhpbmss IGFwcHJvcHJpYXRlIGZvciB0aGUgdHJhbnNwb3J0IGxheWVyLg0KPiA+ID4NCj4gPiA+IEkgZG9u J3Qgc2VlIGFueSBkaWZmZXJlbmNlIGJldHdlZW4gWE1MIGVsZW1lbnRzIGFuZA0KPiA+ID4gW2F0 dHJpYnV0ZXMgb3IgUEldLiBUaGV5IGFsbCBhcmUgWE1MIGRhdGEuIEFuZCBFT00gY2FuDQo+ID4g PiBhcHBlYXIgaW4gWE1MIGRhdGEgb3IgYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQuDQo+ID4g PiBJZiBzb21lYm9keSB3YW50cyB0byBkaXNydXB0IHRoZSBycGMgY29tbWFuZCBoZSBjYW4NCj4g PiA+IGRvIGl0IG5vIG1hdHRlciBpbiBlbGVtZW50cyBvciBhdHRyaWJ1dGVzLg0KPiA+ID4NCj4g PiA+IFNvLCBhdCB0aGUgZW5kIEkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0IGluIHJlZHVjaW5nIHRo ZQ0KPiA+ID4gcmVzdHJpY3Rpb24gYW5kIHRoaW5rOg0KPiA+ID4gVG8gYmUgb24gdGhlIHNhZmUg c2lkZSBhbmQgdG8ga2VlcCBpdCBzaW1wbGUgZm9yIHRoZQ0KPiA+ID4gaW1wbGVtZW50ZXIgb2Yg NDc0MmJpcyB0aGUgc2VxdWVuY2UgbXVzdCBub3QgYXBwZWFyDQo+ID4gPiBpbiB0aGUgWE1MIGRv Y3VtZW50IChleGNlcHQgb3V0c2lkZSBvZiBjb21tZW50cykuDQo+ID4gPg0KPiA+ID4gW25vdyB0 aGUgY2hhaXIgaGF0IG9uXToNCj4gPiA+DQo+ID4gPiBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQg d2UgZG9uJ3QgaGF2ZSB0aGUgbWFuZGF0ZQ0KPiA+ID4gZm9yIHYyLjAuIFdlIGFyZSBqdXN0IGRv aW5nIGJ1Zy1maXhpbmcuDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHYyLjAg c2hvdWxkIHNvbHZlIHRoaXMgaXNzdWUNCj4gPiA+IHdpdGggYSB0aG9yb3VnaCBzb2x1dGlvbi4g V291bGQgeW91IGxpa2UgdG8gcHJlcGFyZQ0KPiA+ID4gYSBmZXcgc2xpZGVzIGZvciB0aGUgTkVU Q09ORiBzZXNzaW9uIGluIEJlaWppbmcgZm9yDQo+ID4gPiBhIHNvbHV0aW9uLCB3aGljaCBjb3Vs ZCBiZSBwdXQgbGF0ZXIgaW50byB2Mi4wPw0KPiA+ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IE1l aG1ldA0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiA+IEZyb206IGV4dCBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAY2VzbmV0LmN6 XQ0KPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgNzoyMyBQTQ0KPiA+ ID4gPiBUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiA+ID4gPiBDYzogTmV0 Y29uZjsgZXh0IE1hcmdhcmV0IFdhc3Nlcm1hbg0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW05ldGNv bmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dMQw0KPiA+ID4gPiBS RkM0NzQxYmlzDQo+ID4gPiA+DQo+ID4gPiA+IE9uIFN0LCAyMDEwLTEwLTIwIGF0IDE4OjI3ICsw MjAwLCBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQo+ID4gPiA+IHdyb3RlOg0KPiA+ ID4gPiA+IEhpIEFsbCwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IHNhbWUgaXMgd2l0aCA0NzQyYmlz IFdHTEMgZGlzY3VzaW9uLiBXZSBoYWQgb25seSBtaW5vcg0KPiA+ID4gPiA+IGNoYW5nZXMgYWZ0 ZXIgSUVURiA3OC4gT3VyIGltcHJlc3Npb24gaXMgdGhhdCB3ZSBoYXZlDQo+ID4gPiA+ID4gY29u c2Vuc3VzIHRvIHNlZSB0aGUgZHJhZnQgYXMgZmluYWwuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBN YXJnYXJldCBzdWJtaXR0ZWQgdGhlIGRyYWZ0IHRvZGF5IG1ha2luZyBpdCByZWFkeSBmb3INCj4g PiA+ID4gPiBBRCByZXZpZXcuIFBsZWFzZSBjaGVjayB0aGUgY2hhbmdlcyBieSAxMC8yMiBzbyB0 aGF0DQo+ID4gPiA+ID4gd2UgaGF2ZSBhIGNoYW5jZSB0byByZS1zdWJtaXQgYmVmb3JlIGRlYWRs aW5lLiBUaGFua3MuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBqdXN0aWZpY2F0aW9uIGZvciB0aGUg RU9NIG1hcmtlciBpbiBzZWMuIDMuMSBpcyB0ZWNobmljYWxseQ0KPiA+ID4gPiBpbmNvcnJlY3Qg LSBhbmQgSSBvYmplY3RlZCBhZ2FpbnN0IGl0IHByZXZpb3VzbHk6DQo+ID4gPiA+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC0NCj4gYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA2Mjc3 Lmh0bWwNCj4gPiA+ID4NCj4gPiA+ID4gSGVyZSBpcyB0aGUgY2hhbmdlIEkgcHJvcG9zZSAodGhl cmUncyBhbHNvIGEgdHlwbyBpbg0KPiA+ICJ1bmFtYmlndW91c2x5Iik6DQo+ID4gPiA+DQo+ID4g PiA+IE9MRA0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGNoYXJhY3RlciBzZXF1ZW5jZSBjYW5ub3Qg bGVnYWxseSBhcHBlYXIgb3V0c2lkZSBvZiBhDQo+IGNvbW1lbnQNCj4gPiBpbg0KPiA+ID4gPiBh bg0KPiA+ID4gPiBYTUwgZG9jdW1lbnQsIHNvIGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQg dG8gaWRlbnRpZnkgdGhlIGVuZA0KPiA+IG9mDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiBjdXJyZW50 IGRvY3VtZW50LCBhbGxvd2luZyByZXN5bmNocm9uaXphdGlvbiBvZiB0aGUgTkVUQ09ORg0KPiA+ IGV4Y2hhbmdlIGluDQo+ID4gPiA+IHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNp bmcgZXJyb3IuDQo+ID4gPiA+DQo+ID4gPiA+IE5FVw0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGNo YXJhY3RlciBzZXF1ZW5jZSBjYW5ub3QgbGVnYWxseSBhcHBlYXIgb3V0c2lkZSBvZiBhDQo+IGNv bW1lbnQsDQo+ID4gPiA+IHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb24gYW5kIGF0dHJpYnV0ZSB2YWx1 ZSBpbiBhbiBYTUwgZG9jdW1lbnQsIHNvDQo+ID4gaXQNCj4gPiA+ID4gY2FuDQo+ID4gPiA+IGJl IHVuYW1iaWd1b3VzbHkgdXNlZCB0byBpZGVudGlmeSB0aGUgZW5kIG9mIHRoZSBjdXJyZW50DQo+ IGRvY3VtZW50LA0KPiA+ID4gPiBhbGxvd2luZyByZXN5bmNocm9uaXphdGlvbiBvZiB0aGUgTkVU Q09ORiBleGNoYW5nZSBpbiB0aGUgZXZlbnQNCj4gb2YNCj4gPiBhbg0KPiA+ID4gPiBYTUwgc3lu dGF4IG9yIHBhcnNpbmcgZXJyb3IuDQo+ID4gPiA+DQo+ID4gPiA+IExhZGENCj4gPiA+ID4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiBNZWhtZXQNCj4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiBGcm9tOiBuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRjb25mLQ0KPiBib3Vu Y2VzQGlldGYub3JnXQ0KPiA+IE9uDQo+ID4gPiA+ID4gQmVoYWxmIE9mIGV4dCBCZXJ0IFdpam5l biAoSUVURikNCj4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgMzo1 MiBQTQ0KPiA+ID4gPiA+IFRvOiBOZXRjb25mDQo+ID4gPiA+ID4gU3ViamVjdDogW05ldGNvbmZd IHN0YXR1cyBXR0xDIFJGQzQ3NDFiaXMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEl0IHNlZW1zIHRo YXQgdGhlIFdHTEMgZGlzY3Vzc2lvbiBoYXMgbm93IGRpZWQgb3V0IG9uIHRoZQ0KPiBtYWlsaW5n DQo+ID4gPiA+IGxpc3QuDQo+ID4gPiA+ID4gRnJvbSByZS1yZWFkaW5nIGFsbCB0aG9zZSBjb21t ZW50cywgSSBhbHNvIGdldCB0aGUgaW1wcmVzc2lvbg0KPiA+IHRoYXQNCj4gPiA+ID4gPiB0aGVy ZSBpcyBjb25zZW5zdXMvYWdyZWVtZW50IG9uIHRoZSBjaGFuZ2VzIHRoYXQgbmVlZCB0byBiZQ0K PiA+ID4gPiBhZGRyZXNzZWQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgZWRpdG9ycyAoc3Bl Y2lmaWNhbGx5IE1hcnRpbikgaXMgcHJlcGFyaW5nIGEgbmV3IHJldmlzaW9uDQo+ID4gYmFzZWQN Cj4gPiA+ID4gPiBvbiB0aGUgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9ucy4gV2lsbCBwcm9iYWJs eSBzaG93IHVwIGxhdGVyDQo+ID4gdG9kYXkuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPdXIgcGxh biBhcyBXRy1jaGFpcnMgaXMgdG8gYWxsb3cgdGhlIFdHIGEgZmV3IGRheXMgdG8gcXVpY2tseQ0K PiA+IGNoZWNrDQo+ID4gPiA+ID4gaWYgdGhlIGNoYW5nZXMgYXJlIE9LLiBUaGVuIGFzayBvdXIg QWQgdG8gYnJpbmcgaXQgZm9yd2FyZCB0bw0KPiA+IElFVEYNCj4gPiA+ID4gPiBMYXN0IENhbGwg YW5kIElFU0cgcmV2aWV3Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiA+ IEJlcnQgYW5kIE1laG1ldA0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ ID4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4gPiA+ID4gZS1tYWlsIG1lc3NhZ2UgYXR0YWNobWVu dA0KPiA+ID4gPiA+ID4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPiA+ ID4gPiA+IEZyb206IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gUmVwbHkt dG86IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ID4gPiA+ID4gPiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnDQo+ID4gPiA+ID4gPiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiA+ ID4gU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNDc0MmJpcy0wMy50 eHQNCj4gPiA+ID4gPiA+IERhdGU6IFdlZCwgMjAgT2N0IDIwMTAgMTc6MDA6MDIgKzAyMDANCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC0NCj4gPiBEcmFmdHMNCj4gPiA+ID4gZGlyZWN0b3Jp ZXMuDQo+ID4gPiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3Jr IENvbmZpZ3VyYXRpb24NCj4gV29ya2luZw0KPiA+ID4gPiBHcm91cCBvZiB0aGUgSUVURi4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gCVRpdGxlICAgICAgICAgICA6IFVz aW5nIHRoZSBORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wNCj4gPiBvdmVyDQo+ID4gPiA+ IFNlY3VyZSBTaGVsbCAoU1NIKQ0KPiA+ID4gPiA+ID4gCUF1dGhvcihzKSAgICAgICA6IE0uIFdh c3Nlcm1hbiwgVC4gR29kZGFyZA0KPiA+ID4gPiA+ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTAzLnR4dA0KPiA+ID4gPiA+ID4gCVBhZ2VzICAgICAg ICAgICA6IDEwDQo+ID4gPiA+ID4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMC0xMC0yMA0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZv ciBpbnZva2luZyBhbmQgcnVubmluZyB0aGUNCj4gPiA+ID4gTkVUQ09ORg0KPiA+ID4gPiA+ID4g cHJvdG9jb2wgd2l0aGluIGEgU2VjdXJlIFNoZWxsIChTU0gpIHNlc3Npb24gYXMgYW4gU1NIDQo+ ID4gc3Vic3lzdGVtLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEEgVVJMIGZvciB0aGlzIElu dGVybmV0LURyYWZ0IGlzOg0KPiA+ID4gPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRjb25mLQ0KPiA+IHJmYzQ3NDJiaXMtDQo+ID4gPiA+IDAz LnR4dA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiA+ID4gPiA+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQmVsb3cgaXMg dGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsDQo+ID4gcmVh ZGVyDQo+ID4gPiA+ID4gPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZl IHRoZSBBU0NJSSB2ZXJzaW9uIG9mDQo+ID4gdGhlDQo+ID4gPiA+ID4gPiBJbnRlcm5ldC1EcmFm dC4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gTmV0Y29uZkBp ZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0KPiA+ID4gPg0KPiA+ID4gPiAtLQ0KPiA+ID4gPiBMYWRpc2xhdiBMaG90a2EsIENF U05FVA0KPiA+ID4gPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiA+ID4NCj4gPg0KPiA+IC0tDQo+ ID4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQNCj4gPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0 Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From j.schoenwaelder@jacobs-university.de Thu Oct 21 12:10:15 2010 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 501B13A681F for ; Thu, 21 Oct 2010 12:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bmPuSOVgMjgY for ; Thu, 21 Oct 2010 12:10:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BFC853A6802 for ; Thu, 21 Oct 2010 12:10:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62B24C0007; Thu, 21 Oct 2010 21:11:48 +0200 (CEST) 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 z5Vhfm9WWdje; Thu, 21 Oct 2010 21:11:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC422C0004; Thu, 21 Oct 2010 21:11:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B782156C620; Thu, 21 Oct 2010 21:11:08 +0200 (CEST) Date: Thu, 21 Oct 2010 21:11:08 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101021191108.GA28010@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , ext Ladislav Lhotka , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> 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: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:10:15 -0000 On Thu, Oct 21, 2010 at 11:51:34AM -0700, Andy Bierman wrote: > The original intent was to use a char sequence that was not legal in > an XML instance document. Nobody in the WG at the time knew for sure, > so we asked the XML Directorate. We worked under the assumption that > the ]]>]]> sequence was a suitable message boundary marker. > > I would like to hear evidence that this EOM sequence is causing problems > for operators using NETCONF. Is this really a concern to operators? > Would a significant protocol change to address this issue cause more > operational problems than it solves? > > I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > We should decide at the time, after some more deployment experience. Andy, we are in a different discussion. We agreed to not fix it. Still, the wording should be correct and appropriate. This is what we are discussing. Do you have a proposal? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Oct 21 12:13:53 2010 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 67E773A6A56 for ; Thu, 21 Oct 2010 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 n4py5Qhc7BnE for ; Thu, 21 Oct 2010 12:13:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D47973A6975 for ; Thu, 21 Oct 2010 12:13:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7734BC000E; Thu, 21 Oct 2010 21:15:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pHpExcrN1Ift; Thu, 21 Oct 2010 21:15:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB41EC0007; Thu, 21 Oct 2010 21:15:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF88D156C69B; Thu, 21 Oct 2010 21:14:47 +0200 (CEST) Date: Thu, 21 Oct 2010 21:14:47 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101021191447.GB28010@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman , ext Ladislav Lhotka , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64011E53CE@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E53CE@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Andy Bierman , Netconf , ext Margaret Wasserman Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:13:53 -0000 On Thu, Oct 21, 2010 at 09:10:51PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > OK. However, independently what happened earlier we should fix > the misleading text now. > > Juergen wrote: > " If the XML content carried by NETCONF does not include comments, > processing instructions, or attribute values, this character > sequence can be used to resynchronize a NETCONF exchange in the > event of an XML syntax or parsing error." > > I have an issue with this text since it does not state what the > implementer should do if the XML content carried by NETCONF does > include comments, etc. But that problem won't be solved until 2.0. > After all, I tend to agree with Lada that it would be correct from > XML specification pov. if we state: > > "This character sequence cannot legally appear outside of a comment, > processing instruction and attribute value in an XML document, so it > can be used to identify the end of the current document, allowing > resynchronization of the NETCONF exchange in the event of an XML > syntax or parsing error." > > s/unambiguously// > > > Please propose concrete text if anybody thinks something is better > than the proposal from Lada. So hiding the issue is better than being clear about it? I would rather add text to my proposed wording that says that the transport should drop the session in case a parsing error has been detected by the NETCONF message layer if content can contain the magic sequence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Thu Oct 21 12:23:28 2010 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 A82313A6824 for ; Thu, 21 Oct 2010 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 t82gwURMxGCO for ; Thu, 21 Oct 2010 12:23:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id DE29D3A6818 for ; Thu, 21 Oct 2010 12:23:25 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7A8A42CDE058; Thu, 21 Oct 2010 21:25:00 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101021191447.GB28010@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64011E53CE@DEMUEXC006.nsn-intra.net> <20101021191447.GB28010@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 21:24:58 +0200 Message-ID: <1287689098.1606.130.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , ext Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:23:29 -0000 On Čt, 2010-10-21 at 21:14 +0200, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 09:10:51PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > > OK. However, independently what happened earlier we should fix > > the misleading text now. > > > > Juergen wrote: > > " If the XML content carried by NETCONF does not include comments, > > processing instructions, or attribute values, this character > > sequence can be used to resynchronize a NETCONF exchange in the > > event of an XML syntax or parsing error." > > > > I have an issue with this text since it does not state what the > > implementer should do if the XML content carried by NETCONF does > > include comments, etc. > > But that problem won't be solved until 2.0. > > > After all, I tend to agree with Lada that it would be correct from > > XML specification pov. if we state: > > > > "This character sequence cannot legally appear outside of a comment, > > processing instruction and attribute value in an XML document, so it > > can be used to identify the end of the current document, allowing > > resynchronization of the NETCONF exchange in the event of an XML > > syntax or parsing error." > > > > s/unambiguously// > > > > > > Please propose concrete text if anybody thinks something is better > > than the proposal from Lada. > > So hiding the issue is better than being clear about it? I would > rather add text to my proposed wording that says that the transport > should drop the session in case a parsing error has been detected by > the NETCONF message layer if content can contain the magic sequence. The problem is that the message layer won't detect a parsing error if there isn't any. Other transports such as BEEP or TLS should work fine even for message-id="]]>]]>". Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Thu Oct 21 12:28:17 2010 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 251063A6AA5 for ; Thu, 21 Oct 2010 12:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.172, 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 klScIkW5Ifst for ; Thu, 21 Oct 2010 12:28:15 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 562213A6AA3 for ; Thu, 21 Oct 2010 12:28:15 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LJQ6x1014331; Thu, 21 Oct 2010 12:29:44 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s2ta3019r-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 12:29:43 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 12:34:01 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 21 Oct 2010 12:29:42 -0700 From: Andy Bierman To: Juergen Schoenwaelder Date: Thu, 21 Oct 2010 12:29:41 -0700 Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxU9NaMzohYkgSTZ6rLh5FYGfspgAASo2A Message-ID: References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> In-Reply-To: <20101021191108.GA28010@elstar.local> 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=2010-10-21_09:2010-10-21, 2010-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210158 X-Proofpoint-SSN: Sensitivity2 Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:28:17 -0000 Hi, I did not agree to push this to 2.0 and fix it then. I liked the original text that Martin had. I think the IESG is likely to want text that says what the server does if invalid XML is encountered. The current 4741bis text says an operation-failed error MUST be generated. If there is going to be text that says the server MUST drop the session if invalid XML is encountered, then it needs to be for every transport, and needs to be in 4741bis. The transport layer should not need to know the content is XML instead of text. The protocol layer should not need to know which transport was used to decide how to respond to a parse error. The server should not assume it knows whether broken XML is due to client programming error or by some data injection attack. Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, October 21, 2010 12:11 PM To: Andy Bierman Cc: Ersue, Mehmet (NSN - DE/Munich); ext Ladislav Lhotka; ext Margaret Wass= erman; Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bi= s On Thu, Oct 21, 2010 at 11:51:34AM -0700, Andy Bierman wrote: =20 > The original intent was to use a char sequence that was not legal in > an XML instance document. Nobody in the WG at the time knew for sure, > so we asked the XML Directorate. We worked under the assumption that > the ]]>]]> sequence was a suitable message boundary marker. >=20 > I would like to hear evidence that this EOM sequence is causing problems > for operators using NETCONF. Is this really a concern to operators? > Would a significant protocol change to address this issue cause more > operational problems than it solves? >=20 > I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > We should decide at the time, after some more deployment experience. Andy, we are in a different discussion. We agreed to not fix it. Still, the wording should be correct and appropriate. This is what we are discussing. Do you have a proposal? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Thu Oct 21 12:38:03 2010 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 8DF613A6A32 for ; Thu, 21 Oct 2010 12:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 nnBc9EB4Wylr for ; Thu, 21 Oct 2010 12:38:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D83EA3A6848 for ; Thu, 21 Oct 2010 12:38:01 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2A7B72CDE05B; Thu, 21 Oct 2010 21:39:37 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 21:39:35 +0200 Message-ID: <1287689975.1606.136.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:38:03 -0000 On Čt, 2010-10-21 at 12:29 -0700, Andy Bierman wrote: > Hi, > > I did not agree to push this to 2.0 and fix it then. > > I liked the original text that Martin had. Now I am confused. Martin's new text was intended for 4741bis, wasn't it? We are now discussing the text from sec. 3.1 of 4742bis. Lada > I think the IESG is likely to want text that says what the server > does if invalid XML is encountered. The current 4741bis text says > an operation-failed error MUST be generated. > > If there is going to be text that says the server MUST drop the session > if invalid XML is encountered, then it needs to be for every transport, > and needs to be in 4741bis. The transport layer should not need to know > the content is XML instead of text. The protocol layer should not need > to know which transport was used to decide how to respond to a parse error. > The server should not assume it knows whether broken XML is due > to client programming error or by some data injection attack. > > > > Andy > > > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, October 21, 2010 12:11 PM > To: Andy Bierman > Cc: Ersue, Mehmet (NSN - DE/Munich); ext Ladislav Lhotka; ext Margaret Wasserman; Netconf > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis > > On Thu, Oct 21, 2010 at 11:51:34AM -0700, Andy Bierman wrote: > > > The original intent was to use a char sequence that was not legal in > > an XML instance document. Nobody in the WG at the time knew for sure, > > so we asked the XML Directorate. We worked under the assumption that > > the ]]>]]> sequence was a suitable message boundary marker. > > > > I would like to hear evidence that this EOM sequence is causing problems > > for operators using NETCONF. Is this really a concern to operators? > > Would a significant protocol change to address this issue cause more > > operational problems than it solves? > > > > I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > > We should decide at the time, after some more deployment experience. > > Andy, > > we are in a different discussion. We agreed to not fix it. Still, the > wording should be correct and appropriate. This is what we are > discussing. Do you have a proposal? > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Oct 21 12:40:37 2010 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 54C1B3A6A58 for ; Thu, 21 Oct 2010 12:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 uofw6TF2ZuFY for ; Thu, 21 Oct 2010 12:40:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0D2D23A6A21 for ; Thu, 21 Oct 2010 12:40:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE651C0008; Thu, 21 Oct 2010 21:42:11 +0200 (CEST) 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 FKgOcWuU8c9Z; Thu, 21 Oct 2010 21:42:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17112C0007; Thu, 21 Oct 2010 21:42:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3C2C5156C7C7; Thu, 21 Oct 2010 21:41:32 +0200 (CEST) Date: Thu, 21 Oct 2010 21:41:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101021194132.GD28010@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , ext Ladislav Lhotka , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> 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: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:40:37 -0000 On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > If there is going to be text that says the server MUST drop the session > if invalid XML is encountered, then it needs to be for every transport, > and needs to be in 4741bis. The transport layer should not need to know > the content is XML instead of text. The protocol layer should not need > to know which transport was used to decide how to respond to a parse error. > The server should not assume it knows whether broken XML is due > to client programming error or by some data injection attack. Can the message layer be expected to tell the transport whether a parsing error occured? This is all that is needed so that one can do this: SSH with weak framing: c = nc_msg_process_frame(...); if (c == NC_PARSE_ERROR) { ssh_close_session(); } BEEP with robust framing: c = nc_msg_process_frame(...); if (c == NC_PARSE_ERROR) { beep_resynchronize(); } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Thu Oct 21 12:56:50 2010 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 6DF8C3A683A for ; Thu, 21 Oct 2010 12:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 RwsZHBdoeDgC for ; Thu, 21 Oct 2010 12:56:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 1A5033A67DF for ; Thu, 21 Oct 2010 12:56:49 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 72C022CDE058; Thu, 21 Oct 2010 21:58:23 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101021194132.GD28010@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> <20101021194132.GD28010@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 21:58:21 +0200 Message-ID: <1287691101.1606.141.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 19:56:50 -0000 On Čt, 2010-10-21 at 21:41 +0200, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > > > If there is going to be text that says the server MUST drop the session > > if invalid XML is encountered, then it needs to be for every transport, > > and needs to be in 4741bis. The transport layer should not need to know > > the content is XML instead of text. The protocol layer should not need > > to know which transport was used to decide how to respond to a parse error. > > The server should not assume it knows whether broken XML is due > > to client programming error or by some data injection attack. > > Can the message layer be expected to tell the transport whether a > parsing error occured? This is all that is needed so that one can What do you mean by parsing error? The most problematic messages are well-formed XML and satisfy all other requirements of 4741bis. Lada > do this: > > SSH with weak framing: > > c = nc_msg_process_frame(...); > if (c == NC_PARSE_ERROR) { > ssh_close_session(); > } > > BEEP with robust framing: > > c = nc_msg_process_frame(...); > if (c == NC_PARSE_ERROR) { > beep_resynchronize(); > } > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Oct 21 13:13:33 2010 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 0084F3A683A for ; Thu, 21 Oct 2010 13:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 Cwsh36VN7Xpp for ; Thu, 21 Oct 2010 13:13:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 238723A6838 for ; Thu, 21 Oct 2010 13:13:31 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 5F5182CDE058; Thu, 21 Oct 2010 22:15:06 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201010211921.o9LJL0GA043890@idle.juniper.net> References: <201010211921.o9LJL0GA043890@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 22:15:05 +0200 Message-ID: <1287692105.1606.153.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:13:33 -0000 On Čt, 2010-10-21 at 15:21 -0400, Phil Shafer wrote: > Andy Bierman writes: > >I would like to hear evidence that this EOM sequence is causing problems > >for operators using NETCONF. Is this really a concern to operators? > > It's not an issue for operators, but increases the complexity for > implementors and decreases the robustness of NETCONF. It mixes the > parsing of message boundaries with the parsing of the XML itself. > I consider this a more significant issue than many of the issues > addressed by the current netconf-1.1 draft. Me too. SSH is the required transport in 4741bis, so 4741bis and 4742bis have to be considered together. Now, we have this EOM issue that has security implications, which are however mentioned neither in 4741bis nor in 4742bis. This is IMO unacceptable. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Thu Oct 21 13:20:54 2010 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 BC9B53A6843 for ; Thu, 21 Oct 2010 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.735, 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 dxhGQe-owOEE for ; Thu, 21 Oct 2010 13:20:53 -0700 (PDT) Received: from nm18.bullet.mail.ne1.yahoo.com (nm18.bullet.mail.ne1.yahoo.com [98.138.90.81]) by core3.amsl.com (Postfix) with SMTP id 25EA73A67D9 for ; Thu, 21 Oct 2010 13:20:50 -0700 (PDT) Received: from [98.138.90.57] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2010 20:22:23 -0000 Received: from [98.138.89.164] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2010 20:22:23 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 21 Oct 2010 20:22:23 -0000 X-Yahoo-Newman-Id: 124910.29488.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 40334 invoked from network); 21 Oct 2010 20:22:23 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 21 Oct 2010 13:22:22 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 9mYhn3kVM1nYzSH9TSFfTGV_tEaQogH.UCpy4he_ZcQKIL7 w2TFM_4I2FqsWN7Zc5o9mdgZMm71Kv8wXKBMd.4BZi_MuKdwpb5s9kQSPEfd Gapzz_0gYFET.xRDicjWSg_bpZal2ghx2.TRJiVdS1O4Jv_E7OZXDfrFZl9r BLZiPL7wTSLbEs5RWhZq0WxPWztO80nMLXpEdbHQh9O42S7jHKdf_2gYJCKi ed8w9oVoiHZZbO44sUNOsEtLUVXnfIw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC0A101.1080308@andybierman.com> Date: Thu, 21 Oct 2010 13:22:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Andy Bierman , "Ersue, Mehmet \(NSN - DE/Munich\)" , ext Ladislav Lhotka , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> <20101021194132.GD28010@elstar.local> In-Reply-To: <20101021194132.GD28010@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:20:54 -0000 On 10/21/2010 12:41 PM, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > >> If there is going to be text that says the server MUST drop the session >> if invalid XML is encountered, then it needs to be for every transport, >> and needs to be in 4741bis. The transport layer should not need to know >> the content is XML instead of text. The protocol layer should not need >> to know which transport was used to decide how to respond to a parse error. >> The server should not assume it knows whether broken XML is due >> to client programming error or by some data injection attack. > > Can the message layer be expected to tell the transport whether a > parsing error occured? This is all that is needed so that one can > do this: > > SSH with weak framing: > > c = nc_msg_process_frame(...); > if (c == NC_PARSE_ERROR) { > ssh_close_session(); > } > > BEEP with robust framing: > > c = nc_msg_process_frame(...); > if (c == NC_PARSE_ERROR) { > beep_resynchronize(); > } > The protocol layer would have to code for all supported transports, not just 1. I do not like introducing coupling between the layers here. It seems too complicated. It is extremely unlikely server implementations will parse XML in the SSH layer. This code never knows if it is delivering valid NETCONF messages. It resyncs on its own without any input from the upper layers. Since invalid XML should be extremely rare, and certainly not a use-case, it is not a big deal to shutdown the session whenever invalid XML is received, whether assumed to be due to framing or not. > /js > Andy From mbj@tail-f.com Thu Oct 21 13:33:32 2010 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 E73CD3A67F6 for ; Thu, 21 Oct 2010 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.128, 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 JDd+vZMrmSIs for ; Thu, 21 Oct 2010 13:33:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8C40E3A68F6 for ; Thu, 21 Oct 2010 13:33:30 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 536D2616005; Thu, 21 Oct 2010 22:35:05 +0200 (CEST) Date: Thu, 21 Oct 2010 22:35:03 +0200 (CEST) Message-Id: <20101021.223503.79570188.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4CC0A101.1080308@andybierman.com> References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@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: biermana@Brocade.com, netconf@ietf.org, margaretw42@gmail.com Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:33:32 -0000 Andy Bierman wrote: > Since invalid XML should be extremely rare, and certainly not a use-case, > it is not a big deal to shutdown the session whenever invalid XML is received, > whether assumed to be due to framing or not. So here's a concrete proposal, along these lines. Add the text I proposed earlier to 4741bis: 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 close the NETCONF session. And remove this text from 4742bis: This character sequence cannot legally appear outside of a comment in an XML document, so it can be unambigiously used to identify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error. And then we can revisit this issue when we do NETCONF 2.0. /martin From j.schoenwaelder@jacobs-university.de Thu Oct 21 13:33:53 2010 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 E04FF3A690C for ; Thu, 21 Oct 2010 13:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 slv+EbWPHFdZ for ; Thu, 21 Oct 2010 13:33:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C7FE3A67F6 for ; Thu, 21 Oct 2010 13:33:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F072C0008; Thu, 21 Oct 2010 22:35:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c+EmgSeHBIsG; Thu, 21 Oct 2010 22:35:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CE73C0002; Thu, 21 Oct 2010 22:35:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B2901156C99C; Thu, 21 Oct 2010 22:34:48 +0200 (CEST) Date: Thu, 21 Oct 2010 22:34:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101021203448.GB28148@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> <20101021194132.GD28010@elstar.local> <1287691101.1606.141.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1287691101.1606.141.camel@missotis> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:33:54 -0000 On Thu, Oct 21, 2010 at 09:58:21PM +0200, Ladislav Lhotka wrote: > On Čt, 2010-10-21 at 21:41 +0200, Juergen Schoenwaelder wrote: > > On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > > > > > If there is going to be text that says the server MUST drop the session > > > if invalid XML is encountered, then it needs to be for every transport, > > > and needs to be in 4741bis. The transport layer should not need to know > > > the content is XML instead of text. The protocol layer should not need > > > to know which transport was used to decide how to respond to a parse error. > > > The server should not assume it knows whether broken XML is due > > > to client programming error or by some data injection attack. > > > > Can the message layer be expected to tell the transport whether a > > parsing error occured? This is all that is needed so that one can > > What do you mean by parsing error? The most problematic messages are > well-formed XML and satisfy all other requirements of 4741bis. 4741bis says: [...] If a peer receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. This got added after long debates. Well-formed XML messages are simply processed. If someone injects data that properly closes the current message and opens another one that then properly closes as well, we are simply out of luck. If this is a valid concern, we should close the session immediately after opening it. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Oct 21 13:38:45 2010 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 140D93A6838 for ; Thu, 21 Oct 2010 13:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 RBj2DrqZSWVf for ; Thu, 21 Oct 2010 13:38:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0762A3A6824 for ; Thu, 21 Oct 2010 13:38:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEAE2C0007; Thu, 21 Oct 2010 22:40:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3eW3GRLLAOHl; Thu, 21 Oct 2010 22:40:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9597FC0002; Thu, 21 Oct 2010 22:40:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBE16156CA0A; Thu, 21 Oct 2010 22:39:38 +0200 (CEST) Date: Thu, 21 Oct 2010 22:39:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101021203938.GC28148@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , ext Ladislav Lhotka , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC0A101.1080308@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , Netconf , ext Margaret Wasserman Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:38:45 -0000 On Thu, Oct 21, 2010 at 01:22:25PM -0700, Andy Bierman wrote: > On 10/21/2010 12:41 PM, Juergen Schoenwaelder wrote: > >On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > > > >>If there is going to be text that says the server MUST drop the session > >>if invalid XML is encountered, then it needs to be for every transport, > >>and needs to be in 4741bis. The transport layer should not need to know > >>the content is XML instead of text. The protocol layer should not need > >>to know which transport was used to decide how to respond to a parse error. > >>The server should not assume it knows whether broken XML is due > >>to client programming error or by some data injection attack. > > > >Can the message layer be expected to tell the transport whether a > >parsing error occured? This is all that is needed so that one can > >do this: > > > >SSH with weak framing: > > > > c = nc_msg_process_frame(...); > > if (c == NC_PARSE_ERROR) { > > ssh_close_session(); > > } > > > >BEEP with robust framing: > > > > c = nc_msg_process_frame(...); > > if (c == NC_PARSE_ERROR) { > > beep_resynchronize(); > > } > > > > The protocol layer would have to code for all supported transports, > not just 1. I do not like introducing coupling between the layers > here. It seems too complicated. You did not get the idea. The code fragments sit in the transport code. > It is extremely unlikely server implementations will parse XML in > the SSH layer. Nobody suggested this, we are in agreement. > This code never knows if it is delivering valid NETCONF messages. > It resyncs on its own without any input from the upper layers. Sure it knows - because the message layer tells. > Since invalid XML should be extremely rare, and certainly not a > use-case, it is not a big deal to shutdown the session whenever > invalid XML is received, whether assumed to be due to framing or > not. So you agree to what I proposed. Thanks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Oct 21 13:43:20 2010 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 7A7773A6A7A for ; Thu, 21 Oct 2010 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 iS8655x4gKAU for ; Thu, 21 Oct 2010 13:43:19 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 2A4B63A6824 for ; Thu, 21 Oct 2010 13:43:19 -0700 (PDT) Received: (qmail 15625 invoked from network); 21 Oct 2010 20:44:50 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Oct 2010 13:44:49 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: XDGWnwYVM1nCF8w1vnhUvm8cZkUTaFEjKvJuPzAE.id5PtX kSV3RHKotCDGMj.iuU7CYQxS5UorvFE4p0vEjTPFZWHJ6nb3IVHBDFB6zir5 pZVDQyrlYZc_GVrDEf4NQW.jyTCoMKWUj5YEInGH.BRXlQ7LiAGdnhMDVQ.Q pQU1.o3X7BhKIAjaSXGIxPG7gCPEk4WVr5D2G9iumxJwgl8MzoCj2A1.jsKi nEyJWCjqDYVJso.LeNLgPwN5Pv2r55wTtmD9ZUHQvRmXxrsFX1V2Byan74st Ml3nC_ZSG9jCYbQXanUVYNSJ2sfjyiMJKTxf_V2PJzGhAO9g9Mg9MA1HItIr dTeE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC0A640.6040505@andybierman.com> Date: Thu, 21 Oct 2010 13:44:48 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: Martin Bjorklund References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> In-Reply-To: <20101021.223503.79570188.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netconf@ietf.org, margaretw42@gmail.com Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 20:43:20 -0000 On 10/21/2010 01:35 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Since invalid XML should be extremely rare, and certainly not a use-case, >> it is not a big deal to shutdown the session whenever invalid XML is received, >> whether assumed to be due to framing or not. > > So here's a concrete proposal, along these lines. > > Add the text I proposed earlier to 4741bis: > > 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 > close the NETCONF session. > > And remove this text from 4742bis: > > This > character sequence cannot legally appear outside of a comment in an > XML document, so it can be unambigiously used to identify the end of > the current document, allowing resynchronization of the NETCONF > exchange in the event of an XML syntax or parsing error. > > > And then we can revisit this issue when we do NETCONF 2.0. > > Looks good to me. > > /martin > > Andy From biermana@Brocade.com Thu Oct 21 15:09:47 2010 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 A5C4E3A6848 for ; Thu, 21 Oct 2010 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.167, 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 c90o37i6fm+x for ; Thu, 21 Oct 2010 15:09:40 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 7F2703A6838 for ; Thu, 21 Oct 2010 15:09:38 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LMBDsU031347; Thu, 21 Oct 2010 15:11:13 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s2vnrr1cq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 15:11:12 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 15:15:30 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 21 Oct 2010 15:11:11 -0700 From: Andy Bierman To: Ladislav Lhotka , Phil Shafer Date: Thu, 21 Oct 2010 15:11:10 -0700 Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActxXKx4ae7j3JuSRTGf0hqPHHcvDwAD8C+Q Message-ID: References: <201010211921.o9LJL0GA043890@idle.juniper.net> <1287692105.1606.153.camel@missotis> In-Reply-To: <1287692105.1606.153.camel@missotis> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-21_11:2010-10-22, 2010-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210197 X-Proofpoint-SSN: Sensitivity2 Cc: Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 21 Oct 2010 22:09:47 -0000 SGksDQoNCkkgZG9uJ3QgYWdyZWUgdGhhdCBjb21wbGV4aXR5IGlzIGluY3JlYXNlZCBieSBhbnkg bWVhc3VyYWJsZSBhbW91bnQuDQoNCkkgaGF2ZSBub3QgaGVhcmQgYSBwcm9wb3NhbCBmb3IgYW4g YWNjZXB0YWJsZSBzb2x1dGlvbi4NClJlcXVpcmluZyBidWZmZXJpbmcgaW4gdGhlIHNlcnZlciBp cyBub3QgZ29pbmcgdG8gYmUgaW1wbGVtZW50ZWQuDQpJZiBpdCBpcyBhIGJ1cmRlbiBmb3IgYSBz ZXJ2ZXIgdG8gcmVjZWl2ZSBwYXJ0IG9mIGEgbGlzdCBiZWZvcmUgdGhlIGtleXMsDQp0aGVuIGl0 IGlzIGEgYnVyZGVuIHRvIGJ1ZmZlciBhbnkgcGFydCBvZiB0aGUgcnBjLXJlcGx5IGFzIHdlbGwu DQoNCg0KQW5keQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBMYWRpc2xhdiBMaG90a2ENClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIxLCAyMDEw IDE6MTUgUE0NClRvOiBQaGlsIFNoYWZlcg0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0 Y29uZl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDIFJGQzQ3NDFi aXMNCg0KT24gxIx0LCAyMDEwLTEwLTIxIGF0IDE1OjIxIC0wNDAwLCBQaGlsIFNoYWZlciB3cm90 ZToNCj4gQW5keSBCaWVybWFuIHdyaXRlczoNCj4gPkkgd291bGQgbGlrZSB0byBoZWFyIGV2aWRl bmNlIHRoYXQgdGhpcyBFT00gc2VxdWVuY2UgaXMgY2F1c2luZyBwcm9ibGVtcw0KPiA+Zm9yIG9w ZXJhdG9ycyB1c2luZyBORVRDT05GLiAgSXMgdGhpcyByZWFsbHkgYSBjb25jZXJuIHRvIG9wZXJh dG9ycz8NCj4gDQo+IEl0J3Mgbm90IGFuIGlzc3VlIGZvciBvcGVyYXRvcnMsIGJ1dCBpbmNyZWFz ZXMgdGhlIGNvbXBsZXhpdHkgZm9yDQo+IGltcGxlbWVudG9ycyBhbmQgZGVjcmVhc2VzIHRoZSBy b2J1c3RuZXNzIG9mIE5FVENPTkYuICBJdCBtaXhlcyB0aGUNCj4gcGFyc2luZyBvZiBtZXNzYWdl IGJvdW5kYXJpZXMgd2l0aCB0aGUgcGFyc2luZyBvZiB0aGUgWE1MIGl0c2VsZi4NCj4gSSBjb25z aWRlciB0aGlzIGEgbW9yZSBzaWduaWZpY2FudCBpc3N1ZSB0aGFuIG1hbnkgb2YgdGhlIGlzc3Vl cw0KPiBhZGRyZXNzZWQgYnkgdGhlIGN1cnJlbnQgbmV0Y29uZi0xLjEgZHJhZnQuDQoNCk1lIHRv by4gU1NIIGlzIHRoZSByZXF1aXJlZCB0cmFuc3BvcnQgaW4gNDc0MWJpcywgc28gNDc0MWJpcyBh bmQNCjQ3NDJiaXMgaGF2ZSB0byBiZSBjb25zaWRlcmVkIHRvZ2V0aGVyLiBOb3csIHdlIGhhdmUg dGhpcyBFT00gaXNzdWUgdGhhdA0KaGFzIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgd2hpY2ggYXJl IGhvd2V2ZXIgbWVudGlvbmVkIG5laXRoZXIgaW4NCjQ3NDFiaXMgbm9yIGluIDQ3NDJiaXMuIFRo aXMgaXMgSU1PIHVuYWNjZXB0YWJsZS4NCg0KTGFkYQ0KIA0KPiANCj4gVGhhbmtzLA0KPiAgUGhp bA0KDQotLSANCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQpQR1AgS2V5IElEOiBFNzRFOEMwQw0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRj b25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From root@core3.amsl.com Thu Oct 21 15:15:03 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A2053A6838; Thu, 21 Oct 2010 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021221502.4A2053A6838@core3.amsl.com> Date: Thu, 21 Oct 2010 15:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-01.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: Thu, 21 Oct 2010 22: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 : NETCONF System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-01.txt Pages : 12 Date : 2010-10-21 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common system events such as a change in system capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the system events within the NETCONF server. This document defines a YANG module which allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-01.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-system-notifications-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21150522.I-D@ietf.org> --NextPart-- From phil@juniper.net Thu Oct 21 19:49:47 2010 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 9C9E53A6833 for ; Thu, 21 Oct 2010 19:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 vRQbEo-FSh9T for ; Thu, 21 Oct 2010 19:49:44 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 8BD3C3A682F for ; Thu, 21 Oct 2010 19:49:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTMD8J5eDxUjPV3pQcj793znD9TiseHzE@postini.com; Thu, 21 Oct 2010 19:51:21 PDT 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; Thu, 21 Oct 2010 19:48:55 -0700 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 o9M2msU58212; Thu, 21 Oct 2010 19:48:54 -0700 (PDT) (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 o9M2RwpW046300; Fri, 22 Oct 2010 02:27:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010220227.o9M2RwpW046300@idle.juniper.net> To: Andy Bierman Date: Thu, 21 Oct 2010 22:27:58 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 02:49:47 -0000 Andy Bierman writes: >I have not heard a proposal for an acceptable solution. Lada has suggested using a truly illegal character (<0x20). I suggested a "chunked" approach, where a block of data is prefaced by the length and an indication of whether it's the final chunk. Either solution is reasonable. Thanks, Phil From lhotka@cesnet.cz Fri Oct 22 01:45:12 2010 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 63ECA3A6800 for ; Fri, 22 Oct 2010 01:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 hYlnXyTx9wEE for ; Fri, 22 Oct 2010 01:45:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 2D1FD3A685B for ; Fri, 22 Oct 2010 01:45:10 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id CC5752CDE05D; Fri, 22 Oct 2010 10:46:46 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201010220227.o9M2RwpW046300@idle.juniper.net> References: <201010220227.o9M2RwpW046300@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 10:46:45 +0200 Message-ID: <1287737205.10487.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 08:45:12 -0000 On Čt, 2010-10-21 at 22:27 -0400, Phil Shafer wrote: > Andy Bierman writes: > >I have not heard a proposal for an acceptable solution. > > Lada has suggested using a truly illegal character (<0x20). I > suggested a "chunked" approach, where a block of data is prefaced > by the length and an indication of whether it's the final chunk. > Either solution is reasonable. And Per suggested the bit stuffing. Each of the methods has its pros and cons but each will also solve the issue in a clean way. As it is now, there are valid NETCONF messages that the SSH transport fails to deliver as valid messages to the opposite end, hence the transport protocol is broken. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Oct 22 01:56:11 2010 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 A8C283A6840 for ; Fri, 22 Oct 2010 01:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 wuxMVlFJnHSY for ; Fri, 22 Oct 2010 01:56:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 6EB213A6782 for ; Fri, 22 Oct 2010 01:56:10 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0F8202CDE058; Fri, 22 Oct 2010 10:57:47 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101021203448.GB28148@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <20101021191108.GA28010@elstar.local> <20101021194132.GD28010@elstar.local> <1287691101.1606.141.camel@missotis> <20101021203448.GB28148@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 10:57:46 +0200 Message-ID: <1287737866.10487.9.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 08:56:11 -0000 On Čt, 2010-10-21 at 22:34 +0200, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 09:58:21PM +0200, Ladislav Lhotka wrote: > > On Čt, 2010-10-21 at 21:41 +0200, Juergen Schoenwaelder wrote: > > > On Thu, Oct 21, 2010 at 12:29:41PM -0700, Andy Bierman wrote: > > > > > > > If there is going to be text that says the server MUST drop the session > > > > if invalid XML is encountered, then it needs to be for every transport, > > > > and needs to be in 4741bis. The transport layer should not need to know > > > > the content is XML instead of text. The protocol layer should not need > > > > to know which transport was used to decide how to respond to a parse error. > > > > The server should not assume it knows whether broken XML is due > > > > to client programming error or by some data injection attack. > > > > > > Can the message layer be expected to tell the transport whether a > > > parsing error occured? This is all that is needed so that one can > > > > What do you mean by parsing error? The most problematic messages are > > well-formed XML and satisfy all other requirements of 4741bis. > > 4741bis says: > > [...] If a > peer receives a message that is not well-formed XML, it MUST reply > with an 'operation-failed' error. > > This got added after long debates. OK, but this issue is different from the EOM justification in 4742bis. I missed the change in topics, sorry. > > Well-formed XML messages are simply processed. If someone injects data > that properly closes the current message and opens another one that > then properly closes as well, we are simply out of luck. If this is a > valid concern, we should close the session immediately after opening > it. ;-) Agreed. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Oct 22 02:12:08 2010 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 A83E53A6887 for ; Fri, 22 Oct 2010 02:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VmC2QgdOyYiK for ; Fri, 22 Oct 2010 02:12:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B7A473A6782 for ; Fri, 22 Oct 2010 02:12:05 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3C4682CDE05D; Fri, 22 Oct 2010 11:13:42 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20101021.223503.79570188.mbj@tail-f.com> References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 11:13:41 +0200 Message-ID: <1287738821.10487.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: margaretw42@gmail.com, biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 09:12:08 -0000 On Čt, 2010-10-21 at 22:35 +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > Since invalid XML should be extremely rare, and certainly not a use-case, > > it is not a big deal to shutdown the session whenever invalid XML is received, > > whether assumed to be due to framing or not. > > So here's a concrete proposal, along these lines. > > Add the text I proposed earlier to 4741bis: > > 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 > close the NETCONF session. I think it should also send an error message before closing, otherwise I agree. > > And remove this text from 4742bis: > > This > character sequence cannot legally appear outside of a comment in an > XML document, so it can be unambigiously used to identify the end of > the current document, allowing resynchronization of the NETCONF > exchange in the event of an XML syntax or parsing error. But this means sweeping the issue under the carpet. How about telling the whole truth, i.e. 1. Originally it was believed the EOM sequence cannot appear in any XML document. 2. This assumption turned out to be wrong but now this mistake cannot be mitigated in a backwards compatible way. 3. As a result, the SSH transport is not 100% reliable and safe and may lead to operational problems and open space for attacks. It is however believed that the associated threat is not very high. On the other hand, making incompatible changes would break existing clients. 4. NETCONF implementations using the SSH transport must exercise extra care and make sure the EOM sequence is not present in NETCONF messages before passing them to the Transport layer, even if they were well-formed XML. Lada > > > And then we can revisit this issue when we do NETCONF 2.0. > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Fri Oct 22 04:18:51 2010 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 2FD6B3A68EB for ; Fri, 22 Oct 2010 04:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 5+h1NxbKXusd for ; Fri, 22 Oct 2010 04:18:49 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 93D6A3A686A for ; Fri, 22 Oct 2010 04:18:46 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P9FfR-0000IU-T6; Fri, 22 Oct 2010 13:20:21 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest62.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P9FfR-0007Ow-Nw; Fri, 22 Oct 2010 13:20:13 +0200 Message-ID: <4CC1736D.4010903@bwijnen.net> Date: Fri, 22 Oct 2010 13:20:13 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Andy Bierman References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ee78d2a76f0c349420cca128f4927817 X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ee78d2a76f0c349420cca128f4927817 Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 11:18:51 -0000 As a technical contributor. My understanding was (and still is): - at rfc4741 time, we thought that the sequence could NOT legally occur in an XML document. - so we decided that the sequence serves as an EOM. Which I understand to mean that the SSH layer does not (at least does not need to) parse XML at all. It just searched in the stream for the EOM sequence, and then passes the data up to that point to the netconf layer. - we learned later that the sequence may occur in comments and decided that we do not consider that as a problem, ans do we do (or should) advise users to NOT use the EOM sequence in XML comments - then yet later we learned that it can occur in PI and attribute values, but we decided (or concluded based on experience) that we are not using/needing PI in NETCONF or NETCONF content, and that we also do not need it in attribute values. So, we figure it is still OK to use the EOM marker, at least untill someone shows us a good use case where our EOM marker is needed with NETCONF. So, we want be correct/precise/honest in exactly specifying how the sequence can theoretically and legally appear in an XML document. We then want to state that we believe, based on our experience, that that sequence is in practice not used/needed in NETCONF, and so that we still believe it is OK to use that sequence as EOM marker, no matter where in the transport stream it occurs. We could add a question that if anyone ever sees a need to use the sequence that they better inform us (netconf WG) asap with a good description of the scenario. Bert On 10/21/10 8:51 PM, Andy Bierman wrote: > Hi, > > The original intent was to use a char sequence that was not legal in > an XML instance document. Nobody in the WG at the time knew for sure, > so we asked the XML Directorate. We worked under the assumption that > the ]]>]]> sequence was a suitable message boundary marker. > > I would like to hear evidence that this EOM sequence is causing problems > for operators using NETCONF. Is this really a concern to operators? > Would a significant protocol change to address this issue cause more > operational problems than it solves? > > I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > We should decide at the time, after some more deployment experience. > > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) > Sent: Thursday, October 21, 2010 11:21 AM > To: ext Ladislav Lhotka > Cc: ext Margaret Wasserman; Netconf > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis > > Hi Lada, > >> Hi Mehmet, >> >> On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> Hi Lada, >>> >>> [speaking as a contributor] >>> >>> if I understand you correctly you want to allow the EOM >>> not only in comments but also in XML attributes and PIs. >>> >>> In case the answer is no: I appear to misunderstand what >>> you were saying. So pls explain. >> I certainly don't want to allow anything that isn't already allowed. :- >> ) >> >> The current text says, as I understand it, that XML specification >> doesn't allow the EOM marker to appear outside comments in an XML >> document (and therefore it is a good choice). But this is not true: XML >> documents having the sequence in PIs and attribute values are >> well-formed as well. The only place where the sequence is really >> forbidden is element text. > "This character sequence cannot legally appear in an XML document, so > it can be unambigiously used to indentify the end of the current > document in the event of an XML syntax or parsing error, allowing > resynchronization of the NETCONF exchange." > > The sentence is actually since May 2004 (v01) in SSH document > and did not change until today. I don't know exactly what the > aim of the authors was to write it that way. > > One option is they wanted to state that the EOM "... MUST NOT > appear outside of a comment in an XML document", which would > be a consistent restriction. > > The other option is how you understand it: > "XML specification doesn't allow the EOM marker to appear > outside comments" > > ...which is obviously not correct and can be addressed as > you suggest. But this would mean additional implementation > effort for SSH transport. > > Margaret, Ted, Andy: > Can you please clarify what the original aim was? > > What do others in the WG think? > Please state your opinion before Friday EOB. > > Mehmet > >> Lada >> >>> In case the answer is yes: >>> >>> Theoretically the EOM sequence can appear everywhere in >>> an XML document. >>> >>> However, the transport layer shouldn't do fine grained >>> parsing of the XML document, to find out where the >>> attributes or PIs are. >>> This is the reason why 4742 kept it simple and, as I >>> think, appropriate for the transport layer. >>> >>> I don't see any difference between XML elements and >>> [attributes or PI]. They all are XML data. And EOM can >>> appear in XML data or at the end of the document. >>> If somebody wants to disrupt the rpc command he can >>> do it no matter in elements or attributes. >>> >>> So, at the end I don't see any benefit in reducing the >>> restriction and think: >>> To be on the safe side and to keep it simple for the >>> implementer of 4742bis the sequence must not appear >>> in the XML document (except outside of comments). >>> >>> [now the chair hat on]: >>> >>> Please keep in mind that we don't have the mandate >>> for v2.0. We are just doing bug-fixing. >>> >>> I agree with you that v2.0 should solve this issue >>> with a thorough solution. Would you like to prepare >>> a few slides for the NETCONF session in Beijing for >>> a solution, which could be put later into v2.0? >>> >>> Cheers, >>> Mehmet >>> >>> >>>> -----Original Message----- >>>> From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] >>>> Sent: Wednesday, October 20, 2010 7:23 PM >>>> To: Ersue, Mehmet (NSN - DE/Munich) >>>> Cc: Netconf; ext Margaret Wasserman >>>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC >>>> RFC4741bis >>>> >>>> On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) >>>> wrote: >>>>> Hi All, >>>>> >>>>> same is with 4742bis WGLC discusion. We had only minor >>>>> changes after IETF 78. Our impression is that we have >>>>> consensus to see the draft as final. >>>>> >>>>> Margaret submitted the draft today making it ready for >>>>> AD review. Please check the changes by 10/22 so that >>>>> we have a chance to re-submit before deadline. Thanks. >>>> The justification for the EOM marker in sec. 3.1 is technically >>>> incorrect - and I objected against it previously: >>>> http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html >>>> >>>> Here is the change I propose (there's also a typo in >> "unambiguously"): >>>> OLD >>>> >>>> This character sequence cannot legally appear outside of a comment >> in >>>> an >>>> XML document, so it can be unambigiously used to identify the end >> of >>>> the >>>> current document, allowing resynchronization of the NETCONF >> exchange in >>>> the event of an XML syntax or parsing error. >>>> >>>> NEW >>>> >>>> This character sequence cannot legally appear outside of a comment, >>>> processing instruction and attribute value in an XML document, so >> it >>>> can >>>> be unambiguously used to identify the end of the current document, >>>> allowing resynchronization of the NETCONF exchange in the event of >> an >>>> XML syntax or parsing error. >>>> >>>> Lada >>>> >>>>> Cheers, >>>>> Mehmet >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] >> On >>>>> Behalf Of ext Bert Wijnen (IETF) >>>>> Sent: Wednesday, October 20, 2010 3:52 PM >>>>> To: Netconf >>>>> Subject: [Netconf] status WGLC RFC4741bis >>>>> >>>>> It seems that the WGLC discussion has now died out on the mailing >>>> list. >>>>> From re-reading all those comments, I also get the impression >> that >>>>> there is consensus/agreement on the changes that need to be >>>> addressed. >>>>> The editors (specifically Martin) is preparing a new revision >> based >>>>> on the result of the discussions. Will probably show up later >> today. >>>>> Our plan as WG-chairs is to allow the WG a few days to quickly >> check >>>>> if the changes are OK. Then ask our Ad to bring it forward to >> IETF >>>>> Last Call and IESG review. >>>>> >>>>> Thanks, >>>>> Bert and Mehmet >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> e-mail message attachment >>>>>> -------- Forwarded Message -------- >>>>>> From: Internet-Drafts@ietf.org >>>>>> Reply-to: >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: netconf@ietf.org >>>>>> Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt >>>>>> Date: Wed, 20 Oct 2010 17:00:02 +0200 >>>>>> >>>>>> 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-03.txt >>>>>> Pages : 10 >>>>>> Date : 2010-10-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- >>>> 03.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 >>>> -- >>>> Ladislav Lhotka, CESNET >>>> PGP Key ID: E74E8C0C >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C > _______________________________________________ > 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 lhotka@cesnet.cz Fri Oct 22 04:36:36 2010 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 7DAC73A680D for ; Fri, 22 Oct 2010 04:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 KG4Noi2bHJQO for ; Fri, 22 Oct 2010 04:36:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 6EB543A686A for ; Fri, 22 Oct 2010 04:36:32 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 416702CDE05D; Fri, 22 Oct 2010 13:38:09 +0200 (CEST) From: Ladislav Lhotka To: "Bert (IETF) Wijnen" In-Reply-To: <4CC1736D.4010903@bwijnen.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 13:38:08 +0200 Message-ID: <1287747488.12363.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 11:36:36 -0000 On Pá, 2010-10-22 at 13:20 +0200, Bert (IETF) Wijnen wrote: > As a technical contributor. > > My understanding was (and still is): > > - at rfc4741 time, we thought that the sequence could NOT legally occur > in an XML document. > - so we decided that the sequence serves as an EOM. Which I understand to mean > that the SSH layer does not (at least does not need to) parse XML at all. It just > searched in the stream for the EOM sequence, and then passes the data up > to that point to the netconf layer. > - we learned later that the sequence may occur in comments and decided that > we do not consider that as a problem, ans do we do (or should) advise > users to NOT use the EOM sequence in XML comments > - then yet later we learned that it can occur in PI and attribute values, but we decided > (or concluded based on experience) that we are not using/needing PI in NETCONF > or NETCONF content, and that we also do not need it in attribute values. > So, we figure it is still OK to use the EOM marker, at least untill someone shows us > a good use case where our EOM marker is needed with NETCONF. It may not be needed but it is available to attackers who may try to inject the marker in various places. This could be done indirectly, by exploiting other holes such as stack overflow in the client code. If this ever happens, all NETCONF implementations will have to be patched very quickly. I think it is better to fix it NOW than in such an emergency situation. Lada > > So, we want be correct/precise/honest in exactly specifying how the sequence can > theoretically and legally appear in an XML document. > We then want to state that we believe, based on our experience, that that sequence > is in practice not used/needed in NETCONF, and so that we still believe it is OK > to use that sequence as EOM marker, no matter where in the transport stream it > occurs. > > We could add a question that if anyone ever sees a need to use the sequence that > they better inform us (netconf WG) asap with a good description of the scenario. > > Bert > > On 10/21/10 8:51 PM, Andy Bierman wrote: > > Hi, > > > > The original intent was to use a char sequence that was not legal in > > an XML instance document. Nobody in the WG at the time knew for sure, > > so we asked the XML Directorate. We worked under the assumption that > > the ]]>]]> sequence was a suitable message boundary marker. > > > > I would like to hear evidence that this EOM sequence is causing problems > > for operators using NETCONF. Is this really a concern to operators? > > Would a significant protocol change to address this issue cause more > > operational problems than it solves? > > > > I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > > We should decide at the time, after some more deployment experience. > > > > > > Andy > > > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) > > Sent: Thursday, October 21, 2010 11:21 AM > > To: ext Ladislav Lhotka > > Cc: ext Margaret Wasserman; Netconf > > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis > > > > Hi Lada, > > > >> Hi Mehmet, > >> > >> On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) > >> wrote: > >>> Hi Lada, > >>> > >>> [speaking as a contributor] > >>> > >>> if I understand you correctly you want to allow the EOM > >>> not only in comments but also in XML attributes and PIs. > >>> > >>> In case the answer is no: I appear to misunderstand what > >>> you were saying. So pls explain. > >> I certainly don't want to allow anything that isn't already allowed. :- > >> ) > >> > >> The current text says, as I understand it, that XML specification > >> doesn't allow the EOM marker to appear outside comments in an XML > >> document (and therefore it is a good choice). But this is not true: XML > >> documents having the sequence in PIs and attribute values are > >> well-formed as well. The only place where the sequence is really > >> forbidden is element text. > > "This character sequence cannot legally appear in an XML document, so > > it can be unambigiously used to indentify the end of the current > > document in the event of an XML syntax or parsing error, allowing > > resynchronization of the NETCONF exchange." > > > > The sentence is actually since May 2004 (v01) in SSH document > > and did not change until today. I don't know exactly what the > > aim of the authors was to write it that way. > > > > One option is they wanted to state that the EOM "... MUST NOT > > appear outside of a comment in an XML document", which would > > be a consistent restriction. > > > > The other option is how you understand it: > > "XML specification doesn't allow the EOM marker to appear > > outside comments" > > > > ...which is obviously not correct and can be addressed as > > you suggest. But this would mean additional implementation > > effort for SSH transport. > > > > Margaret, Ted, Andy: > > Can you please clarify what the original aim was? > > > > What do others in the WG think? > > Please state your opinion before Friday EOB. > > > > Mehmet > > > >> Lada > >> > >>> In case the answer is yes: > >>> > >>> Theoretically the EOM sequence can appear everywhere in > >>> an XML document. > >>> > >>> However, the transport layer shouldn't do fine grained > >>> parsing of the XML document, to find out where the > >>> attributes or PIs are. > >>> This is the reason why 4742 kept it simple and, as I > >>> think, appropriate for the transport layer. > >>> > >>> I don't see any difference between XML elements and > >>> [attributes or PI]. They all are XML data. And EOM can > >>> appear in XML data or at the end of the document. > >>> If somebody wants to disrupt the rpc command he can > >>> do it no matter in elements or attributes. > >>> > >>> So, at the end I don't see any benefit in reducing the > >>> restriction and think: > >>> To be on the safe side and to keep it simple for the > >>> implementer of 4742bis the sequence must not appear > >>> in the XML document (except outside of comments). > >>> > >>> [now the chair hat on]: > >>> > >>> Please keep in mind that we don't have the mandate > >>> for v2.0. We are just doing bug-fixing. > >>> > >>> I agree with you that v2.0 should solve this issue > >>> with a thorough solution. Would you like to prepare > >>> a few slides for the NETCONF session in Beijing for > >>> a solution, which could be put later into v2.0? > >>> > >>> Cheers, > >>> Mehmet > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] > >>>> Sent: Wednesday, October 20, 2010 7:23 PM > >>>> To: Ersue, Mehmet (NSN - DE/Munich) > >>>> Cc: Netconf; ext Margaret Wasserman > >>>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > >>>> RFC4741bis > >>>> > >>>> On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) > >>>> wrote: > >>>>> Hi All, > >>>>> > >>>>> same is with 4742bis WGLC discusion. We had only minor > >>>>> changes after IETF 78. Our impression is that we have > >>>>> consensus to see the draft as final. > >>>>> > >>>>> Margaret submitted the draft today making it ready for > >>>>> AD review. Please check the changes by 10/22 so that > >>>>> we have a chance to re-submit before deadline. Thanks. > >>>> The justification for the EOM marker in sec. 3.1 is technically > >>>> incorrect - and I objected against it previously: > >>>> http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html > >>>> > >>>> Here is the change I propose (there's also a typo in > >> "unambiguously"): > >>>> OLD > >>>> > >>>> This character sequence cannot legally appear outside of a comment > >> in > >>>> an > >>>> XML document, so it can be unambigiously used to identify the end > >> of > >>>> the > >>>> current document, allowing resynchronization of the NETCONF > >> exchange in > >>>> the event of an XML syntax or parsing error. > >>>> > >>>> NEW > >>>> > >>>> This character sequence cannot legally appear outside of a comment, > >>>> processing instruction and attribute value in an XML document, so > >> it > >>>> can > >>>> be unambiguously used to identify the end of the current document, > >>>> allowing resynchronization of the NETCONF exchange in the event of > >> an > >>>> XML syntax or parsing error. > >>>> > >>>> Lada > >>>> > >>>>> Cheers, > >>>>> Mehmet > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > >> On > >>>>> Behalf Of ext Bert Wijnen (IETF) > >>>>> Sent: Wednesday, October 20, 2010 3:52 PM > >>>>> To: Netconf > >>>>> Subject: [Netconf] status WGLC RFC4741bis > >>>>> > >>>>> It seems that the WGLC discussion has now died out on the mailing > >>>> list. > >>>>> From re-reading all those comments, I also get the impression > >> that > >>>>> there is consensus/agreement on the changes that need to be > >>>> addressed. > >>>>> The editors (specifically Martin) is preparing a new revision > >> based > >>>>> on the result of the discussions. Will probably show up later > >> today. > >>>>> Our plan as WG-chairs is to allow the WG a few days to quickly > >> check > >>>>> if the changes are OK. Then ask our Ad to bring it forward to > >> IETF > >>>>> Last Call and IESG review. > >>>>> > >>>>> Thanks, > >>>>> Bert and Mehmet > >>>>> _______________________________________________ > >>>>> Netconf mailing list > >>>>> Netconf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netconf > >>>>> e-mail message attachment > >>>>>> -------- Forwarded Message -------- > >>>>>> From: Internet-Drafts@ietf.org > >>>>>> Reply-to: > >>>>>> To: i-d-announce@ietf.org > >>>>>> Cc: netconf@ietf.org > >>>>>> Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt > >>>>>> Date: Wed, 20 Oct 2010 17:00:02 +0200 > >>>>>> > >>>>>> 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-03.txt > >>>>>> Pages : 10 > >>>>>> Date : 2010-10-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- > >>>> 03.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 > >>>> -- > >>>> Ladislav Lhotka, CESNET > >>>> PGP Key ID: E74E8C0C > >> -- > >> Ladislav Lhotka, CESNET > >> PGP Key ID: E74E8C0C > > _______________________________________________ > > 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 bertietf@bwijnen.net Fri Oct 22 05:12:29 2010 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 E90473A68E2 for ; Fri, 22 Oct 2010 05:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 UZr8uw4Ibjn3 for ; Fri, 22 Oct 2010 05:12:27 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id AC8803A68E0 for ; Fri, 22 Oct 2010 05:12:24 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P9GVK-0000Nr-Sj; Fri, 22 Oct 2010 14:13:58 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest62.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1P9GVH-0003Z5-L1; Fri, 22 Oct 2010 14:13:48 +0200 Message-ID: <4CC17FFB.8020406@bwijnen.net> Date: Fri, 22 Oct 2010 14:13:47 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <1287747488.12363.35.camel@missotis> In-Reply-To: <1287747488.12363.35.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48b5da49b321b00f3fce59e1146d2040a X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48b5da49b321b00f3fce59e1146d2040a Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 12:12:30 -0000 On 10/22/10 1:38 PM, Ladislav Lhotka wrote: > On Pá, 2010-10-22 at 13:20 +0200, Bert (IETF) Wijnen wrote: >> As a technical contributor. >> >> My understanding was (and still is): >> >> - at rfc4741 time, we thought that the sequence could NOT legally occur >> in an XML document. >> - so we decided that the sequence serves as an EOM. Which I understand to mean >> that the SSH layer does not (at least does not need to) parse XML at all. It just >> searched in the stream for the EOM sequence, and then passes the data up >> to that point to the netconf layer. >> - we learned later that the sequence may occur in comments and decided that >> we do not consider that as a problem, ans do we do (or should) advise >> users to NOT use the EOM sequence in XML comments >> - then yet later we learned that it can occur in PI and attribute values, but we decided >> (or concluded based on experience) that we are not using/needing PI in NETCONF >> or NETCONF content, and that we also do not need it in attribute values. >> So, we figure it is still OK to use the EOM marker, at least untill someone shows us >> a good use case where our EOM marker is needed with NETCONF. > It may not be needed but it is available to attackers who may try to > inject the marker in various places. This could be done indirectly, by > exploiting other holes such as stack overflow in the client code. > > If this ever happens, all NETCONF implementations will have to be > patched very quickly. I think it is better to fix it NOW than in such an > emergency situation. > Lada, that "fix it now" may be better in the view of some people, but we were unable to reach agreement on fixing it now. So that "better fix it now" is no longer open for discussion. We're discussing how to best document the situation we have created. Bert (now speaking as a WG chair) > Lada > >> So, we want be correct/precise/honest in exactly specifying how the sequence can >> theoretically and legally appear in an XML document. >> We then want to state that we believe, based on our experience, that that sequence >> is in practice not used/needed in NETCONF, and so that we still believe it is OK >> to use that sequence as EOM marker, no matter where in the transport stream it >> occurs. >> >> We could add a question that if anyone ever sees a need to use the sequence that >> they better inform us (netconf WG) asap with a good description of the scenario. >> >> Bert >> >> On 10/21/10 8:51 PM, Andy Bierman wrote: >>> Hi, >>> >>> The original intent was to use a char sequence that was not legal in >>> an XML instance document. Nobody in the WG at the time knew for sure, >>> so we asked the XML Directorate. We worked under the assumption that >>> the ]]>]]> sequence was a suitable message boundary marker. >>> >>> I would like to hear evidence that this EOM sequence is causing problems >>> for operators using NETCONF. Is this really a concern to operators? >>> Would a significant protocol change to address this issue cause more >>> operational problems than it solves? >>> >>> I do not agree that this must be fixed in NETCONF 2.0, whenever that is. >>> We should decide at the time, after some more deployment experience. >>> >>> >>> Andy >>> >>> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) >>> Sent: Thursday, October 21, 2010 11:21 AM >>> To: ext Ladislav Lhotka >>> Cc: ext Margaret Wasserman; Netconf >>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis >>> >>> Hi Lada, >>> >>>> Hi Mehmet, >>>> >>>> On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) >>>> wrote: >>>>> Hi Lada, >>>>> >>>>> [speaking as a contributor] >>>>> >>>>> if I understand you correctly you want to allow the EOM >>>>> not only in comments but also in XML attributes and PIs. >>>>> >>>>> In case the answer is no: I appear to misunderstand what >>>>> you were saying. So pls explain. >>>> I certainly don't want to allow anything that isn't already allowed. :- >>>> ) >>>> >>>> The current text says, as I understand it, that XML specification >>>> doesn't allow the EOM marker to appear outside comments in an XML >>>> document (and therefore it is a good choice). But this is not true: XML >>>> documents having the sequence in PIs and attribute values are >>>> well-formed as well. The only place where the sequence is really >>>> forbidden is element text. >>> "This character sequence cannot legally appear in an XML document, so >>> it can be unambigiously used to indentify the end of the current >>> document in the event of an XML syntax or parsing error, allowing >>> resynchronization of the NETCONF exchange." >>> >>> The sentence is actually since May 2004 (v01) in SSH document >>> and did not change until today. I don't know exactly what the >>> aim of the authors was to write it that way. >>> >>> One option is they wanted to state that the EOM "... MUST NOT >>> appear outside of a comment in an XML document", which would >>> be a consistent restriction. >>> >>> The other option is how you understand it: >>> "XML specification doesn't allow the EOM marker to appear >>> outside comments" >>> >>> ...which is obviously not correct and can be addressed as >>> you suggest. But this would mean additional implementation >>> effort for SSH transport. >>> >>> Margaret, Ted, Andy: >>> Can you please clarify what the original aim was? >>> >>> What do others in the WG think? >>> Please state your opinion before Friday EOB. >>> >>> Mehmet >>> >>>> Lada >>>> >>>>> In case the answer is yes: >>>>> >>>>> Theoretically the EOM sequence can appear everywhere in >>>>> an XML document. >>>>> >>>>> However, the transport layer shouldn't do fine grained >>>>> parsing of the XML document, to find out where the >>>>> attributes or PIs are. >>>>> This is the reason why 4742 kept it simple and, as I >>>>> think, appropriate for the transport layer. >>>>> >>>>> I don't see any difference between XML elements and >>>>> [attributes or PI]. They all are XML data. And EOM can >>>>> appear in XML data or at the end of the document. >>>>> If somebody wants to disrupt the rpc command he can >>>>> do it no matter in elements or attributes. >>>>> >>>>> So, at the end I don't see any benefit in reducing the >>>>> restriction and think: >>>>> To be on the safe side and to keep it simple for the >>>>> implementer of 4742bis the sequence must not appear >>>>> in the XML document (except outside of comments). >>>>> >>>>> [now the chair hat on]: >>>>> >>>>> Please keep in mind that we don't have the mandate >>>>> for v2.0. We are just doing bug-fixing. >>>>> >>>>> I agree with you that v2.0 should solve this issue >>>>> with a thorough solution. Would you like to prepare >>>>> a few slides for the NETCONF session in Beijing for >>>>> a solution, which could be put later into v2.0? >>>>> >>>>> Cheers, >>>>> Mehmet >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] >>>>>> Sent: Wednesday, October 20, 2010 7:23 PM >>>>>> To: Ersue, Mehmet (NSN - DE/Munich) >>>>>> Cc: Netconf; ext Margaret Wasserman >>>>>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC >>>>>> RFC4741bis >>>>>> >>>>>> On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) >>>>>> wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> same is with 4742bis WGLC discusion. We had only minor >>>>>>> changes after IETF 78. Our impression is that we have >>>>>>> consensus to see the draft as final. >>>>>>> >>>>>>> Margaret submitted the draft today making it ready for >>>>>>> AD review. Please check the changes by 10/22 so that >>>>>>> we have a chance to re-submit before deadline. Thanks. >>>>>> The justification for the EOM marker in sec. 3.1 is technically >>>>>> incorrect - and I objected against it previously: >>>>>> http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html >>>>>> >>>>>> Here is the change I propose (there's also a typo in >>>> "unambiguously"): >>>>>> OLD >>>>>> >>>>>> This character sequence cannot legally appear outside of a comment >>>> in >>>>>> an >>>>>> XML document, so it can be unambigiously used to identify the end >>>> of >>>>>> the >>>>>> current document, allowing resynchronization of the NETCONF >>>> exchange in >>>>>> the event of an XML syntax or parsing error. >>>>>> >>>>>> NEW >>>>>> >>>>>> This character sequence cannot legally appear outside of a comment, >>>>>> processing instruction and attribute value in an XML document, so >>>> it >>>>>> can >>>>>> be unambiguously used to identify the end of the current document, >>>>>> allowing resynchronization of the NETCONF exchange in the event of >>>> an >>>>>> XML syntax or parsing error. >>>>>> >>>>>> Lada >>>>>> >>>>>>> Cheers, >>>>>>> Mehmet >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] >>>> On >>>>>>> Behalf Of ext Bert Wijnen (IETF) >>>>>>> Sent: Wednesday, October 20, 2010 3:52 PM >>>>>>> To: Netconf >>>>>>> Subject: [Netconf] status WGLC RFC4741bis >>>>>>> >>>>>>> It seems that the WGLC discussion has now died out on the mailing >>>>>> list. >>>>>>> From re-reading all those comments, I also get the impression >>>> that >>>>>>> there is consensus/agreement on the changes that need to be >>>>>> addressed. >>>>>>> The editors (specifically Martin) is preparing a new revision >>>> based >>>>>>> on the result of the discussions. Will probably show up later >>>> today. >>>>>>> Our plan as WG-chairs is to allow the WG a few days to quickly >>>> check >>>>>>> if the changes are OK. Then ask our Ad to bring it forward to >>>> IETF >>>>>>> Last Call and IESG review. >>>>>>> >>>>>>> Thanks, >>>>>>> Bert and Mehmet >>>>>>> _______________________________________________ >>>>>>> Netconf mailing list >>>>>>> Netconf@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>>>> e-mail message attachment >>>>>>>> -------- Forwarded Message -------- >>>>>>>> From: Internet-Drafts@ietf.org >>>>>>>> Reply-to: >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: netconf@ietf.org >>>>>>>> Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt >>>>>>>> Date: Wed, 20 Oct 2010 17:00:02 +0200 >>>>>>>> >>>>>>>> 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-03.txt >>>>>>>> Pages : 10 >>>>>>>> Date : 2010-10-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- >>>>>> 03.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 >>>>>> -- >>>>>> Ladislav Lhotka, CESNET >>>>>> PGP Key ID: E74E8C0C >>>> -- >>>> Ladislav Lhotka, CESNET >>>> PGP Key ID: E74E8C0C >>> _______________________________________________ >>> 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 Fri Oct 22 05:33:30 2010 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 B72C23A686A for ; Fri, 22 Oct 2010 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 slx02Lyim0Xu for ; Fri, 22 Oct 2010 05:33:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8A6103A68E2 for ; Fri, 22 Oct 2010 05:33:27 -0700 (PDT) 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 o9MCYu12024338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 14:34:56 +0200 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 o9MCYtJ4009427; Fri, 22 Oct 2010 14:34:55 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 14:34:56 +0200 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: Fri, 22 Oct 2010 14:34:54 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E57E3@DEMUEXC006.nsn-intra.net> In-Reply-To: <4CC1736D.4010903@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: Actx2yACTBkBdz6LRWO7Q+qRZOxLvwABz7OA References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert (IETF) Wijnen" , "Andy Bierman" X-OriginalArrivalTime: 22 Oct 2010 12:34:56.0149 (UTC) FILETIME=[887C5450:01CB71E5] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 12:33:31 -0000 SGkgQWxsLA0KDQpNYXJ0aW4gd3JvdGU6DQo+IEFuZCByZW1vdmUgdGhpcyB0ZXh0IGZyb20gNDc0 MmJpczoNCj4gICBUaGlzDQo+ICAgIGNoYXJhY3RlciBzZXF1ZW5jZSBjYW5ub3QgbGVnYWxseSBh cHBlYXIgb3V0c2lkZSBvZiBhIGNvbW1lbnQgaW4gYW4NCj4gICAgWE1MIGRvY3VtZW50LCBzbyBp dCBjYW4gYmUgdW5hbWJpZ2lvdXNseSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBlbmQgb2YNCj4gICAg dGhlIGN1cnJlbnQgZG9jdW1lbnQsIGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBO RVRDT05GDQo+ICAgIGV4Y2hhbmdlIGluIHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBh cnNpbmcgZXJyb3IuDQoNCkkgYWdyZWUgd2l0aCBMYWRhIGFuZCBNYXJ0aW4gdGhhdCB0aGlzIHNl bnRlbmNlIGNhdXNlZCBtb3JlIHRyb3VibGUgDQp0aGFuIGl0IGhlbHBlZC4gDQoNClRvIGF2b2lk IGFueSBraW5kIG9mIG1pc3VuZGVyc3RhbmRpbmcgZm9yIHRoZSBpbXBsZW1lbnRlciBvZiA0NzQy YmlzIA0KSSB3b3VsZCB3cml0ZSBpbnN0ZWFkIG9mIHRoZSB0ZXh0IGFib3ZlOg0KDQpORVc6DQoi VGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2UgTVVTVCBOT1QgYXBwZWFyIGluIGFuIFhNTCBkb2N1bWVu dC4iDQoNCkdvb2Qgb3IgYmFkLCB0aGlzIGlzIGhvdyBTU0ggdHJhbnNwb3J0IHdvcmtzIGluIHYx LjAuDQoNCg0KTGFkYSB3cm90ZToNCj4gSG93IGFib3V0IHRlbGxpbmcgdGhlIHdob2xlIHRydXRo LCBpLmUuDQo+IA0KPiAxLiBPcmlnaW5hbGx5IGl0IHdhcyBiZWxpZXZlZCB0aGUgRU9NIHNlcXVl bmNlIGNhbm5vdCBhcHBlYXIgaW4gYW55IFhNTCBkb2N1bWVudC4NCj4gMi4gVGhpcyBhc3N1bXB0 aW9uIHR1cm5lZCBvdXQgdG8gYmUgd3JvbmcgYnV0IG5vdyB0aGlzIG1pc3Rha2UgY2Fubm90IGJl DQo+IG1pdGlnYXRlZCBpbiBhIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdheS4NCj4gMy4gQXMgYSBy ZXN1bHQsIHRoZSBTU0ggdHJhbnNwb3J0IGlzIG5vdCAxMDAlIHJlbGlhYmxlIGFuZCBzYWZlIGFu ZCBtYXkNCj4gbGVhZCB0byBvcGVyYXRpb25hbCBwcm9ibGVtcyBhbmQgb3BlbiBzcGFjZSBmb3Ig YXR0YWNrcy4gSXQgaXMgaG93ZXZlcg0KPiBiZWxpZXZlZCB0aGF0IHRoZSBhc3NvY2lhdGVkIHRo cmVhdCBpcyBub3QgdmVyeSBoaWdoLiBPbiB0aGUgb3RoZXIgaGFuZCwNCj4gbWFraW5nIGluY29t cGF0aWJsZSBjaGFuZ2VzIHdvdWxkIGJyZWFrIGV4aXN0aW5nIGNsaWVudHMuDQo+IDQuIE5FVENP TkYgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZSBTU0ggdHJhbnNwb3J0IG11c3QgZXhlcmNpc2Ug ZXh0cmENCj4gY2FyZSBhbmQgbWFrZSBzdXJlIHRoZSBFT00gc2VxdWVuY2UgaXMgbm90IHByZXNl bnQgaW4gTkVUQ09ORiBtZXNzYWdlcw0KPiBiZWZvcmUgcGFzc2luZyB0aGVtIHRvIHRoZSBUcmFu c3BvcnQgbGF5ZXIsIGV2ZW4gaWYgdGhleSB3ZXJlDQo+IHdlbGwtZm9ybWVkIFhNTC4NCg0KU29t ZSBvZiB0aGlzIHNob3VsZCBiZSB3cml0dGVuIGludG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHNlY3Rpb24uDQpFLmcuDQoNCk5FVzoNCiJSRkMgNDc0MiBhc3N1bWVzIHRoYXQgdGhlIEVP TSBzZXF1ZW5jZSBjYW5ub3QgYXBwZWFyIGluIGFueSBYTUwgZG9jdW1lbnQsDQp3aGljaCB0dXJu ZWQgb3V0IHRvIGJlIG1pc3Rha2VuLiBUaGUgRU9NIHNlcXVlbmNlIGNhbiBjYXVzZSBvcGVyYXRp b25hbCANCnByb2JsZW1zIGFuZCBvcGVuIHNwYWNlIGZvciBhdHRhY2tzIGlmIHNlbnQgZGVsaWJl cmF0ZWx5IGluIGFuIFhNTCBkb2N1bWVudC4NCkl0IGlzIGhvd2V2ZXIgYmVsaWV2ZWQgdGhhdCB0 aGUgYXNzb2NpYXRlZCB0aHJlYXQgaXMgbm90IHZlcnkgaGlnaC4gVGhpcyANCmRvY3VtZW50IGtl ZXBzIHVzaW5nIHRoZSBFT00gc2VxdWVuY2UgdG8gYXZvaWQgaW5jb21wYXRpYmlsaXR5IHdpdGgg ZXhpc3RpbmcgDQpjbGllbnRzLg0KTkVUQ09ORiBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlIFNT SCB0cmFuc3BvcnQgbXVzdCBleGVyY2lzZSBleHRyYSBjYXJlIA0KYW5kIG1ha2Ugc3VyZSB0aGUg RU9NIHNlcXVlbmNlIGlzIG5vdCBwcmVzZW50IGluIE5FVENPTkYgbWVzc2FnZXMgYmVmb3JlIA0K cGFzc2luZyB0aGVtIHRvIHRoZSBUcmFuc3BvcnQgbGF5ZXIsIGV2ZW4gaWYgdGhleSB3ZXJlIHdl bGwtZm9ybWVkIFhNTC4iDQoNCg0KV2l0aCB0aGlzICh0d28pIE5FVy10ZXh0IHByb3Bvc2Fscywg Y2FuIHdlIHNlZSBub3cgdGhlIGlzc3VlIGFzIGNsb3NlZCANCmZvciAodjEuMCkgNDc0MmJpcz8N Cg0KQW5kIHdlIGNhbiByZXZpc2l0IHRoaXMgaXNzdWUgd2hlbiB3ZSBkbyBORVRDT05GIHYyLjAu DQoNCkNoZWVycywNCk1laG1ldA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogZXh0IEJlcnQgKElFVEYpIFdpam5lbiBbbWFpbHRvOmJlcnRpZXRmQGJ3aWpuZW4ubmV0 XQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMTAgMToyMCBQTQ0KPiBUbzogQW5keSBC aWVybWFuDQo+IENjOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpOyBleHQgTGFkaXNs YXYgTGhvdGthOyBleHQgTWFyZ2FyZXQNCj4gV2Fzc2VybWFuOyBOZXRjb25mDQo+IFN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xD DQo+IFJGQzQ3NDFiaXMNCj4gDQo+IEFzIGEgdGVjaG5pY2FsIGNvbnRyaWJ1dG9yLg0KPiANCj4g TXkgdW5kZXJzdGFuZGluZyB3YXMgKGFuZCBzdGlsbCBpcyk6DQo+IA0KPiAtIGF0IHJmYzQ3NDEg dGltZSwgd2UgdGhvdWdodCB0aGF0IHRoZSBzZXF1ZW5jZSBjb3VsZCBOT1QgbGVnYWxseSBvY2N1 cg0KPiAgICAgaW4gYW4gWE1MIGRvY3VtZW50Lg0KPiAtIHNvIHdlIGRlY2lkZWQgdGhhdCB0aGUg c2VxdWVuY2Ugc2VydmVzIGFzIGFuIEVPTS4gV2hpY2ggSSB1bmRlcnN0YW5kDQo+IHRvIG1lYW4N Cj4gICAgIHRoYXQgdGhlIFNTSCBsYXllciBkb2VzIG5vdCAoYXQgbGVhc3QgZG9lcyBub3QgbmVl ZCB0bykgcGFyc2UgWE1MDQo+IGF0IGFsbC4gSXQganVzdA0KPiAgICAgc2VhcmNoZWQgaW4gdGhl IHN0cmVhbSBmb3IgdGhlIEVPTSBzZXF1ZW5jZSwgYW5kIHRoZW4gcGFzc2VzIHRoZQ0KPiBkYXRh IHVwDQo+ICAgICB0byB0aGF0IHBvaW50IHRvIHRoZSBuZXRjb25mIGxheWVyLg0KPiAtIHdlIGxl YXJuZWQgbGF0ZXIgdGhhdCB0aGUgc2VxdWVuY2UgbWF5IG9jY3VyIGluIGNvbW1lbnRzIGFuZCBk ZWNpZGVkDQo+IHRoYXQNCj4gICAgIHdlIGRvIG5vdCBjb25zaWRlciB0aGF0IGFzIGEgcHJvYmxl bSwgYW5zIGRvIHdlIGRvIChvciBzaG91bGQpDQo+IGFkdmlzZQ0KPiAgICAgdXNlcnMgdG8gTk9U IHVzZSB0aGUgRU9NIHNlcXVlbmNlIGluIFhNTCBjb21tZW50cw0KPiAtIHRoZW4geWV0IGxhdGVy IHdlIGxlYXJuZWQgdGhhdCBpdCBjYW4gb2NjdXIgaW4gUEkgYW5kIGF0dHJpYnV0ZQ0KPiB2YWx1 ZXMsIGJ1dCB3ZSBkZWNpZGVkDQo+ICAgICAob3IgY29uY2x1ZGVkIGJhc2VkIG9uIGV4cGVyaWVu Y2UpIHRoYXQgd2UgYXJlIG5vdCB1c2luZy9uZWVkaW5nIFBJDQo+IGluIE5FVENPTkYNCj4gICAg IG9yIE5FVENPTkYgY29udGVudCwgYW5kIHRoYXQgd2UgYWxzbyBkbyBub3QgbmVlZCBpdCBpbiBh dHRyaWJ1dGUNCj4gdmFsdWVzLg0KPiAgICAgU28sIHdlIGZpZ3VyZSBpdCBpcyBzdGlsbCBPSyB0 byB1c2UgdGhlIEVPTSBtYXJrZXIsIGF0IGxlYXN0IHVudGlsbA0KPiBzb21lb25lIHNob3dzIHVz DQo+ICAgICBhIGdvb2QgdXNlIGNhc2Ugd2hlcmUgb3VyIEVPTSBtYXJrZXIgaXMgbmVlZGVkIHdp dGggTkVUQ09ORi4NCj4gDQo+IFNvLCB3ZSB3YW50IGJlIGNvcnJlY3QvcHJlY2lzZS9ob25lc3Qg aW4gZXhhY3RseSBzcGVjaWZ5aW5nIGhvdyB0aGUNCj4gc2VxdWVuY2UgY2FuDQo+IHRoZW9yZXRp Y2FsbHkgYW5kIGxlZ2FsbHkgYXBwZWFyIGluIGFuIFhNTCBkb2N1bWVudC4NCj4gV2UgdGhlbiB3 YW50IHRvIHN0YXRlIHRoYXQgd2UgYmVsaWV2ZSwgYmFzZWQgb24gb3VyIGV4cGVyaWVuY2UsIHRo YXQNCj4gdGhhdCBzZXF1ZW5jZQ0KPiBpcyBpbiBwcmFjdGljZSBub3QgdXNlZC9uZWVkZWQgaW4g TkVUQ09ORiwgYW5kIHNvIHRoYXQgd2Ugc3RpbGwgYmVsaWV2ZQ0KPiBpdCBpcyBPSw0KPiB0byB1 c2UgdGhhdCBzZXF1ZW5jZSBhcyBFT00gbWFya2VyLCBubyBtYXR0ZXIgd2hlcmUgaW4gdGhlIHRy YW5zcG9ydA0KPiBzdHJlYW0gaXQNCj4gb2NjdXJzLg0KPiANCj4gV2UgY291bGQgYWRkIGEgcXVl c3Rpb24gdGhhdCBpZiBhbnlvbmUgZXZlciBzZWVzIGEgbmVlZCB0byB1c2UgdGhlDQo+IHNlcXVl bmNlIHRoYXQNCj4gdGhleSBiZXR0ZXIgaW5mb3JtIHVzIChuZXRjb25mIFdHKSBhc2FwIHdpdGgg YSBnb29kIGRlc2NyaXB0aW9uIG9mIHRoZQ0KPiBzY2VuYXJpby4NCj4gDQo+IEJlcnQNCj4gDQo+ IE9uIDEwLzIxLzEwIDg6NTEgUE0sIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPiBIaSwNCj4gPg0K PiA+IFRoZSBvcmlnaW5hbCBpbnRlbnQgd2FzIHRvIHVzZSBhIGNoYXIgc2VxdWVuY2UgdGhhdCB3 YXMgbm90IGxlZ2FsIGluDQo+ID4gYW4gWE1MIGluc3RhbmNlIGRvY3VtZW50LiAgTm9ib2R5IGlu IHRoZSBXRyBhdCB0aGUgdGltZSBrbmV3IGZvcg0KPiBzdXJlLA0KPiA+IHNvIHdlIGFza2VkIHRo ZSBYTUwgRGlyZWN0b3JhdGUuICBXZSB3b3JrZWQgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhhdA0K PiA+IHRoZSBdXT5dXT4gIHNlcXVlbmNlIHdhcyBhIHN1aXRhYmxlIG1lc3NhZ2UgYm91bmRhcnkg bWFya2VyLg0KPiA+DQo+ID4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgZXZpZGVuY2UgdGhhdCB0aGlz IEVPTSBzZXF1ZW5jZSBpcyBjYXVzaW5nDQo+IHByb2JsZW1zDQo+ID4gZm9yIG9wZXJhdG9ycyB1 c2luZyBORVRDT05GLiAgSXMgdGhpcyByZWFsbHkgYSBjb25jZXJuIHRvIG9wZXJhdG9ycz8NCj4g PiBXb3VsZCBhIHNpZ25pZmljYW50IHByb3RvY29sIGNoYW5nZSB0byBhZGRyZXNzIHRoaXMgaXNz dWUgY2F1c2UgbW9yZQ0KPiA+IG9wZXJhdGlvbmFsIHByb2JsZW1zIHRoYW4gaXQgc29sdmVzPw0K PiA+DQo+ID4gSSBkbyBub3QgYWdyZWUgdGhhdCB0aGlzIG11c3QgYmUgZml4ZWQgaW4gTkVUQ09O RiAyLjAsIHdoZW5ldmVyIHRoYXQNCj4gaXMuDQo+ID4gV2Ugc2hvdWxkIGRlY2lkZSBhdCB0aGUg dGltZSwgYWZ0ZXIgc29tZSBtb3JlIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4NCj4gPg0KPiA+DQo+ ID4gQW5keQ0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4gQmVoYWxmIE9mIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4g PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMSwgMjAxMCAxMToyMSBBTQ0KPiA+IFRvOiBleHQg TGFkaXNsYXYgTGhvdGthDQo+ID4gQ2M6IGV4dCBNYXJnYXJldCBXYXNzZXJtYW47IE5ldGNvbmYN Cj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZX OiBzdGF0dXMgV0dMQw0KPiBSRkM0NzQxYmlzDQo+ID4NCj4gPiBIaSBMYWRhLA0KPiA+DQo+ID4+ IEhpIE1laG1ldCwNCj4gPj4NCj4gPj4gT24gxIx0LCAyMDEwLTEwLTIxIGF0IDE4OjQ5ICswMjAw LCBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQo+ID4+IHdyb3RlOg0KPiA+Pj4gSGkg TGFkYSwNCj4gPj4+DQo+ID4+PiBbc3BlYWtpbmcgYXMgYSBjb250cmlidXRvcl0NCj4gPj4+DQo+ ID4+PiBpZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB5b3Ugd2FudCB0byBhbGxvdyB0aGUg RU9NDQo+ID4+PiBub3Qgb25seSBpbiBjb21tZW50cyBidXQgYWxzbyBpbiBYTUwgYXR0cmlidXRl cyBhbmQgUElzLg0KPiA+Pj4NCj4gPj4+IEluIGNhc2UgdGhlIGFuc3dlciBpcyBubzogSSBhcHBl YXIgdG8gbWlzdW5kZXJzdGFuZCB3aGF0DQo+ID4+PiB5b3Ugd2VyZSBzYXlpbmcuIFNvIHBscyBl eHBsYWluLg0KPiA+PiBJIGNlcnRhaW5seSBkb24ndCB3YW50IHRvIGFsbG93IGFueXRoaW5nIHRo YXQgaXNuJ3QgYWxyZWFkeSBhbGxvd2VkLg0KPiA6LQ0KPiA+PiApDQo+ID4+DQo+ID4+IFRoZSBj dXJyZW50IHRleHQgc2F5cywgYXMgSSB1bmRlcnN0YW5kIGl0LCB0aGF0IFhNTCBzcGVjaWZpY2F0 aW9uDQo+ID4+IGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8gYXBwZWFyIG91dHNpZGUg Y29tbWVudHMgaW4gYW4gWE1MDQo+ID4+IGRvY3VtZW50IChhbmQgdGhlcmVmb3JlIGl0IGlzIGEg Z29vZCBjaG9pY2UpLiBCdXQgdGhpcyBpcyBub3QgdHJ1ZToNCj4gWE1MDQo+ID4+IGRvY3VtZW50 cyBoYXZpbmcgdGhlIHNlcXVlbmNlIGluIFBJcyBhbmQgYXR0cmlidXRlIHZhbHVlcyBhcmUNCj4g Pj4gd2VsbC1mb3JtZWQgYXMgd2VsbC4gVGhlIG9ubHkgcGxhY2Ugd2hlcmUgdGhlIHNlcXVlbmNl IGlzIHJlYWxseQ0KPiA+PiBmb3JiaWRkZW4gaXMgZWxlbWVudCB0ZXh0Lg0KPiA+ICJUaGlzIGNo YXJhY3RlciBzZXF1ZW5jZSBjYW5ub3QgbGVnYWxseSBhcHBlYXIgaW4gYW4gWE1MIGRvY3VtZW50 LCBzbw0KPiA+IGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8gaW5kZW50aWZ5IHRoZSBl bmQgb2YgdGhlIGN1cnJlbnQNCj4gPiBkb2N1bWVudCBpbiB0aGUgZXZlbnQgb2YgYW4gWE1MIHN5 bnRheCBvciBwYXJzaW5nIGVycm9yLCBhbGxvd2luZw0KPiA+IHJlc3luY2hyb25pemF0aW9uIG9m IHRoZSBORVRDT05GIGV4Y2hhbmdlLiINCj4gPg0KPiA+IFRoZSBzZW50ZW5jZSBpcyBhY3R1YWxs eSBzaW5jZSBNYXkgMjAwNCAodjAxKSBpbiBTU0ggZG9jdW1lbnQNCj4gPiBhbmQgZGlkIG5vdCBj aGFuZ2UgdW50aWwgdG9kYXkuIEkgZG9uJ3Qga25vdyBleGFjdGx5IHdoYXQgdGhlDQo+ID4gYWlt IG9mIHRoZSBhdXRob3JzIHdhcyB0byB3cml0ZSBpdCB0aGF0IHdheS4NCj4gPg0KPiA+IE9uZSBv cHRpb24gaXMgdGhleSB3YW50ZWQgdG8gc3RhdGUgdGhhdCB0aGUgRU9NICIuLi4gTVVTVCBOT1QN Cj4gPiBhcHBlYXIgb3V0c2lkZSBvZiBhIGNvbW1lbnQgaW4gYW4gWE1MIGRvY3VtZW50Iiwgd2hp Y2ggd291bGQNCj4gPiBiZSBhIGNvbnNpc3RlbnQgcmVzdHJpY3Rpb24uDQo+ID4NCj4gPiBUaGUg b3RoZXIgb3B0aW9uIGlzIGhvdyB5b3UgdW5kZXJzdGFuZCBpdDoNCj4gPiAiWE1MIHNwZWNpZmlj YXRpb24gZG9lc24ndCBhbGxvdyB0aGUgRU9NIG1hcmtlciB0byBhcHBlYXINCj4gPiBvdXRzaWRl IGNvbW1lbnRzIg0KPiA+DQo+ID4gLi4ud2hpY2ggaXMgb2J2aW91c2x5IG5vdCBjb3JyZWN0IGFu ZCBjYW4gYmUgYWRkcmVzc2VkIGFzDQo+ID4geW91IHN1Z2dlc3QuIEJ1dCB0aGlzIHdvdWxkIG1l YW4gYWRkaXRpb25hbCBpbXBsZW1lbnRhdGlvbg0KPiA+IGVmZm9ydCBmb3IgU1NIIHRyYW5zcG9y dC4NCj4gPg0KPiA+IE1hcmdhcmV0LCBUZWQsIEFuZHk6DQo+ID4gQ2FuIHlvdSBwbGVhc2UgY2xh cmlmeSB3aGF0IHRoZSBvcmlnaW5hbCBhaW0gd2FzPw0KPiA+DQo+ID4gV2hhdCBkbyBvdGhlcnMg aW4gdGhlIFdHIHRoaW5rPw0KPiA+IFBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYmVmb3JlIEZy aWRheSBFT0IuDQo+ID4NCj4gPiBNZWhtZXQNCj4gPg0KPiA+PiBMYWRhDQo+ID4+DQo+ID4+PiBJ biBjYXNlIHRoZSBhbnN3ZXIgaXMgeWVzOg0KPiA+Pj4NCj4gPj4+IFRoZW9yZXRpY2FsbHkgdGhl IEVPTSBzZXF1ZW5jZSBjYW4gYXBwZWFyIGV2ZXJ5d2hlcmUgaW4NCj4gPj4+IGFuIFhNTCBkb2N1 bWVudC4NCj4gPj4+DQo+ID4+PiBIb3dldmVyLCB0aGUgdHJhbnNwb3J0IGxheWVyIHNob3VsZG4n dCBkbyBmaW5lIGdyYWluZWQNCj4gPj4+IHBhcnNpbmcgb2YgdGhlIFhNTCBkb2N1bWVudCwgdG8g ZmluZCBvdXQgd2hlcmUgdGhlDQo+ID4+PiBhdHRyaWJ1dGVzIG9yIFBJcyBhcmUuDQo+ID4+PiBU aGlzIGlzIHRoZSByZWFzb24gd2h5IDQ3NDIga2VwdCBpdCBzaW1wbGUgYW5kLCBhcyBJDQo+ID4+ PiB0aGluaywgYXBwcm9wcmlhdGUgZm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQo+ID4+Pg0KPiA+ Pj4gSSBkb24ndCBzZWUgYW55IGRpZmZlcmVuY2UgYmV0d2VlbiBYTUwgZWxlbWVudHMgYW5kDQo+ ID4+PiBbYXR0cmlidXRlcyBvciBQSV0uIFRoZXkgYWxsIGFyZSBYTUwgZGF0YS4gQW5kIEVPTSBj YW4NCj4gPj4+IGFwcGVhciBpbiBYTUwgZGF0YSBvciBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVu dC4NCj4gPj4+IElmIHNvbWVib2R5IHdhbnRzIHRvIGRpc3J1cHQgdGhlIHJwYyBjb21tYW5kIGhl IGNhbg0KPiA+Pj4gZG8gaXQgbm8gbWF0dGVyIGluIGVsZW1lbnRzIG9yIGF0dHJpYnV0ZXMuDQo+ ID4+Pg0KPiA+Pj4gU28sIGF0IHRoZSBlbmQgSSBkb24ndCBzZWUgYW55IGJlbmVmaXQgaW4gcmVk dWNpbmcgdGhlDQo+ID4+PiByZXN0cmljdGlvbiBhbmQgdGhpbms6DQo+ID4+PiBUbyBiZSBvbiB0 aGUgc2FmZSBzaWRlIGFuZCB0byBrZWVwIGl0IHNpbXBsZSBmb3IgdGhlDQo+ID4+PiBpbXBsZW1l bnRlciBvZiA0NzQyYmlzIHRoZSBzZXF1ZW5jZSBtdXN0IG5vdCBhcHBlYXINCj4gPj4+IGluIHRo ZSBYTUwgZG9jdW1lbnQgKGV4Y2VwdCBvdXRzaWRlIG9mIGNvbW1lbnRzKS4NCj4gPj4+DQo+ID4+ PiBbbm93IHRoZSBjaGFpciBoYXQgb25dOg0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBrZWVwIGluIG1p bmQgdGhhdCB3ZSBkb24ndCBoYXZlIHRoZSBtYW5kYXRlDQo+ID4+PiBmb3IgdjIuMC4gV2UgYXJl IGp1c3QgZG9pbmcgYnVnLWZpeGluZy4NCj4gPj4+DQo+ID4+PiBJIGFncmVlIHdpdGggeW91IHRo YXQgdjIuMCBzaG91bGQgc29sdmUgdGhpcyBpc3N1ZQ0KPiA+Pj4gd2l0aCBhIHRob3JvdWdoIHNv bHV0aW9uLiBXb3VsZCB5b3UgbGlrZSB0byBwcmVwYXJlDQo+ID4+PiBhIGZldyBzbGlkZXMgZm9y IHRoZSBORVRDT05GIHNlc3Npb24gaW4gQmVpamluZyBmb3INCj4gPj4+IGEgc29sdXRpb24sIHdo aWNoIGNvdWxkIGJlIHB1dCBsYXRlciBpbnRvIHYyLjA/DQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0K PiA+Pj4gTWVobWV0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+Pj4+IEZyb206IGV4dCBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAY2Vz bmV0LmN6XQ0KPiA+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMCwgMjAxMCA3OjIzIFBN DQo+ID4+Pj4gVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4gPj4+PiBDYzog TmV0Y29uZjsgZXh0IE1hcmdhcmV0IFdhc3Nlcm1hbg0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbTmV0 Y29uZl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDDQo+ID4+Pj4g UkZDNDc0MWJpcw0KPiA+Pj4+DQo+ID4+Pj4gT24gU3QsIDIwMTAtMTAtMjAgYXQgMTg6MjcgKzAy MDAsIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4gPj4+PiB3cm90ZToNCj4gPj4+ Pj4gSGkgQWxsLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBzYW1lIGlzIHdpdGggNDc0MmJpcyBXR0xDIGRp c2N1c2lvbi4gV2UgaGFkIG9ubHkgbWlub3INCj4gPj4+Pj4gY2hhbmdlcyBhZnRlciBJRVRGIDc4 LiBPdXIgaW1wcmVzc2lvbiBpcyB0aGF0IHdlIGhhdmUNCj4gPj4+Pj4gY29uc2Vuc3VzIHRvIHNl ZSB0aGUgZHJhZnQgYXMgZmluYWwuDQo+ID4+Pj4+DQo+ID4+Pj4+IE1hcmdhcmV0IHN1Ym1pdHRl ZCB0aGUgZHJhZnQgdG9kYXkgbWFraW5nIGl0IHJlYWR5IGZvcg0KPiA+Pj4+PiBBRCByZXZpZXcu IFBsZWFzZSBjaGVjayB0aGUgY2hhbmdlcyBieSAxMC8yMiBzbyB0aGF0DQo+ID4+Pj4+IHdlIGhh dmUgYSBjaGFuY2UgdG8gcmUtc3VibWl0IGJlZm9yZSBkZWFkbGluZS4gVGhhbmtzLg0KPiA+Pj4+ IFRoZSBqdXN0aWZpY2F0aW9uIGZvciB0aGUgRU9NIG1hcmtlciBpbiBzZWMuIDMuMSBpcyB0ZWNo bmljYWxseQ0KPiA+Pj4+IGluY29ycmVjdCAtIGFuZCBJIG9iamVjdGVkIGFnYWluc3QgaXQgcHJl dmlvdXNseToNCj4gPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0 Y29uZi9jdXJyZW50L21zZzA2Mjc3Lmh0bWwNCj4gPj4+Pg0KPiA+Pj4+IEhlcmUgaXMgdGhlIGNo YW5nZSBJIHByb3Bvc2UgKHRoZXJlJ3MgYWxzbyBhIHR5cG8gaW4NCj4gPj4gInVuYW1iaWd1b3Vz bHkiKToNCj4gPj4+PiBPTEQNCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgY2hhcmFjdGVyIHNlcXVlbmNl IGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGEgY29tbWVudA0KPiA+PiBpbg0KPiA+ Pj4+IGFuDQo+ID4+Pj4gWE1MIGRvY3VtZW50LCBzbyBpdCBjYW4gYmUgdW5hbWJpZ2lvdXNseSB1 c2VkIHRvIGlkZW50aWZ5IHRoZSBlbmQNCj4gPj4gb2YNCj4gPj4+PiB0aGUNCj4gPj4+PiBjdXJy ZW50IGRvY3VtZW50LCBhbGxvd2luZyByZXN5bmNocm9uaXphdGlvbiBvZiB0aGUgTkVUQ09ORg0K PiA+PiBleGNoYW5nZSBpbg0KPiA+Pj4+IHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBh cnNpbmcgZXJyb3IuDQo+ID4+Pj4NCj4gPj4+PiBORVcNCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgY2hh cmFjdGVyIHNlcXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBvdXRzaWRlIG9mIGENCj4gY29t bWVudCwNCj4gPj4+PiBwcm9jZXNzaW5nIGluc3RydWN0aW9uIGFuZCBhdHRyaWJ1dGUgdmFsdWUg aW4gYW4gWE1MIGRvY3VtZW50LCBzbw0KPiA+PiBpdA0KPiA+Pj4+IGNhbg0KPiA+Pj4+IGJlIHVu YW1iaWd1b3VzbHkgdXNlZCB0byBpZGVudGlmeSB0aGUgZW5kIG9mIHRoZSBjdXJyZW50IGRvY3Vt ZW50LA0KPiA+Pj4+IGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBORVRDT05GIGV4 Y2hhbmdlIGluIHRoZSBldmVudCBvZg0KPiA+PiBhbg0KPiA+Pj4+IFhNTCBzeW50YXggb3IgcGFy c2luZyBlcnJvci4NCj4gPj4+Pg0KPiA+Pj4+IExhZGENCj4gPj4+Pg0KPiA+Pj4+PiBDaGVlcnMs DQo+ID4+Pj4+IE1laG1ldA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+IE9uDQo+ID4+Pj4+IEJlaGFsZiBP ZiBleHQgQmVydCBXaWpuZW4gKElFVEYpDQo+ID4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2Jl ciAyMCwgMjAxMCAzOjUyIFBNDQo+ID4+Pj4+IFRvOiBOZXRjb25mDQo+ID4+Pj4+IFN1YmplY3Q6 IFtOZXRjb25mXSBzdGF0dXMgV0dMQyBSRkM0NzQxYmlzDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0IHNl ZW1zIHRoYXQgdGhlIFdHTEMgZGlzY3Vzc2lvbiBoYXMgbm93IGRpZWQgb3V0IG9uIHRoZSBtYWls aW5nDQo+ID4+Pj4gbGlzdC4NCj4gPj4+Pj4gIEZyb20gcmUtcmVhZGluZyBhbGwgdGhvc2UgY29t bWVudHMsIEkgYWxzbyBnZXQgdGhlIGltcHJlc3Npb24NCj4gPj4gdGhhdA0KPiA+Pj4+PiB0aGVy ZSBpcyBjb25zZW5zdXMvYWdyZWVtZW50IG9uIHRoZSBjaGFuZ2VzIHRoYXQgbmVlZCB0byBiZQ0K PiA+Pj4+IGFkZHJlc3NlZC4NCj4gPj4+Pj4gVGhlIGVkaXRvcnMgKHNwZWNpZmljYWxseSBNYXJ0 aW4pIGlzIHByZXBhcmluZyBhIG5ldyByZXZpc2lvbg0KPiA+PiBiYXNlZA0KPiA+Pj4+PiBvbiB0 aGUgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9ucy4gV2lsbCBwcm9iYWJseSBzaG93IHVwIGxhdGVy DQo+ID4+IHRvZGF5Lg0KPiA+Pj4+PiBPdXIgcGxhbiBhcyBXRy1jaGFpcnMgaXMgdG8gYWxsb3cg dGhlIFdHIGEgZmV3IGRheXMgdG8gcXVpY2tseQ0KPiA+PiBjaGVjaw0KPiA+Pj4+PiBpZiB0aGUg Y2hhbmdlcyBhcmUgT0suIFRoZW4gYXNrIG91ciBBZCB0byBicmluZyBpdCBmb3J3YXJkIHRvDQo+ ID4+IElFVEYNCj4gPj4+Pj4gTGFzdCBDYWxsIGFuZCBJRVNHIHJldmlldy4NCj4gPj4+Pj4NCj4g Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+PiBCZXJ0IGFuZCBNZWhtZXQNCj4gPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4gTmV0Y29uZiBt YWlsaW5nIGxpc3QNCj4gPj4+Pj4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4+Pj4gZS1tYWlsIG1lc3Nh Z2UgYXR0YWNobWVudA0KPiA+Pj4+Pj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0t LS0NCj4gPj4+Pj4+IEZyb206IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZw0KPiA+Pj4+Pj4gUmVw bHktdG86PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPj4+Pj4+IFRvOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcNCj4gPj4+Pj4+IENjOiBuZXRjb25mQGlldGYub3JnDQo+ID4+Pj4+PiBTdWJq ZWN0OiBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTAzLnR4dA0KPiA+ Pj4+Pj4gRGF0ZTogV2VkLCAyMCBPY3QgMjAxMCAxNzowMDowMiArMDIwMA0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LQ0KPiA+PiBEcmFmdHMNCj4gPj4+PiBkaXJlY3Rvcmllcy4NCj4gPj4+Pj4+IFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBXb3Jr aW5nDQo+ID4+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gCVRpdGxl ICAgICAgICAgICA6IFVzaW5nIHRoZSBORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wNCj4g Pj4gb3Zlcg0KPiA+Pj4+IFNlY3VyZSBTaGVsbCAoU1NIKQ0KPiA+Pj4+Pj4gCUF1dGhvcihzKSAg ICAgICA6IE0uIFdhc3Nlcm1hbiwgVC4gR29kZGFyZA0KPiA+Pj4+Pj4gCUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTAzLnR4dA0KPiA+Pj4+Pj4gCVBhZ2Vz ICAgICAgICAgICA6IDEwDQo+ID4+Pj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxMC0xMC0yMA0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBp bnZva2luZyBhbmQgcnVubmluZyB0aGUNCj4gPj4+PiBORVRDT05GDQo+ID4+Pj4+PiBwcm90b2Nv bCB3aXRoaW4gYSBTZWN1cmUgU2hlbGwgKFNTSCkgc2Vzc2lvbiBhcyBhbiBTU0gNCj4gPj4gc3Vi c3lzdGVtLg0KPiA+Pj4+Pj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+ID4+ Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNv bmYtDQo+ID4+IHJmYzQ3NDJiaXMtDQo+ID4+Pj4gMDMudHh0DQo+ID4+Pj4+PiBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4+Pj4+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEJl bG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbA0K PiA+PiByZWFkZXINCj4gPj4+Pj4+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0 cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YNCj4gPj4gdGhlDQo+ID4+Pj4+PiBJbnRlcm5ldC1E cmFmdC4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gTmV0Y29uZkBpZXRm Lm9yZw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCj4gPj4+PiAtLQ0KPiA+Pj4+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUDQo+ID4+Pj4gUEdQ IEtleSBJRDogRTc0RThDMEMNCj4gPj4gLS0NCj4gPj4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQN Cj4gPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0 Y29uZkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== From mehmet.ersue@nsn.com Fri Oct 22 05:39:57 2010 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 D38173A6916 for ; Fri, 22 Oct 2010 05:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 VENv7vXcBB+n for ; Fri, 22 Oct 2010 05:38:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 071003A68D6 for ; Fri, 22 Oct 2010 05:38:12 -0700 (PDT) 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 o9MCdcfn003989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 14:39:38 +0200 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 o9MCdbnk026576; Fri, 22 Oct 2010 14:39:38 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 14:39:37 +0200 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: Fri, 22 Oct 2010 14:39:35 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> In-Reply-To: <1287738821.10487.25.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: ActxyW4V50d48AS3Q++JdKok32ty1AAHCoNA References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> <1287738821.10487.25.camel@missotis> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ladislav Lhotka" , "Martin Bjorklund" X-OriginalArrivalTime: 22 Oct 2010 12:39:37.0678 (UTC) FILETIME=[304A3EE0:01CB71E6] Cc: margaretw42@gmail.com, biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 12:39:57 -0000 SGkgTGFkYSwNCg0KY2FuIHlvdSBwcm92aWRlIGEgZmV3IHNsaWRlcyBmb3IgdGhlIE5FVENPTkYg c2Vzc2lvbg0Kc3VtbWFyaXppbmcgdGhlIHNvbHV0aW9uIHByb3Bvc2FscyBmb3IgdGhlIEVPTSBp c3N1ZSANCmZvciB2Mi4wIHdlIGhhZCBzbyBmYXIgb24gdGhlIE1MPw0KDQpJIHRoaW5rIHdlIHNo b3VsZCBkaXNjdXNzIGl0IGluIEJlaWppbmcgYXMgbG9uZyBhcyBpdA0KaXMgd2FybS4NCg0KQ2hl ZXJzLA0KTWVobWV0DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBl eHQgTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQGNlc25ldC5jel0NCj4gU2VudDogRnJp ZGF5LCBPY3RvYmVyIDIyLCAyMDEwIDExOjE0IEFNDQo+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kDQo+ IENjOiBpZXRmQGFuZHliaWVybWFuLmNvbTsgYmllcm1hbmFAQnJvY2FkZS5jb207IEVyc3VlLCBN ZWhtZXQgKE5TTiAtDQo+IERFL011bmljaCk7IG1hcmdhcmV0dzQyQGdtYWlsLmNvbTsgbmV0Y29u ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJi aXMgV0FTOkZXOiBzdGF0dXMgV0dMQw0KPiBSRkM0NzQxYmlzDQo+IA0KPiBPbiDEjHQsIDIwMTAt MTAtMjEgYXQgMjI6MzUgKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gQW5keSBC aWVybWFuIDxpZXRmQGFuZHliaWVybWFuLmNvbT4gd3JvdGU6DQo+ID4gPiBTaW5jZSBpbnZhbGlk IFhNTCBzaG91bGQgYmUgZXh0cmVtZWx5IHJhcmUsIGFuZCBjZXJ0YWlubHkgbm90IGENCj4gdXNl LWNhc2UsDQo+ID4gPiBpdCBpcyBub3QgYSBiaWcgZGVhbCB0byBzaHV0ZG93biB0aGUgc2Vzc2lv biB3aGVuZXZlciBpbnZhbGlkIFhNTA0KPiBpcyByZWNlaXZlZCwNCj4gPiA+IHdoZXRoZXIgYXNz dW1lZCB0byBiZSBkdWUgdG8gZnJhbWluZyBvciBub3QuDQo+ID4NCj4gPiBTbyBoZXJlJ3MgYSBj b25jcmV0ZSBwcm9wb3NhbCwgYWxvbmcgdGhlc2UgbGluZXMuDQo+ID4NCj4gPiBBZGQgdGhlIHRl eHQgSSBwcm9wb3NlZCBlYXJsaWVyIHRvIDQ3NDFiaXM6DQo+ID4NCj4gPiAgICAgICAgICBBbGwg TkVUQ09ORiBtZXNzYWdlcyBNVVNUIGJlIHdlbGwtZm9ybWVkIFhNTCwgZW5jb2RlZCBpbg0KPiBV VEYtOC4gIElmDQo+ID4gICAgICAgICAgYSBwZWVyIHJlY2VpdmVzIGEgbWVzc2FnZSB0aGF0IGlz IG5vdCB3ZWxsLWZvcm1lZCBYTUwsIGl0DQo+IE1VU1QNCj4gPiAgICAgICAgICBjbG9zZSB0aGUg TkVUQ09ORiBzZXNzaW9uLg0KPiANCj4gSSB0aGluayBpdCBzaG91bGQgYWxzbyBzZW5kIGFuIGVy cm9yIG1lc3NhZ2UgYmVmb3JlIGNsb3NpbmcsIG90aGVyd2lzZQ0KPiBJDQo+IGFncmVlLg0KPiAN Cj4gPg0KPiA+IEFuZCByZW1vdmUgdGhpcyB0ZXh0IGZyb20gNDc0MmJpczoNCj4gPg0KPiA+ICAg IFRoaXMNCj4gPiAgICBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91 dHNpZGUgb2YgYSBjb21tZW50IGluDQo+IGFuDQo+ID4gICAgWE1MIGRvY3VtZW50LCBzbyBpdCBj YW4gYmUgdW5hbWJpZ2lvdXNseSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBlbmQNCj4gb2YNCj4gPiAg ICB0aGUgY3VycmVudCBkb2N1bWVudCwgYWxsb3dpbmcgcmVzeW5jaHJvbml6YXRpb24gb2YgdGhl IE5FVENPTkYNCj4gPiAgICBleGNoYW5nZSBpbiB0aGUgZXZlbnQgb2YgYW4gWE1MIHN5bnRheCBv ciBwYXJzaW5nIGVycm9yLg0KPiANCj4gQnV0IHRoaXMgbWVhbnMgc3dlZXBpbmcgdGhlIGlzc3Vl IHVuZGVyIHRoZSBjYXJwZXQuIEhvdyBhYm91dCB0ZWxsaW5nDQo+IHRoZSB3aG9sZSB0cnV0aCwg aS5lLg0KPiANCj4gMS4gT3JpZ2luYWxseSBpdCB3YXMgYmVsaWV2ZWQgdGhlIEVPTSBzZXF1ZW5j ZSBjYW5ub3QgYXBwZWFyIGluIGFueSBYTUwNCj4gZG9jdW1lbnQuDQo+IA0KPiAyLiBUaGlzIGFz c3VtcHRpb24gdHVybmVkIG91dCB0byBiZSB3cm9uZyBidXQgbm93IHRoaXMgbWlzdGFrZSBjYW5u b3QNCj4gYmUNCj4gbWl0aWdhdGVkIGluIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgd2F5Lg0KPiAN Cj4gMy4gQXMgYSByZXN1bHQsIHRoZSBTU0ggdHJhbnNwb3J0IGlzIG5vdCAxMDAlIHJlbGlhYmxl IGFuZCBzYWZlIGFuZCBtYXkNCj4gbGVhZCB0byBvcGVyYXRpb25hbCBwcm9ibGVtcyBhbmQgb3Bl biBzcGFjZSBmb3IgYXR0YWNrcy4gSXQgaXMgaG93ZXZlcg0KPiBiZWxpZXZlZCB0aGF0IHRoZSBh c3NvY2lhdGVkIHRocmVhdCBpcyBub3QgdmVyeSBoaWdoLiBPbiB0aGUgb3RoZXINCj4gaGFuZCwN Cj4gbWFraW5nIGluY29tcGF0aWJsZSBjaGFuZ2VzIHdvdWxkIGJyZWFrIGV4aXN0aW5nIGNsaWVu dHMuDQo+IA0KPiA0LiBORVRDT05GIGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGUgU1NIIHRyYW5z cG9ydCBtdXN0IGV4ZXJjaXNlIGV4dHJhDQo+IGNhcmUgYW5kIG1ha2Ugc3VyZSB0aGUgRU9NIHNl cXVlbmNlIGlzIG5vdCBwcmVzZW50IGluIE5FVENPTkYgbWVzc2FnZXMNCj4gYmVmb3JlIHBhc3Np bmcgdGhlbSB0byB0aGUgVHJhbnNwb3J0IGxheWVyLCBldmVuIGlmIHRoZXkgd2VyZQ0KPiB3ZWxs LWZvcm1lZCBYTUwuDQo+IA0KPiBMYWRhDQo+IA0KPiA+DQo+ID4NCj4gPiBBbmQgdGhlbiB3ZSBj YW4gcmV2aXNpdCB0aGlzIGlzc3VlIHdoZW4gd2UgZG8gTkVUQ09ORiAyLjAuDQo+ID4NCj4gPg0K PiA+DQo+ID4gL21hcnRpbg0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQNCj4g UEdQIEtleSBJRDogRTc0RThDMEMNCg0K From ietf@andybierman.com Fri Oct 22 06:37:03 2010 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 B69633A684A for ; Fri, 22 Oct 2010 06:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 EEb8zg9OrOur for ; Fri, 22 Oct 2010 06:37:02 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) by core3.amsl.com (Postfix) with SMTP id 844C43A679C for ; Fri, 22 Oct 2010 06:37:00 -0700 (PDT) Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2010 13:38:38 -0000 Received: from [98.138.89.175] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2010 13:38:38 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 22 Oct 2010 13:38:37 -0000 X-Yahoo-Newman-Id: 636623.65267.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 51606 invoked from network); 22 Oct 2010 13:38:37 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 22 Oct 2010 06:38:37 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: o1bt6X0VM1lbd1xw6Ukg07n0t9.XZ7381FZv9zeWzxqbjuE Ggn4X9orn3elvXi8m4ewpzp3v04Fm6JfjjnVDBjfbbbZ6.bnyKm.1fiPbvDI yySHLAjMNDP1vqg7qawiuF1ATj5Xyq_i.9HRind70vJxowZRmIuwuJqRrZvT 5UHeFRRji0Y2xlxUS.OF1W8FThkCpBJJ94J_ipmYE.fj.wsTT5KZAkThha_l SIOxryZQa9CtRK6vxpKOpLBSuZX8JVx8ayeRY_w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC193DA.6040607@andybierman.com> Date: Fri, 22 Oct 2010 06:38:34 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> <1287738821.10487.25.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: margaretw42@gmail.com, netconf@ietf.org Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 13:37:04 -0000 On 10/22/2010 05:39 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > > can you provide a few slides for the NETCONF session > summarizing the solution proposals for the EOM issue > for v2.0 we had so far on the ML? > > I think we should discuss it in Beijing as long as it > is warm. Why? There is no new information. We are not working on NETCONF 2.0 yet, so why revisit the issue over and over now? A client application could be compromised at any protocol layer, so no form of framing is safe. > Cheers, > Mehmet Andy > > >> -----Original Message----- >> From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] >> Sent: Friday, October 22, 2010 11:14 AM >> To: Martin Bjorklund >> Cc: ietf@andybierman.com; biermana@Brocade.com; Ersue, Mehmet (NSN - >> DE/Munich); margaretw42@gmail.com; netconf@ietf.org >> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC >> RFC4741bis >> >> On Čt, 2010-10-21 at 22:35 +0200, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Since invalid XML should be extremely rare, and certainly not a >> use-case, >>>> it is not a big deal to shutdown the session whenever invalid XML >> is received, >>>> whether assumed to be due to framing or not. >>> >>> So here's a concrete proposal, along these lines. >>> >>> Add the text I proposed earlier to 4741bis: >>> >>> 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 >>> close the NETCONF session. >> >> I think it should also send an error message before closing, otherwise >> I >> agree. >> >>> >>> And remove this text from 4742bis: >>> >>> This >>> character sequence cannot legally appear outside of a comment in >> an >>> XML document, so it can be unambigiously used to identify the end >> of >>> the current document, allowing resynchronization of the NETCONF >>> exchange in the event of an XML syntax or parsing error. >> >> But this means sweeping the issue under the carpet. How about telling >> the whole truth, i.e. >> >> 1. Originally it was believed the EOM sequence cannot appear in any XML >> document. >> >> 2. This assumption turned out to be wrong but now this mistake cannot >> be >> mitigated in a backwards compatible way. >> >> 3. As a result, the SSH transport is not 100% reliable and safe and may >> lead to operational problems and open space for attacks. It is however >> believed that the associated threat is not very high. On the other >> hand, >> making incompatible changes would break existing clients. >> >> 4. NETCONF implementations using the SSH transport must exercise extra >> care and make sure the EOM sequence is not present in NETCONF messages >> before passing them to the Transport layer, even if they were >> well-formed XML. >> >> Lada >> >>> >>> >>> And then we can revisit this issue when we do NETCONF 2.0. >>> >>> >>> >>> /martin >> >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C > From mehmet.ersue@nsn.com Fri Oct 22 06:53:36 2010 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 1306028B23E for ; Fri, 22 Oct 2010 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 FqjqV37ShF73 for ; Fri, 22 Oct 2010 06:53:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0C8B528C0DB for ; Fri, 22 Oct 2010 06:53:33 -0700 (PDT) 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 o9MDt8wV002824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 15:55:08 +0200 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 o9MDt8mw027789; Fri, 22 Oct 2010 15:55:08 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 15:55:08 +0200 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: Fri, 22 Oct 2010 15:55:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E589A@DEMUEXC006.nsn-intra.net> In-Reply-To: <4CC193DA.6040607@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: Actx7nEsqsBKR3CWR9eFdqUwbqkqEwAASNAQ References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> <1287738821.10487.25.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> <4CC193DA.6040607@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 22 Oct 2010 13:55:08.0430 (UTC) FILETIME=[BCD422E0:01CB71F0] Cc: margaretw42@gmail.com, netconf@ietf.org Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 13:53:36 -0000 VGhpcyBpcyBieSBubyBtZWFucyBwYXJ0IG9mIDQ3NDJiaXMgb3IgNDc0MWJpcyBkaXNjdXNzaW9u Lg0KQm90aCBvZiB3aGljaCBhcmUgZ29pbmcgaG9wZWZ1bGx5IHRvIEFEIHJldmlldyBvbiBNb25k YXkuDQoNCkkgcHJvcG9zZWQgdGhpcyBhcyBhbiBvcGVuIG1pa2UgZGlzY3Vzc2lvbi4gVGhvdWdo IHdpdGggYSANCmZldyBzbGlkZXMgdG8gc3RydWN0dXJlIGl0LiBMZXQncyBzZWUgd2hldGhlciB3 ZSBjYW4gcmVhY2ggDQphbnkgY29tbW9uIHZpZXcuDQoNCkNoZWVycywNCk1laG1ldA0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0IEFuZHkgQmllcm1hbiBbbWFp bHRvOmlldGZAYW5keWJpZXJtYW4uY29tXQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIw MTAgMzozOSBQTQ0KPiBUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiBDYzog ZXh0IExhZGlzbGF2IExob3RrYTsgTWFydGluIEJqb3JrbHVuZDsgbWFyZ2FyZXR3NDJAZ21haWwu Y29tOw0KPiBuZXRjb25mQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gU3RhdHVz IFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDDQo+IFJGQzQ3NDFiaXMNCj4gDQo+ IE9uIDEwLzIyLzIwMTAgMDU6MzkgQU0sIEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkg d3JvdGU6DQo+ID4gSGkgTGFkYSwNCj4gPg0KPiA+IGNhbiB5b3UgcHJvdmlkZSBhIGZldyBzbGlk ZXMgZm9yIHRoZSBORVRDT05GIHNlc3Npb24NCj4gPiBzdW1tYXJpemluZyB0aGUgc29sdXRpb24g cHJvcG9zYWxzIGZvciB0aGUgRU9NIGlzc3VlDQo+ID4gZm9yIHYyLjAgd2UgaGFkIHNvIGZhciBv biB0aGUgTUw/DQo+ID4NCj4gPiBJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIGl0IGluIEJlaWpp bmcgYXMgbG9uZyBhcyBpdA0KPiA+IGlzIHdhcm0uDQo+IA0KPiBXaHk/DQo+IFRoZXJlIGlzIG5v IG5ldyBpbmZvcm1hdGlvbi4NCj4gV2UgYXJlIG5vdCB3b3JraW5nIG9uIE5FVENPTkYgMi4wIHll dCwgc28gd2h5IHJldmlzaXQgdGhlIGlzc3VlIG92ZXINCj4gYW5kIG92ZXIgbm93Pw0KPiANCj4g QSBjbGllbnQgYXBwbGljYXRpb24gY291bGQgYmUgY29tcHJvbWlzZWQgYXQgYW55IHByb3RvY29s IGxheWVyLCBzbyBubw0KPiBmb3JtDQo+IG9mIGZyYW1pbmcgaXMgc2FmZS4NCj4gDQo+IA0KPiA+ IENoZWVycywNCj4gPiBNZWhtZXQNCj4gDQo+IEFuZHkNCj4gDQo+ID4NCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBleHQgTGFkaXNsYXYgTGhvdGthIFtt YWlsdG86bGhvdGthQGNlc25ldC5jel0NCj4gPj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDIyLCAy MDEwIDExOjE0IEFNDQo+ID4+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kDQo+ID4+IENjOiBpZXRmQGFu ZHliaWVybWFuLmNvbTsgYmllcm1hbmFAQnJvY2FkZS5jb207IEVyc3VlLCBNZWhtZXQgKE5TTiAt DQo+ID4+IERFL011bmljaCk7IG1hcmdhcmV0dzQyQGdtYWlsLmNvbTsgbmV0Y29uZkBpZXRmLm9y Zw0KPiA+PiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FT OkZXOiBzdGF0dXMgV0dMQw0KPiA+PiBSRkM0NzQxYmlzDQo+ID4+DQo+ID4+IE9uIMSMdCwgMjAx MC0xMC0yMSBhdCAyMjozNSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4+IEFu ZHkgQmllcm1hbjxpZXRmQGFuZHliaWVybWFuLmNvbT4gIHdyb3RlOg0KPiA+Pj4+IFNpbmNlIGlu dmFsaWQgWE1MIHNob3VsZCBiZSBleHRyZW1lbHkgcmFyZSwgYW5kIGNlcnRhaW5seSBub3QgYQ0K PiA+PiB1c2UtY2FzZSwNCj4gPj4+PiBpdCBpcyBub3QgYSBiaWcgZGVhbCB0byBzaHV0ZG93biB0 aGUgc2Vzc2lvbiB3aGVuZXZlciBpbnZhbGlkIFhNTA0KPiA+PiBpcyByZWNlaXZlZCwNCj4gPj4+ PiB3aGV0aGVyIGFzc3VtZWQgdG8gYmUgZHVlIHRvIGZyYW1pbmcgb3Igbm90Lg0KPiA+Pj4NCj4g Pj4+IFNvIGhlcmUncyBhIGNvbmNyZXRlIHByb3Bvc2FsLCBhbG9uZyB0aGVzZSBsaW5lcy4NCj4g Pj4+DQo+ID4+PiBBZGQgdGhlIHRleHQgSSBwcm9wb3NlZCBlYXJsaWVyIHRvIDQ3NDFiaXM6DQo+ ID4+Pg0KPiA+Pj4gICAgICAgICAgIEFsbCBORVRDT05GIG1lc3NhZ2VzIE1VU1QgYmUgd2VsbC1m b3JtZWQgWE1MLCBlbmNvZGVkIGluDQo+ID4+IFVURi04LiAgSWYNCj4gPj4+ICAgICAgICAgICBh IHBlZXIgcmVjZWl2ZXMgYSBtZXNzYWdlIHRoYXQgaXMgbm90IHdlbGwtZm9ybWVkIFhNTCwgaXQN Cj4gPj4gTVVTVA0KPiA+Pj4gICAgICAgICAgIGNsb3NlIHRoZSBORVRDT05GIHNlc3Npb24uDQo+ ID4+DQo+ID4+IEkgdGhpbmsgaXQgc2hvdWxkIGFsc28gc2VuZCBhbiBlcnJvciBtZXNzYWdlIGJl Zm9yZSBjbG9zaW5nLA0KPiBvdGhlcndpc2UNCj4gPj4gSQ0KPiA+PiBhZ3JlZS4NCj4gPj4NCj4g Pj4+DQo+ID4+PiBBbmQgcmVtb3ZlIHRoaXMgdGV4dCBmcm9tIDQ3NDJiaXM6DQo+ID4+Pg0KPiA+ Pj4gICAgIFRoaXMNCj4gPj4+ICAgICBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkg YXBwZWFyIG91dHNpZGUgb2YgYSBjb21tZW50DQo+IGluDQo+ID4+IGFuDQo+ID4+PiAgICAgWE1M IGRvY3VtZW50LCBzbyBpdCBjYW4gYmUgdW5hbWJpZ2lvdXNseSB1c2VkIHRvIGlkZW50aWZ5IHRo ZQ0KPiBlbmQNCj4gPj4gb2YNCj4gPj4+ICAgICB0aGUgY3VycmVudCBkb2N1bWVudCwgYWxsb3dp bmcgcmVzeW5jaHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYNCj4gPj4+ICAgICBleGNoYW5nZSBp biB0aGUgZXZlbnQgb2YgYW4gWE1MIHN5bnRheCBvciBwYXJzaW5nIGVycm9yLg0KPiA+Pg0KPiA+ PiBCdXQgdGhpcyBtZWFucyBzd2VlcGluZyB0aGUgaXNzdWUgdW5kZXIgdGhlIGNhcnBldC4gSG93 IGFib3V0DQo+IHRlbGxpbmcNCj4gPj4gdGhlIHdob2xlIHRydXRoLCBpLmUuDQo+ID4+DQo+ID4+ IDEuIE9yaWdpbmFsbHkgaXQgd2FzIGJlbGlldmVkIHRoZSBFT00gc2VxdWVuY2UgY2Fubm90IGFw cGVhciBpbiBhbnkNCj4gWE1MDQo+ID4+IGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiAyLiBUaGlzIGFz c3VtcHRpb24gdHVybmVkIG91dCB0byBiZSB3cm9uZyBidXQgbm93IHRoaXMgbWlzdGFrZQ0KPiBj YW5ub3QNCj4gPj4gYmUNCj4gPj4gbWl0aWdhdGVkIGluIGEgYmFja3dhcmRzIGNvbXBhdGlibGUg d2F5Lg0KPiA+Pg0KPiA+PiAzLiBBcyBhIHJlc3VsdCwgdGhlIFNTSCB0cmFuc3BvcnQgaXMgbm90 IDEwMCUgcmVsaWFibGUgYW5kIHNhZmUgYW5kDQo+IG1heQ0KPiA+PiBsZWFkIHRvIG9wZXJhdGlv bmFsIHByb2JsZW1zIGFuZCBvcGVuIHNwYWNlIGZvciBhdHRhY2tzLiBJdCBpcw0KPiBob3dldmVy DQo+ID4+IGJlbGlldmVkIHRoYXQgdGhlIGFzc29jaWF0ZWQgdGhyZWF0IGlzIG5vdCB2ZXJ5IGhp Z2guIE9uIHRoZSBvdGhlcg0KPiA+PiBoYW5kLA0KPiA+PiBtYWtpbmcgaW5jb21wYXRpYmxlIGNo YW5nZXMgd291bGQgYnJlYWsgZXhpc3RpbmcgY2xpZW50cy4NCj4gPj4NCj4gPj4gNC4gTkVUQ09O RiBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlIFNTSCB0cmFuc3BvcnQgbXVzdCBleGVyY2lzZQ0K PiBleHRyYQ0KPiA+PiBjYXJlIGFuZCBtYWtlIHN1cmUgdGhlIEVPTSBzZXF1ZW5jZSBpcyBub3Qg cHJlc2VudCBpbiBORVRDT05GDQo+IG1lc3NhZ2VzDQo+ID4+IGJlZm9yZSBwYXNzaW5nIHRoZW0g dG8gdGhlIFRyYW5zcG9ydCBsYXllciwgZXZlbiBpZiB0aGV5IHdlcmUNCj4gPj4gd2VsbC1mb3Jt ZWQgWE1MLg0KPiA+Pg0KPiA+PiBMYWRhDQo+ID4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFuZCB0 aGVuIHdlIGNhbiByZXZpc2l0IHRoaXMgaXNzdWUgd2hlbiB3ZSBkbyBORVRDT05GIDIuMC4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC9tYXJ0aW4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gTGFk aXNsYXYgTGhvdGthLCBDRVNORVQNCj4gPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPg0KDQo= From j.schoenwaelder@jacobs-university.de Fri Oct 22 07:35:57 2010 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 5033628C0E8 for ; Fri, 22 Oct 2010 07:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rccKIrX81-XZ for ; Fri, 22 Oct 2010 07:35:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A4AE128C0F7 for ; Fri, 22 Oct 2010 07:35:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3AFCC000F; Fri, 22 Oct 2010 16:37:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5l+6XjX9JoPb; Fri, 22 Oct 2010 16:37:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE2A2C0009; Fri, 22 Oct 2010 16:37:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C249156E0D7; Fri, 22 Oct 2010 16:36:48 +0200 (CEST) Date: Fri, 22 Oct 2010 16:36:48 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101022143647.GB30247@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Bert (IETF) Wijnen" , Andy Bierman , ext Margaret Wasserman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64011E57E3@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E57E3@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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: Fri, 22 Oct 2010 14:35:57 -0000 On Fri, Oct 22, 2010 at 02:34:54PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > Martin wrote: > > And remove this text from 4742bis: > > This > > character sequence cannot legally appear outside of a comment in an > > XML document, so it can be unambigiously used to identify the end of > > the current document, allowing resynchronization of the NETCONF > > exchange in the event of an XML syntax or parsing error. > > I agree with Lada and Martin that this sentence caused more trouble > than it helped. > > To avoid any kind of misunderstanding for the implementer of 4742bis > I would write instead of the text above: > > NEW: > "This character sequence MUST NOT appear in an XML document." Works for me. > Good or bad, this is how SSH transport works in v1.0. > > > Lada wrote: > > How about telling the whole truth, i.e. > > > > 1. Originally it was believed the EOM sequence cannot appear in any XML document. > > 2. This assumption turned out to be wrong but now this mistake cannot be > > mitigated in a backwards compatible way. > > 3. As a result, the SSH transport is not 100% reliable and safe and may > > lead to operational problems and open space for attacks. It is however > > believed that the associated threat is not very high. On the other hand, > > making incompatible changes would break existing clients. > > 4. NETCONF implementations using the SSH transport must exercise extra > > care and make sure the EOM sequence is not present in NETCONF messages > > before passing them to the Transport layer, even if they were > > well-formed XML. > > Some of this should be written into the security considerations section. > E.g. > > NEW: > "RFC 4742 assumes that the EOM sequence cannot appear in any XML document, > which turned out to be mistaken. The EOM sequence can cause operational > problems and open space for attacks if sent deliberately in an XML document. > It is however believed that the associated threat is not very high. This > document keeps using the EOM sequence to avoid incompatibility with existing > clients. > NETCONF implementations using the SSH transport must exercise extra care > and make sure the EOM sequence is not present in NETCONF messages before > passing them to the Transport layer, even if they were well-formed XML." So where does this go, into 4741bis or 4742bis? The last sentence more sounds like 4741bis since it says something about what the NETCONF message layer has to do. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Oct 22 08:04:21 2010 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 CFED13A682F for ; Fri, 22 Oct 2010 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 b9b1RATHUXjm for ; Fri, 22 Oct 2010 08:04:20 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 70A5D3A6830 for ; Fri, 22 Oct 2010 08:04:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTMGoT9CcJLnZ2rjzqhixpILNi8WBIaoA@postini.com; Fri, 22 Oct 2010 08:05:59 PDT 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, 22 Oct 2010 08:02:20 -0700 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 o9MF2JU79133; Fri, 22 Oct 2010 08:02:19 -0700 (PDT) (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 o9MEfMAH050726; Fri, 22 Oct 2010 14:41:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010221441.o9MEfMAH050726@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20101022143647.GB30247@elstar.local> Date: Fri, 22 Oct 2010 10:41:22 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Andy Bierman , ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 15:04:21 -0000 Juergen Schoenwaelder writes: >> NEW: >> "This character sequence MUST NOT appear in an XML document." >Works for me. This is a change to the NETCONF protocol, since it makes a previously legal character sequence illegal. If we're willing to change NETCONF, why not just repair the SSH transport mapping, where the problem really exists. But if the WG really is following the "it's not a bug" line, then I suggest: (a) The draft should include an explanation of why this is illegal, with the history, etc. (b) The draft should include a description of the means to avoid this sequence (amper escaping) and a list of places where that escaping is not possible (processing instructions). That is, the draft should give all the details as we know them so an implementor can understand and properly address the issues. Me, I think it's a bug. A minor one, sure, but at least on par with the other issues addressed with netconf-1.1. Thanks, Phil From mehmet.ersue@nsn.com Fri Oct 22 09:18:49 2010 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 B61A53A6897 for ; Fri, 22 Oct 2010 09:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 aJkepS8Cm8Hq for ; Fri, 22 Oct 2010 09:18:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id A08233A67B1 for ; Fri, 22 Oct 2010 09:18:48 -0700 (PDT) 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 o9MGKLvc008590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 18:20:21 +0200 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 o9MGKKXD017968; Fri, 22 Oct 2010 18:20:20 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 18:20:20 +0200 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, 22 Oct 2010 18:20:18 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E5989@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101022143647.GB30247@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: Actx9ql52EYBuQ2XQmyERET6maTfNAAChJKQ References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64011E57E3@DEMUEXC006.nsn-intra.net> <20101022143647.GB30247@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 22 Oct 2010 16:20:20.0537 (UTC) FILETIME=[05A62A90:01CB7205] Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:18:49 -0000 >> NEW: >> "RFC 4742 assumes that the EOM sequence cannot appear in any XML document, >> which turned out to be mistaken. The EOM sequence can cause operational >> problems and open space for attacks if sent deliberately in an XML document. >> It is however believed that the associated threat is not very high. This >> document keeps using the EOM sequence to avoid incompatibility with >> existing clients. >> NETCONF implementations using the SSH transport must exercise extra care >> and make sure the EOM sequence is not present in NETCONF messages before >> passing them to the Transport layer, even if they were well-formed XML." >=20 > So where does this go, into 4741bis or 4742bis? The last sentence more > sounds like 4741bis since it says something about what the NETCONF > message layer has to do. Agree it should rather be: NEW (in security consideration section of 4742bis): "RFC 4742 assumes that the EOM sequence cannot appear in any XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in an XML document. It is however believed that the associated threat is not very high. This document keeps using the EOM sequence to avoid incompatibility with existing clients. Implementations of SSH transport should exercise extra care and make sure=20 the EOM sequence is not present in an XML document." Mehmet From mehmet.ersue@nsn.com Fri Oct 22 09:19:58 2010 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 E32D33A68A8 for ; Fri, 22 Oct 2010 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 SxBjtt+pRMgW for ; Fri, 22 Oct 2010 09:19:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id AE7AA3A67B1 for ; Fri, 22 Oct 2010 09:19:57 -0700 (PDT) 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 o9MGLWs6023290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 18:21:32 +0200 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 o9MGLVbg023570; Fri, 22 Oct 2010 18:21:32 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 18:21:22 +0200 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, 22 Oct 2010 18:21:21 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E598B@DEMUEXC006.nsn-intra.net> In-Reply-To: <201010221441.o9MEfMAH050726@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: Actx+qOm432YTcpRRgmDp72IdpYkNwABsOfw References: <20101022143647.GB30247@elstar.local> <201010221441.o9MEfMAH050726@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 22 Oct 2010 16:21:22.0970 (UTC) FILETIME=[2ADCAFA0:01CB7205] Cc: Andy Bierman , ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:19:59 -0000 Hi Phil, All, ::>> NEW: ::>> "This character sequence MUST NOT appear in an XML document." > >Works for me. >=20 > This is a change to the NETCONF protocol, since it makes a previously > legal character sequence illegal. If we're willing to change > NETCONF, why not just repair the SSH transport mapping, where the > problem really exists. >=20 > But if the WG really is following the "it's not a bug" line, then > I suggest: >=20 > (a) The draft should include an explanation of why this is illegal, > with the history, etc. >=20 > (b) The draft should include a description of the means to avoid > this sequence (amper escaping) and a list of places where that > escaping is not possible (processing instructions). >=20 > That is, the draft should give all the details as we know them so > an implementor can understand and properly address the issues. >=20 > Me, I think it's a bug. A minor one, sure, but at least on par with > the other issues addressed with netconf-1.1. Yes, it is a bug. We found out it can only be addressed "thoroughly"=20 in v2.0. We are now trying to fix the mistaken text in v1.0 of 4742bis. SSH v1.0 is specified to recognize end of document with this character=20 sequence. As we all were thinking, the character sequence cannot appear=20 in an XML document, I don't think it is a change for the NETCONF protocol (this BTW was the case since May 2004, see v01 of SSH draft which leaded to 4742). If you think "MUST NOT" is too strict I can go also with "SHOULD NOT". OTOH, if we know already it is bad, why not "MUST"? The explanation text you are proposing should go into the security=20 considerations section of 4742bis, e.g.: NEW: :: "RFC 4742 assumes that the EOM sequence cannot appear in any XML document, :: which turned out to be mistaken. The EOM sequence can cause operational :: problems and open space for attacks if sent deliberately in an XML document. :: It is however believed that the associated threat is not very high. This :: document keeps using the EOM sequence to avoid incompatibility with :: existing clients. :: Implementations of SSH transport must exercise extra care and make sure=20 :: the EOM sequence is not present in an XML document." All: : Knowing that this is only a (limited) bug fixing for v1.0, can we go=20 : with the proposed two NEW text blocks in 4742bis? We need a decision kind of soon to resubmit before deadline. Thank you. Mehmet From lhotka@cesnet.cz Fri Oct 22 09:20:07 2010 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 3BA453A691D for ; Fri, 22 Oct 2010 09:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 ik-ls-1ZXRw9 for ; Fri, 22 Oct 2010 09:20:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A8F3D3A690F for ; Fri, 22 Oct 2010 09:20:05 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id A242C2CDE058; Fri, 22 Oct 2010 18:21:42 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> References: <20101021194132.GD28010@elstar.local> <4CC0A101.1080308@andybierman.com> <20101021.223503.79570188.mbj@tail-f.com> <1287738821.10487.25.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E57ED@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 18:21:40 +0200 Message-ID: <1287764500.12363.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: margaretw42@gmail.com, biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:20:07 -0000 On Pá, 2010-10-22 at 14:39 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, > > can you provide a few slides for the NETCONF session > summarizing the solution proposals for the EOM issue > for v2.0 we had so far on the ML? OK, I will. Lada > > I think we should discuss it in Beijing as long as it > is warm. > > Cheers, > Mehmet > > > > -----Original Message----- > > From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > Sent: Friday, October 22, 2010 11:14 AM > > To: Martin Bjorklund > > Cc: ietf@andybierman.com; biermana@Brocade.com; Ersue, Mehmet (NSN - > > DE/Munich); margaretw42@gmail.com; netconf@ietf.org > > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > > RFC4741bis > > > > On Čt, 2010-10-21 at 22:35 +0200, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > Since invalid XML should be extremely rare, and certainly not a > > use-case, > > > > it is not a big deal to shutdown the session whenever invalid XML > > is received, > > > > whether assumed to be due to framing or not. > > > > > > So here's a concrete proposal, along these lines. > > > > > > Add the text I proposed earlier to 4741bis: > > > > > > 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 > > > close the NETCONF session. > > > > I think it should also send an error message before closing, otherwise > > I > > agree. > > > > > > > > And remove this text from 4742bis: > > > > > > This > > > character sequence cannot legally appear outside of a comment in > > an > > > XML document, so it can be unambigiously used to identify the end > > of > > > the current document, allowing resynchronization of the NETCONF > > > exchange in the event of an XML syntax or parsing error. > > > > But this means sweeping the issue under the carpet. How about telling > > the whole truth, i.e. > > > > 1. Originally it was believed the EOM sequence cannot appear in any XML > > document. > > > > 2. This assumption turned out to be wrong but now this mistake cannot > > be > > mitigated in a backwards compatible way. > > > > 3. As a result, the SSH transport is not 100% reliable and safe and may > > lead to operational problems and open space for attacks. It is however > > believed that the associated threat is not very high. On the other > > hand, > > making incompatible changes would break existing clients. > > > > 4. NETCONF implementations using the SSH transport must exercise extra > > care and make sure the EOM sequence is not present in NETCONF messages > > before passing them to the Transport layer, even if they were > > well-formed XML. > > > > Lada > > > > > > > > > > > And then we can revisit this issue when we do NETCONF 2.0. > > > > > > > > > > > > /martin > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Oct 22 09:28:00 2010 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 E78F23A6805 for ; Fri, 22 Oct 2010 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 HAMBnWKQjgYB for ; Fri, 22 Oct 2010 09:27:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 7437E3A68B2 for ; Fri, 22 Oct 2010 09:27:58 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id CC43D2CDE058; Fri, 22 Oct 2010 18:29:35 +0200 (CEST) From: Ladislav Lhotka To: "Bert (IETF) Wijnen" In-Reply-To: <4CC17FFB.8020406@bwijnen.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <1287747488.12363.35.camel@missotis> <4CC17FFB.8020406@bwijnen.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 18:29:34 +0200 Message-ID: <1287764974.12363.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:28:01 -0000 On Pá, 2010-10-22 at 14:13 +0200, Bert (IETF) Wijnen wrote: > On 10/22/10 1:38 PM, Ladislav Lhotka wrote: > > On Pá, 2010-10-22 at 13:20 +0200, Bert (IETF) Wijnen wrote: > >> As a technical contributor. > >> > >> My understanding was (and still is): > >> > >> - at rfc4741 time, we thought that the sequence could NOT legally occur > >> in an XML document. > >> - so we decided that the sequence serves as an EOM. Which I understand to mean > >> that the SSH layer does not (at least does not need to) parse XML at all. It just > >> searched in the stream for the EOM sequence, and then passes the data up > >> to that point to the netconf layer. > >> - we learned later that the sequence may occur in comments and decided that > >> we do not consider that as a problem, ans do we do (or should) advise > >> users to NOT use the EOM sequence in XML comments > >> - then yet later we learned that it can occur in PI and attribute values, but we decided > >> (or concluded based on experience) that we are not using/needing PI in NETCONF > >> or NETCONF content, and that we also do not need it in attribute values. > >> So, we figure it is still OK to use the EOM marker, at least untill someone shows us > >> a good use case where our EOM marker is needed with NETCONF. > > It may not be needed but it is available to attackers who may try to > > inject the marker in various places. This could be done indirectly, by > > exploiting other holes such as stack overflow in the client code. > > > > If this ever happens, all NETCONF implementations will have to be > > patched very quickly. I think it is better to fix it NOW than in such an > > emergency situation. > > > > Lada, that "fix it now" may be better in the view of some people, but > we were unable to reach agreement > on fixing it now. So that "better fix it now" is no longer open for discussion. OK, I just don't agree with the logic that as long there are no use cases for the EOM marker inside NETCONF messages the marker is good enough. The problem are misuse cases, not use cases. > > We're discussing how to best document the situation we have created. Yes, I understand and tried to work in that direction, too. I just couldn't resist here. :-) Lada > > Bert (now speaking as a WG chair) > > Lada > > > >> So, we want be correct/precise/honest in exactly specifying how the sequence can > >> theoretically and legally appear in an XML document. > >> We then want to state that we believe, based on our experience, that that sequence > >> is in practice not used/needed in NETCONF, and so that we still believe it is OK > >> to use that sequence as EOM marker, no matter where in the transport stream it > >> occurs. > >> > >> We could add a question that if anyone ever sees a need to use the sequence that > >> they better inform us (netconf WG) asap with a good description of the scenario. > >> > >> Bert > >> > >> On 10/21/10 8:51 PM, Andy Bierman wrote: > >>> Hi, > >>> > >>> The original intent was to use a char sequence that was not legal in > >>> an XML instance document. Nobody in the WG at the time knew for sure, > >>> so we asked the XML Directorate. We worked under the assumption that > >>> the ]]>]]> sequence was a suitable message boundary marker. > >>> > >>> I would like to hear evidence that this EOM sequence is causing problems > >>> for operators using NETCONF. Is this really a concern to operators? > >>> Would a significant protocol change to address this issue cause more > >>> operational problems than it solves? > >>> > >>> I do not agree that this must be fixed in NETCONF 2.0, whenever that is. > >>> We should decide at the time, after some more deployment experience. > >>> > >>> > >>> Andy > >>> > >>> > >>> -----Original Message----- > >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) > >>> Sent: Thursday, October 21, 2010 11:21 AM > >>> To: ext Ladislav Lhotka > >>> Cc: ext Margaret Wasserman; Netconf > >>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis > >>> > >>> Hi Lada, > >>> > >>>> Hi Mehmet, > >>>> > >>>> On Čt, 2010-10-21 at 18:49 +0200, Ersue, Mehmet (NSN - DE/Munich) > >>>> wrote: > >>>>> Hi Lada, > >>>>> > >>>>> [speaking as a contributor] > >>>>> > >>>>> if I understand you correctly you want to allow the EOM > >>>>> not only in comments but also in XML attributes and PIs. > >>>>> > >>>>> In case the answer is no: I appear to misunderstand what > >>>>> you were saying. So pls explain. > >>>> I certainly don't want to allow anything that isn't already allowed. :- > >>>> ) > >>>> > >>>> The current text says, as I understand it, that XML specification > >>>> doesn't allow the EOM marker to appear outside comments in an XML > >>>> document (and therefore it is a good choice). But this is not true: XML > >>>> documents having the sequence in PIs and attribute values are > >>>> well-formed as well. The only place where the sequence is really > >>>> forbidden is element text. > >>> "This character sequence cannot legally appear in an XML document, so > >>> it can be unambigiously used to indentify the end of the current > >>> document in the event of an XML syntax or parsing error, allowing > >>> resynchronization of the NETCONF exchange." > >>> > >>> The sentence is actually since May 2004 (v01) in SSH document > >>> and did not change until today. I don't know exactly what the > >>> aim of the authors was to write it that way. > >>> > >>> One option is they wanted to state that the EOM "... MUST NOT > >>> appear outside of a comment in an XML document", which would > >>> be a consistent restriction. > >>> > >>> The other option is how you understand it: > >>> "XML specification doesn't allow the EOM marker to appear > >>> outside comments" > >>> > >>> ...which is obviously not correct and can be addressed as > >>> you suggest. But this would mean additional implementation > >>> effort for SSH transport. > >>> > >>> Margaret, Ted, Andy: > >>> Can you please clarify what the original aim was? > >>> > >>> What do others in the WG think? > >>> Please state your opinion before Friday EOB. > >>> > >>> Mehmet > >>> > >>>> Lada > >>>> > >>>>> In case the answer is yes: > >>>>> > >>>>> Theoretically the EOM sequence can appear everywhere in > >>>>> an XML document. > >>>>> > >>>>> However, the transport layer shouldn't do fine grained > >>>>> parsing of the XML document, to find out where the > >>>>> attributes or PIs are. > >>>>> This is the reason why 4742 kept it simple and, as I > >>>>> think, appropriate for the transport layer. > >>>>> > >>>>> I don't see any difference between XML elements and > >>>>> [attributes or PI]. They all are XML data. And EOM can > >>>>> appear in XML data or at the end of the document. > >>>>> If somebody wants to disrupt the rpc command he can > >>>>> do it no matter in elements or attributes. > >>>>> > >>>>> So, at the end I don't see any benefit in reducing the > >>>>> restriction and think: > >>>>> To be on the safe side and to keep it simple for the > >>>>> implementer of 4742bis the sequence must not appear > >>>>> in the XML document (except outside of comments). > >>>>> > >>>>> [now the chair hat on]: > >>>>> > >>>>> Please keep in mind that we don't have the mandate > >>>>> for v2.0. We are just doing bug-fixing. > >>>>> > >>>>> I agree with you that v2.0 should solve this issue > >>>>> with a thorough solution. Would you like to prepare > >>>>> a few slides for the NETCONF session in Beijing for > >>>>> a solution, which could be put later into v2.0? > >>>>> > >>>>> Cheers, > >>>>> Mehmet > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ext Ladislav Lhotka [mailto:lhotka@cesnet.cz] > >>>>>> Sent: Wednesday, October 20, 2010 7:23 PM > >>>>>> To: Ersue, Mehmet (NSN - DE/Munich) > >>>>>> Cc: Netconf; ext Margaret Wasserman > >>>>>> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > >>>>>> RFC4741bis > >>>>>> > >>>>>> On St, 2010-10-20 at 18:27 +0200, Ersue, Mehmet (NSN - DE/Munich) > >>>>>> wrote: > >>>>>>> Hi All, > >>>>>>> > >>>>>>> same is with 4742bis WGLC discusion. We had only minor > >>>>>>> changes after IETF 78. Our impression is that we have > >>>>>>> consensus to see the draft as final. > >>>>>>> > >>>>>>> Margaret submitted the draft today making it ready for > >>>>>>> AD review. Please check the changes by 10/22 so that > >>>>>>> we have a chance to re-submit before deadline. Thanks. > >>>>>> The justification for the EOM marker in sec. 3.1 is technically > >>>>>> incorrect - and I objected against it previously: > >>>>>> http://www.ietf.org/mail-archive/web/netconf/current/msg06277.html > >>>>>> > >>>>>> Here is the change I propose (there's also a typo in > >>>> "unambiguously"): > >>>>>> OLD > >>>>>> > >>>>>> This character sequence cannot legally appear outside of a comment > >>>> in > >>>>>> an > >>>>>> XML document, so it can be unambigiously used to identify the end > >>>> of > >>>>>> the > >>>>>> current document, allowing resynchronization of the NETCONF > >>>> exchange in > >>>>>> the event of an XML syntax or parsing error. > >>>>>> > >>>>>> NEW > >>>>>> > >>>>>> This character sequence cannot legally appear outside of a comment, > >>>>>> processing instruction and attribute value in an XML document, so > >>>> it > >>>>>> can > >>>>>> be unambiguously used to identify the end of the current document, > >>>>>> allowing resynchronization of the NETCONF exchange in the event of > >>>> an > >>>>>> XML syntax or parsing error. > >>>>>> > >>>>>> Lada > >>>>>> > >>>>>>> Cheers, > >>>>>>> Mehmet > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > >>>> On > >>>>>>> Behalf Of ext Bert Wijnen (IETF) > >>>>>>> Sent: Wednesday, October 20, 2010 3:52 PM > >>>>>>> To: Netconf > >>>>>>> Subject: [Netconf] status WGLC RFC4741bis > >>>>>>> > >>>>>>> It seems that the WGLC discussion has now died out on the mailing > >>>>>> list. > >>>>>>> From re-reading all those comments, I also get the impression > >>>> that > >>>>>>> there is consensus/agreement on the changes that need to be > >>>>>> addressed. > >>>>>>> The editors (specifically Martin) is preparing a new revision > >>>> based > >>>>>>> on the result of the discussions. Will probably show up later > >>>> today. > >>>>>>> Our plan as WG-chairs is to allow the WG a few days to quickly > >>>> check > >>>>>>> if the changes are OK. Then ask our Ad to bring it forward to > >>>> IETF > >>>>>>> Last Call and IESG review. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Bert and Mehmet > >>>>>>> _______________________________________________ > >>>>>>> Netconf mailing list > >>>>>>> Netconf@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/netconf > >>>>>>> e-mail message attachment > >>>>>>>> -------- Forwarded Message -------- > >>>>>>>> From: Internet-Drafts@ietf.org > >>>>>>>> Reply-to: > >>>>>>>> To: i-d-announce@ietf.org > >>>>>>>> Cc: netconf@ietf.org > >>>>>>>> Subject: I-D Action:draft-ietf-netconf-rfc4742bis-03.txt > >>>>>>>> Date: Wed, 20 Oct 2010 17:00:02 +0200 > >>>>>>>> > >>>>>>>> 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-03.txt > >>>>>>>> Pages : 10 > >>>>>>>> Date : 2010-10-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- > >>>>>> 03.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 > >>>>>> -- > >>>>>> Ladislav Lhotka, CESNET > >>>>>> PGP Key ID: E74E8C0C > >>>> -- > >>>> Ladislav Lhotka, CESNET > >>>> PGP Key ID: E74E8C0C > >>> _______________________________________________ > >>> 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 lhotka@cesnet.cz Fri Oct 22 09:28:59 2010 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 DE2163A68A8 for ; Fri, 22 Oct 2010 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 5YSjvIYFxTaN for ; Fri, 22 Oct 2010 09:28:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id DF78D3A677C for ; Fri, 22 Oct 2010 09:28:58 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4C04A2CDE05D; Fri, 22 Oct 2010 18:30:36 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201010221441.o9MEfMAH050726@idle.juniper.net> References: <201010221441.o9MEfMAH050726@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 18:30:34 +0200 Message-ID: <1287765034.12363.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Andy Bierman , Netconf , ext Margaret Wasserman Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:29:00 -0000 On Pá, 2010-10-22 at 10:41 -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >> NEW: > >> "This character sequence MUST NOT appear in an XML document." > >Works for me. > > This is a change to the NETCONF protocol, since it makes a previously > legal character sequence illegal. If we're willing to change > NETCONF, why not just repair the SSH transport mapping, where the > problem really exists. > > But if the WG really is following the "it's not a bug" line, then > I suggest: > > (a) The draft should include an explanation of why this is illegal, > with the history, etc. > > (b) The draft should include a description of the means to avoid > this sequence (amper escaping) and a list of places where that > escaping is not possible (processing instructions). > > That is, the draft should give all the details as we know them so > an implementor can understand and properly address the issues. Absolutely. > > Me, I think it's a bug. A minor one, sure, but at least on par with > the other issues addressed with netconf-1.1. Same here. Lada > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Oct 22 09:35:12 2010 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 39F7B3A68A8 for ; Fri, 22 Oct 2010 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 dP1PsnUYXI7o for ; Fri, 22 Oct 2010 09:35:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id EF56A3A677C for ; Fri, 22 Oct 2010 09:35:07 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id DF3A72CDE05D; Fri, 22 Oct 2010 18:36:44 +0200 (CEST) From: Ladislav Lhotka To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E5989@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64011E57E3@DEMUEXC006.nsn-intra.net> <20101022143647.GB30247@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64011E5989@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 22 Oct 2010 18:36:43 +0200 Message-ID: <1287765403.12363.45.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: ext Margaret Wasserman , Andy Bierman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 16:35:12 -0000 On Pá, 2010-10-22 at 18:20 +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > >> NEW: > >> "RFC 4742 assumes that the EOM sequence cannot appear in any XML > document, > >> which turned out to be mistaken. The EOM sequence can cause > operational > >> problems and open space for attacks if sent deliberately in an XML > document. > >> It is however believed that the associated threat is not very high. > This > >> document keeps using the EOM sequence to avoid incompatibility with > >> existing clients. > >> NETCONF implementations using the SSH transport must exercise extra > care > >> and make sure the EOM sequence is not present in NETCONF messages > before > >> passing them to the Transport layer, even if they were well-formed > XML." > > > > So where does this go, into 4741bis or 4742bis? The last sentence more > > sounds like 4741bis since it says something about what the NETCONF > > message layer has to do. > > Agree it should rather be: > > NEW (in security consideration section of 4742bis): > > "RFC 4742 assumes that the EOM sequence cannot appear in any XML > document, > which turned out to be mistaken. The EOM sequence can cause operational > problems and open space for attacks if sent deliberately in an XML > document. > It is however believed that the associated threat is not very high. This > document keeps using the EOM sequence to avoid incompatibility with > existing clients. s/clients/implementations/ Lada > Implementations of SSH transport should exercise extra care and make > sure > the EOM sequence is not present in an XML document." > > Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Fri Oct 22 10:17:32 2010 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 37A2928B56A for ; Fri, 22 Oct 2010 10:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, 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 D+l0KF4X52fD for ; Fri, 22 Oct 2010 10:17:23 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 450783A6910 for ; Fri, 22 Oct 2010 10:17:19 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9MHGDo3031013; Fri, 22 Oct 2010 10:18:45 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s3ehug0at-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Oct 2010 10:18:45 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Oct 2010 10:23:03 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 22 Oct 2010 10:18:44 -0700 From: Andy Bierman To: Ladislav Lhotka , "Bert (IETF) Wijnen" Date: Fri, 22 Oct 2010 10:18:42 -0700 Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis Thread-Index: ActyBlKcFpzUgEkoS7eQu5asAZfkBAABPlbw Message-ID: References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <1287747488.12363.35.camel@missotis> <4CC17FFB.8020406@bwijnen.net> <1287764974.12363.43.camel@missotis> In-Reply-To: <1287764974.12363.43.camel@missotis> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-22_10:2010-10-22, 2010-10-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010220117 X-Proofpoint-SSN: Sensitivity2 Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 17:17:32 -0000 SGksDQoNCldlIHdlbnQgdGhyb3VnaCBhbGwgdGhpcyBhbHJlYWR5IGF0IHRoZSBsYXN0IElFVEYu DQoNCkluIG9yZGVyIHRvIGNoYW5nZSB0aGUgZnJhbWluZyBmb3IgU1NILCBhIG5ldyBzdWJzeXN0 ZW0gb3IgcG9ydCBudW1iZXINCm5lZWRzIHRvIGJlIHVzZWQsIHNvIHRoZSBuZXcgZnJhbWluZyBp cyB1c2VkIGZvciBldmVyeSBtZXNzYWdlLA0KZXZlbiB0aGUgPGhlbGxvPi4gQSBoYWNrZXIgY291 bGQgcG9zc2libHkgcGlnZ3liYWNrIGFuIDxycGM+IG9udG8gdGhlIDxoZWxsbz4sDQpzbyBzd2l0 Y2hpbmcgZnJhbWluZyBtb2RlcyBhZnRlciB0aGUgPGhlbGxvPiBkb2VzIG5vdCBmaXggdGhlIHBy b2JsZW0uDQoNClVzaW5nIG11bHRpcGxlIHN1YnN5c3RlbXMgYWRkcyBjb21wbGV4aXR5IHRvIE5N UyBhcHBsaWNhdGlvbnMsDQphbmQgcmVxdWlyZXMgdGhhdCBhIG5ldyBOTVMgbWFrZSAyIGNvbm5l Y3Rpb24gYXR0ZW1wdHMgdG8gZGV0ZXJtaW5lDQppZiB3aGljaCBwcm90b2NvbCB2ZXJzaW9ucyBh cmUgc3VwcG9ydGVkIG9uIHRoZSBzZXJ2ZXIuDQpVc2luZyBhYmlsaXR5LXRvLWNvbm5lY3Qtcmln aHQtbm93IGlzIGEgYmFkIHdheSB0byBtYW5hZ2UgdmVyc2lvbiBjb250cm9sLg0KDQpUaGVzZSBh cmUgdGhlIHJlYXNvbnMgdGhlIFdHIGRlY2lkZWQgdG8gd2FpdCB1bnRpbCBhIG1ham9yIHJlbGVh c2UNCnRvIGNoYW5nZSB0aGUgZnJhbWluZy4NCg0KDQpBbmR5DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAY2VzbmV0LmN6 XQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDIyLCAyMDEwIDk6MzAgQU0NClRvOiBCZXJ0IChJRVRG KSBXaWpuZW4NCkNjOiBBbmR5IEJpZXJtYW47IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmlj aCk7IGV4dCBNYXJnYXJldCBXYXNzZXJtYW47IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29u Zl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDIFJGQzQ3NDFiaXMN Cg0KT24gUMOhLCAyMDEwLTEwLTIyIGF0IDE0OjEzICswMjAwLCBCZXJ0IChJRVRGKSBXaWpuZW4g d3JvdGU6DQo+IE9uIDEwLzIyLzEwIDE6MzggUE0sIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4g PiBPbiBQw6EsIDIwMTAtMTAtMjIgYXQgMTM6MjAgKzAyMDAsIEJlcnQgKElFVEYpIFdpam5lbiB3 cm90ZToNCj4gPj4gQXMgYSB0ZWNobmljYWwgY29udHJpYnV0b3IuDQo+ID4+DQo+ID4+IE15IHVu ZGVyc3RhbmRpbmcgd2FzIChhbmQgc3RpbGwgaXMpOg0KPiA+Pg0KPiA+PiAtIGF0IHJmYzQ3NDEg dGltZSwgd2UgdGhvdWdodCB0aGF0IHRoZSBzZXF1ZW5jZSBjb3VsZCBOT1QgbGVnYWxseSBvY2N1 cg0KPiA+PiAgICAgIGluIGFuIFhNTCBkb2N1bWVudC4NCj4gPj4gLSBzbyB3ZSBkZWNpZGVkIHRo YXQgdGhlIHNlcXVlbmNlIHNlcnZlcyBhcyBhbiBFT00uIFdoaWNoIEkgdW5kZXJzdGFuZCB0byBt ZWFuDQo+ID4+ICAgICAgdGhhdCB0aGUgU1NIIGxheWVyIGRvZXMgbm90IChhdCBsZWFzdCBkb2Vz IG5vdCBuZWVkIHRvKSBwYXJzZSBYTUwgYXQgYWxsLiBJdCBqdXN0DQo+ID4+ICAgICAgc2VhcmNo ZWQgaW4gdGhlIHN0cmVhbSBmb3IgdGhlIEVPTSBzZXF1ZW5jZSwgYW5kIHRoZW4gcGFzc2VzIHRo ZSBkYXRhIHVwDQo+ID4+ICAgICAgdG8gdGhhdCBwb2ludCB0byB0aGUgbmV0Y29uZiBsYXllci4N Cj4gPj4gLSB3ZSBsZWFybmVkIGxhdGVyIHRoYXQgdGhlIHNlcXVlbmNlIG1heSBvY2N1ciBpbiBj b21tZW50cyBhbmQgZGVjaWRlZCB0aGF0DQo+ID4+ICAgICAgd2UgZG8gbm90IGNvbnNpZGVyIHRo YXQgYXMgYSBwcm9ibGVtLCBhbnMgZG8gd2UgZG8gKG9yIHNob3VsZCkgYWR2aXNlDQo+ID4+ICAg ICAgdXNlcnMgdG8gTk9UIHVzZSB0aGUgRU9NIHNlcXVlbmNlIGluIFhNTCBjb21tZW50cw0KPiA+ PiAtIHRoZW4geWV0IGxhdGVyIHdlIGxlYXJuZWQgdGhhdCBpdCBjYW4gb2NjdXIgaW4gUEkgYW5k IGF0dHJpYnV0ZSB2YWx1ZXMsIGJ1dCB3ZSBkZWNpZGVkDQo+ID4+ICAgICAgKG9yIGNvbmNsdWRl ZCBiYXNlZCBvbiBleHBlcmllbmNlKSB0aGF0IHdlIGFyZSBub3QgdXNpbmcvbmVlZGluZyBQSSBp biBORVRDT05GDQo+ID4+ICAgICAgb3IgTkVUQ09ORiBjb250ZW50LCBhbmQgdGhhdCB3ZSBhbHNv IGRvIG5vdCBuZWVkIGl0IGluIGF0dHJpYnV0ZSB2YWx1ZXMuDQo+ID4+ICAgICAgU28sIHdlIGZp Z3VyZSBpdCBpcyBzdGlsbCBPSyB0byB1c2UgdGhlIEVPTSBtYXJrZXIsIGF0IGxlYXN0IHVudGls bCBzb21lb25lIHNob3dzIHVzDQo+ID4+ICAgICAgYSBnb29kIHVzZSBjYXNlIHdoZXJlIG91ciBF T00gbWFya2VyIGlzIG5lZWRlZCB3aXRoIE5FVENPTkYuDQo+ID4gSXQgbWF5IG5vdCBiZSBuZWVk ZWQgYnV0IGl0IGlzIGF2YWlsYWJsZSB0byBhdHRhY2tlcnMgd2hvIG1heSB0cnkgdG8NCj4gPiBp bmplY3QgdGhlIG1hcmtlciBpbiB2YXJpb3VzIHBsYWNlcy4gVGhpcyBjb3VsZCBiZSBkb25lIGlu ZGlyZWN0bHksIGJ5DQo+ID4gZXhwbG9pdGluZyBvdGhlciBob2xlcyBzdWNoIGFzIHN0YWNrIG92 ZXJmbG93IGluIHRoZSBjbGllbnQgY29kZS4NCj4gPg0KPiA+IElmIHRoaXMgZXZlciBoYXBwZW5z LCBhbGwgTkVUQ09ORiBpbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIHRvIGJlDQo+ID4gcGF0Y2hl ZCB2ZXJ5IHF1aWNrbHkuIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGZpeCBpdCBOT1cgdGhhbiBp biBzdWNoIGFuDQo+ID4gZW1lcmdlbmN5IHNpdHVhdGlvbi4NCj4gPg0KPg0KPiBMYWRhLCB0aGF0 ICJmaXggaXQgbm93IiBtYXkgYmUgYmV0dGVyIGluIHRoZSB2aWV3IG9mIHNvbWUgcGVvcGxlLCBi dXQNCj4gd2Ugd2VyZSB1bmFibGUgdG8gcmVhY2ggYWdyZWVtZW50DQo+IG9uIGZpeGluZyBpdCBu b3cuIFNvIHRoYXQgImJldHRlciBmaXggaXQgbm93IiBpcyBubyBsb25nZXIgb3BlbiBmb3IgZGlz Y3Vzc2lvbi4NCg0KT0ssIEkganVzdCBkb24ndCBhZ3JlZSB3aXRoIHRoZSBsb2dpYyB0aGF0IGFz IGxvbmcgdGhlcmUgYXJlIG5vIHVzZQ0KY2FzZXMgZm9yIHRoZSBFT00gbWFya2VyIGluc2lkZSBO RVRDT05GIG1lc3NhZ2VzIHRoZSBtYXJrZXIgaXMgZ29vZA0KZW5vdWdoLiBUaGUgcHJvYmxlbSBh cmUgbWlzdXNlIGNhc2VzLCBub3QgdXNlIGNhc2VzLg0KDQo+DQo+IFdlJ3JlIGRpc2N1c3Npbmcg aG93IHRvIGJlc3QgZG9jdW1lbnQgdGhlIHNpdHVhdGlvbiB3ZSBoYXZlIGNyZWF0ZWQuDQoNClll cywgSSB1bmRlcnN0YW5kIGFuZCB0cmllZCB0byB3b3JrIGluIHRoYXQgZGlyZWN0aW9uLCB0b28u IEkganVzdA0KY291bGRuJ3QgcmVzaXN0IGhlcmUuIDotKQ0KDQpMYWRhDQoNCj4NCj4gQmVydCAo bm93IHNwZWFraW5nIGFzIGEgV0cgY2hhaXIpDQo+ID4gTGFkYQ0KPiA+DQo+ID4+IFNvLCB3ZSB3 YW50IGJlIGNvcnJlY3QvcHJlY2lzZS9ob25lc3QgaW4gZXhhY3RseSBzcGVjaWZ5aW5nIGhvdyB0 aGUgc2VxdWVuY2UgY2FuDQo+ID4+IHRoZW9yZXRpY2FsbHkgYW5kIGxlZ2FsbHkgYXBwZWFyIGlu IGFuIFhNTCBkb2N1bWVudC4NCj4gPj4gV2UgdGhlbiB3YW50IHRvIHN0YXRlIHRoYXQgd2UgYmVs aWV2ZSwgYmFzZWQgb24gb3VyIGV4cGVyaWVuY2UsIHRoYXQgdGhhdCBzZXF1ZW5jZQ0KPiA+PiBp cyBpbiBwcmFjdGljZSBub3QgdXNlZC9uZWVkZWQgaW4gTkVUQ09ORiwgYW5kIHNvIHRoYXQgd2Ug c3RpbGwgYmVsaWV2ZSBpdCBpcyBPSw0KPiA+PiB0byB1c2UgdGhhdCBzZXF1ZW5jZSBhcyBFT00g bWFya2VyLCBubyBtYXR0ZXIgd2hlcmUgaW4gdGhlIHRyYW5zcG9ydCBzdHJlYW0gaXQNCj4gPj4g b2NjdXJzLg0KPiA+Pg0KPiA+PiBXZSBjb3VsZCBhZGQgYSBxdWVzdGlvbiB0aGF0IGlmIGFueW9u ZSBldmVyIHNlZXMgYSBuZWVkIHRvIHVzZSB0aGUgc2VxdWVuY2UgdGhhdA0KPiA+PiB0aGV5IGJl dHRlciBpbmZvcm0gdXMgKG5ldGNvbmYgV0cpIGFzYXAgd2l0aCBhIGdvb2QgZGVzY3JpcHRpb24g b2YgdGhlIHNjZW5hcmlvLg0KPiA+Pg0KPiA+PiBCZXJ0DQo+ID4+DQo+ID4+IE9uIDEwLzIxLzEw IDg6NTEgUE0sIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPj4+IEhpLA0KPiA+Pj4NCj4gPj4+IFRo ZSBvcmlnaW5hbCBpbnRlbnQgd2FzIHRvIHVzZSBhIGNoYXIgc2VxdWVuY2UgdGhhdCB3YXMgbm90 IGxlZ2FsIGluDQo+ID4+PiBhbiBYTUwgaW5zdGFuY2UgZG9jdW1lbnQuICBOb2JvZHkgaW4gdGhl IFdHIGF0IHRoZSB0aW1lIGtuZXcgZm9yIHN1cmUsDQo+ID4+PiBzbyB3ZSBhc2tlZCB0aGUgWE1M IERpcmVjdG9yYXRlLiAgV2Ugd29ya2VkIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQNCj4gPj4+ IHRoZSBdXT5dXT4gICBzZXF1ZW5jZSB3YXMgYSBzdWl0YWJsZSBtZXNzYWdlIGJvdW5kYXJ5IG1h cmtlci4NCj4gPj4+DQo+ID4+PiBJIHdvdWxkIGxpa2UgdG8gaGVhciBldmlkZW5jZSB0aGF0IHRo aXMgRU9NIHNlcXVlbmNlIGlzIGNhdXNpbmcgcHJvYmxlbXMNCj4gPj4+IGZvciBvcGVyYXRvcnMg dXNpbmcgTkVUQ09ORi4gIElzIHRoaXMgcmVhbGx5IGEgY29uY2VybiB0byBvcGVyYXRvcnM/DQo+ ID4+PiBXb3VsZCBhIHNpZ25pZmljYW50IHByb3RvY29sIGNoYW5nZSB0byBhZGRyZXNzIHRoaXMg aXNzdWUgY2F1c2UgbW9yZQ0KPiA+Pj4gb3BlcmF0aW9uYWwgcHJvYmxlbXMgdGhhbiBpdCBzb2x2 ZXM/DQo+ID4+Pg0KPiA+Pj4gSSBkbyBub3QgYWdyZWUgdGhhdCB0aGlzIG11c3QgYmUgZml4ZWQg aW4gTkVUQ09ORiAyLjAsIHdoZW5ldmVyIHRoYXQgaXMuDQo+ID4+PiBXZSBzaG91bGQgZGVjaWRl IGF0IHRoZSB0aW1lLCBhZnRlciBzb21lIG1vcmUgZGVwbG95bWVudCBleHBlcmllbmNlLg0KPiA+ Pj4NCj4gPj4+DQo+ID4+PiBBbmR5DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcnN1ZSwgTWVobWV0IChO U04gLSBERS9NdW5pY2gpDQo+ID4+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMSwgMjAxMCAx MToyMSBBTQ0KPiA+Pj4gVG86IGV4dCBMYWRpc2xhdiBMaG90a2ENCj4gPj4+IENjOiBleHQgTWFy Z2FyZXQgV2Fzc2VybWFuOyBOZXRjb25mDQo+ID4+PiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0 YXR1cyBXR0xDIFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dMQyBSRkM0NzQxYmlzDQo+ID4+ Pg0KPiA+Pj4gSGkgTGFkYSwNCj4gPj4+DQo+ID4+Pj4gSGkgTWVobWV0LA0KPiA+Pj4+DQo+ID4+ Pj4gT24gxIx0LCAyMDEwLTEwLTIxIGF0IDE4OjQ5ICswMjAwLCBFcnN1ZSwgTWVobWV0IChOU04g LSBERS9NdW5pY2gpDQo+ID4+Pj4gd3JvdGU6DQo+ID4+Pj4+IEhpIExhZGEsDQo+ID4+Pj4+DQo+ ID4+Pj4+IFtzcGVha2luZyBhcyBhIGNvbnRyaWJ1dG9yXQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBpZiBJ IHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB5b3Ugd2FudCB0byBhbGxvdyB0aGUgRU9NDQo+ID4+ Pj4+IG5vdCBvbmx5IGluIGNvbW1lbnRzIGJ1dCBhbHNvIGluIFhNTCBhdHRyaWJ1dGVzIGFuZCBQ SXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IEluIGNhc2UgdGhlIGFuc3dlciBpcyBubzogSSBhcHBlYXIg dG8gbWlzdW5kZXJzdGFuZCB3aGF0DQo+ID4+Pj4+IHlvdSB3ZXJlIHNheWluZy4gU28gcGxzIGV4 cGxhaW4uDQo+ID4+Pj4gSSBjZXJ0YWlubHkgZG9uJ3Qgd2FudCB0byBhbGxvdyBhbnl0aGluZyB0 aGF0IGlzbid0IGFscmVhZHkgYWxsb3dlZC4gOi0NCj4gPj4+PiApDQo+ID4+Pj4NCj4gPj4+PiBU aGUgY3VycmVudCB0ZXh0IHNheXMsIGFzIEkgdW5kZXJzdGFuZCBpdCwgdGhhdCBYTUwgc3BlY2lm aWNhdGlvbg0KPiA+Pj4+IGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8gYXBwZWFyIG91 dHNpZGUgY29tbWVudHMgaW4gYW4gWE1MDQo+ID4+Pj4gZG9jdW1lbnQgKGFuZCB0aGVyZWZvcmUg aXQgaXMgYSBnb29kIGNob2ljZSkuIEJ1dCB0aGlzIGlzIG5vdCB0cnVlOiBYTUwNCj4gPj4+PiBk b2N1bWVudHMgaGF2aW5nIHRoZSBzZXF1ZW5jZSBpbiBQSXMgYW5kIGF0dHJpYnV0ZSB2YWx1ZXMg YXJlDQo+ID4+Pj4gd2VsbC1mb3JtZWQgYXMgd2VsbC4gVGhlIG9ubHkgcGxhY2Ugd2hlcmUgdGhl IHNlcXVlbmNlIGlzIHJlYWxseQ0KPiA+Pj4+IGZvcmJpZGRlbiBpcyBlbGVtZW50IHRleHQuDQo+ ID4+PiAiVGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIGluIGFu IFhNTCBkb2N1bWVudCwgc28NCj4gPj4+IGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8g aW5kZW50aWZ5IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQNCj4gPj4+IGRvY3VtZW50IGluIHRoZSBl dmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNpbmcgZXJyb3IsIGFsbG93aW5nDQo+ID4+PiBy ZXN5bmNocm9uaXphdGlvbiBvZiB0aGUgTkVUQ09ORiBleGNoYW5nZS4iDQo+ID4+Pg0KPiA+Pj4g VGhlIHNlbnRlbmNlIGlzIGFjdHVhbGx5IHNpbmNlIE1heSAyMDA0ICh2MDEpIGluIFNTSCBkb2N1 bWVudA0KPiA+Pj4gYW5kIGRpZCBub3QgY2hhbmdlIHVudGlsIHRvZGF5LiBJIGRvbid0IGtub3cg ZXhhY3RseSB3aGF0IHRoZQ0KPiA+Pj4gYWltIG9mIHRoZSBhdXRob3JzIHdhcyB0byB3cml0ZSBp dCB0aGF0IHdheS4NCj4gPj4+DQo+ID4+PiBPbmUgb3B0aW9uIGlzIHRoZXkgd2FudGVkIHRvIHN0 YXRlIHRoYXQgdGhlIEVPTSAiLi4uIE1VU1QgTk9UDQo+ID4+PiBhcHBlYXIgb3V0c2lkZSBvZiBh IGNvbW1lbnQgaW4gYW4gWE1MIGRvY3VtZW50Iiwgd2hpY2ggd291bGQNCj4gPj4+IGJlIGEgY29u c2lzdGVudCByZXN0cmljdGlvbi4NCj4gPj4+DQo+ID4+PiBUaGUgb3RoZXIgb3B0aW9uIGlzIGhv dyB5b3UgdW5kZXJzdGFuZCBpdDoNCj4gPj4+ICJYTUwgc3BlY2lmaWNhdGlvbiBkb2Vzbid0IGFs bG93IHRoZSBFT00gbWFya2VyIHRvIGFwcGVhcg0KPiA+Pj4gb3V0c2lkZSBjb21tZW50cyINCj4g Pj4+DQo+ID4+PiAuLi53aGljaCBpcyBvYnZpb3VzbHkgbm90IGNvcnJlY3QgYW5kIGNhbiBiZSBh ZGRyZXNzZWQgYXMNCj4gPj4+IHlvdSBzdWdnZXN0LiBCdXQgdGhpcyB3b3VsZCBtZWFuIGFkZGl0 aW9uYWwgaW1wbGVtZW50YXRpb24NCj4gPj4+IGVmZm9ydCBmb3IgU1NIIHRyYW5zcG9ydC4NCj4g Pj4+DQo+ID4+PiBNYXJnYXJldCwgVGVkLCBBbmR5Og0KPiA+Pj4gQ2FuIHlvdSBwbGVhc2UgY2xh cmlmeSB3aGF0IHRoZSBvcmlnaW5hbCBhaW0gd2FzPw0KPiA+Pj4NCj4gPj4+IFdoYXQgZG8gb3Ro ZXJzIGluIHRoZSBXRyB0aGluaz8NCj4gPj4+IFBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYmVm b3JlIEZyaWRheSBFT0IuDQo+ID4+Pg0KPiA+Pj4gTWVobWV0DQo+ID4+Pg0KPiA+Pj4+IExhZGEN Cj4gPj4+Pg0KPiA+Pj4+PiBJbiBjYXNlIHRoZSBhbnN3ZXIgaXMgeWVzOg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBUaGVvcmV0aWNhbGx5IHRoZSBFT00gc2VxdWVuY2UgY2FuIGFwcGVhciBldmVyeXdoZXJl IGluDQo+ID4+Pj4+IGFuIFhNTCBkb2N1bWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSG93ZXZlciwg dGhlIHRyYW5zcG9ydCBsYXllciBzaG91bGRuJ3QgZG8gZmluZSBncmFpbmVkDQo+ID4+Pj4+IHBh cnNpbmcgb2YgdGhlIFhNTCBkb2N1bWVudCwgdG8gZmluZCBvdXQgd2hlcmUgdGhlDQo+ID4+Pj4+ IGF0dHJpYnV0ZXMgb3IgUElzIGFyZS4NCj4gPj4+Pj4gVGhpcyBpcyB0aGUgcmVhc29uIHdoeSA0 NzQyIGtlcHQgaXQgc2ltcGxlIGFuZCwgYXMgSQ0KPiA+Pj4+PiB0aGluaywgYXBwcm9wcmlhdGUg Zm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFu eSBkaWZmZXJlbmNlIGJldHdlZW4gWE1MIGVsZW1lbnRzIGFuZA0KPiA+Pj4+PiBbYXR0cmlidXRl cyBvciBQSV0uIFRoZXkgYWxsIGFyZSBYTUwgZGF0YS4gQW5kIEVPTSBjYW4NCj4gPj4+Pj4gYXBw ZWFyIGluIFhNTCBkYXRhIG9yIGF0IHRoZSBlbmQgb2YgdGhlIGRvY3VtZW50Lg0KPiA+Pj4+PiBJ ZiBzb21lYm9keSB3YW50cyB0byBkaXNydXB0IHRoZSBycGMgY29tbWFuZCBoZSBjYW4NCj4gPj4+ Pj4gZG8gaXQgbm8gbWF0dGVyIGluIGVsZW1lbnRzIG9yIGF0dHJpYnV0ZXMuDQo+ID4+Pj4+DQo+ ID4+Pj4+IFNvLCBhdCB0aGUgZW5kIEkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0IGluIHJlZHVjaW5n IHRoZQ0KPiA+Pj4+PiByZXN0cmljdGlvbiBhbmQgdGhpbms6DQo+ID4+Pj4+IFRvIGJlIG9uIHRo ZSBzYWZlIHNpZGUgYW5kIHRvIGtlZXAgaXQgc2ltcGxlIGZvciB0aGUNCj4gPj4+Pj4gaW1wbGVt ZW50ZXIgb2YgNDc0MmJpcyB0aGUgc2VxdWVuY2UgbXVzdCBub3QgYXBwZWFyDQo+ID4+Pj4+IGlu IHRoZSBYTUwgZG9jdW1lbnQgKGV4Y2VwdCBvdXRzaWRlIG9mIGNvbW1lbnRzKS4NCj4gPj4+Pj4N Cj4gPj4+Pj4gW25vdyB0aGUgY2hhaXIgaGF0IG9uXToNCj4gPj4+Pj4NCj4gPj4+Pj4gUGxlYXNl IGtlZXAgaW4gbWluZCB0aGF0IHdlIGRvbid0IGhhdmUgdGhlIG1hbmRhdGUNCj4gPj4+Pj4gZm9y IHYyLjAuIFdlIGFyZSBqdXN0IGRvaW5nIGJ1Zy1maXhpbmcuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkg YWdyZWUgd2l0aCB5b3UgdGhhdCB2Mi4wIHNob3VsZCBzb2x2ZSB0aGlzIGlzc3VlDQo+ID4+Pj4+ IHdpdGggYSB0aG9yb3VnaCBzb2x1dGlvbi4gV291bGQgeW91IGxpa2UgdG8gcHJlcGFyZQ0KPiA+ Pj4+PiBhIGZldyBzbGlkZXMgZm9yIHRoZSBORVRDT05GIHNlc3Npb24gaW4gQmVpamluZyBmb3IN Cj4gPj4+Pj4gYSBzb2x1dGlvbiwgd2hpY2ggY291bGQgYmUgcHV0IGxhdGVyIGludG8gdjIuMD8N Cj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+PiBNZWhtZXQNCj4gPj4+Pj4NCj4gPj4+ Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBl eHQgTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQGNlc25ldC5jel0NCj4gPj4+Pj4+IFNl bnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMCwgMjAxMCA3OjIzIFBNDQo+ID4+Pj4+PiBUbzogRXJz dWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KPiA+Pj4+Pj4gQ2M6IE5ldGNvbmY7IGV4dCBN YXJnYXJldCBXYXNzZXJtYW4NCj4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gU3RhdHVz IFdHTEMgUkZDNDc0MmJpcyBXQVM6Rlc6IHN0YXR1cyBXR0xDDQo+ID4+Pj4+PiBSRkM0NzQxYmlz DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gU3QsIDIwMTAtMTAtMjAgYXQgMTg6MjcgKzAyMDAsIEVy c3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCj4gPj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+ IEhpIEFsbCwNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IHNhbWUgaXMgd2l0aCA0NzQyYmlzIFdHTEMg ZGlzY3VzaW9uLiBXZSBoYWQgb25seSBtaW5vcg0KPiA+Pj4+Pj4+IGNoYW5nZXMgYWZ0ZXIgSUVU RiA3OC4gT3VyIGltcHJlc3Npb24gaXMgdGhhdCB3ZSBoYXZlDQo+ID4+Pj4+Pj4gY29uc2Vuc3Vz IHRvIHNlZSB0aGUgZHJhZnQgYXMgZmluYWwuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBNYXJnYXJl dCBzdWJtaXR0ZWQgdGhlIGRyYWZ0IHRvZGF5IG1ha2luZyBpdCByZWFkeSBmb3INCj4gPj4+Pj4+ PiBBRCByZXZpZXcuIFBsZWFzZSBjaGVjayB0aGUgY2hhbmdlcyBieSAxMC8yMiBzbyB0aGF0DQo+ ID4+Pj4+Pj4gd2UgaGF2ZSBhIGNoYW5jZSB0byByZS1zdWJtaXQgYmVmb3JlIGRlYWRsaW5lLiBU aGFua3MuDQo+ID4+Pj4+PiBUaGUganVzdGlmaWNhdGlvbiBmb3IgdGhlIEVPTSBtYXJrZXIgaW4g c2VjLiAzLjEgaXMgdGVjaG5pY2FsbHkNCj4gPj4+Pj4+IGluY29ycmVjdCAtIGFuZCBJIG9iamVj dGVkIGFnYWluc3QgaXQgcHJldmlvdXNseToNCj4gPj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYyNzcuaHRtbA0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+IEhlcmUgaXMgdGhlIGNoYW5nZSBJIHByb3Bvc2UgKHRoZXJlJ3MgYWxzbyBhIHR5 cG8gaW4NCj4gPj4+PiAidW5hbWJpZ3VvdXNseSIpOg0KPiA+Pj4+Pj4gT0xEDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gVGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91 dHNpZGUgb2YgYSBjb21tZW50DQo+ID4+Pj4gaW4NCj4gPj4+Pj4+IGFuDQo+ID4+Pj4+PiBYTUwg ZG9jdW1lbnQsIHNvIGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8gaWRlbnRpZnkgdGhl IGVuZA0KPiA+Pj4+IG9mDQo+ID4+Pj4+PiB0aGUNCj4gPj4+Pj4+IGN1cnJlbnQgZG9jdW1lbnQs IGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBORVRDT05GDQo+ID4+Pj4gZXhjaGFu Z2UgaW4NCj4gPj4+Pj4+IHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNpbmcgZXJy b3IuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTkVXDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhpcyBjaGFy YWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUgb2YgYSBjb21tZW50 LA0KPiA+Pj4+Pj4gcHJvY2Vzc2luZyBpbnN0cnVjdGlvbiBhbmQgYXR0cmlidXRlIHZhbHVlIGlu IGFuIFhNTCBkb2N1bWVudCwgc28NCj4gPj4+PiBpdA0KPiA+Pj4+Pj4gY2FuDQo+ID4+Pj4+PiBi ZSB1bmFtYmlndW91c2x5IHVzZWQgdG8gaWRlbnRpZnkgdGhlIGVuZCBvZiB0aGUgY3VycmVudCBk b2N1bWVudCwNCj4gPj4+Pj4+IGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBORVRD T05GIGV4Y2hhbmdlIGluIHRoZSBldmVudCBvZg0KPiA+Pj4+IGFuDQo+ID4+Pj4+PiBYTUwgc3lu dGF4IG9yIHBhcnNpbmcgZXJyb3IuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTGFkYQ0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+Pj4gTWVobWV0DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4gRnJvbTog bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XQ0KPiA+Pj4+IE9uDQo+ID4+Pj4+Pj4gQmVoYWxmIE9mIGV4dCBCZXJ0IFdpam5lbiAoSUVURikN Cj4gPj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgMzo1MiBQTQ0KPiA+ Pj4+Pj4+IFRvOiBOZXRjb25mDQo+ID4+Pj4+Pj4gU3ViamVjdDogW05ldGNvbmZdIHN0YXR1cyBX R0xDIFJGQzQ3NDFiaXMNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEl0IHNlZW1zIHRoYXQgdGhlIFdH TEMgZGlzY3Vzc2lvbiBoYXMgbm93IGRpZWQgb3V0IG9uIHRoZSBtYWlsaW5nDQo+ID4+Pj4+PiBs aXN0Lg0KPiA+Pj4+Pj4+ICAgIEZyb20gcmUtcmVhZGluZyBhbGwgdGhvc2UgY29tbWVudHMsIEkg YWxzbyBnZXQgdGhlIGltcHJlc3Npb24NCj4gPj4+PiB0aGF0DQo+ID4+Pj4+Pj4gdGhlcmUgaXMg Y29uc2Vuc3VzL2FncmVlbWVudCBvbiB0aGUgY2hhbmdlcyB0aGF0IG5lZWQgdG8gYmUNCj4gPj4+ Pj4+IGFkZHJlc3NlZC4NCj4gPj4+Pj4+PiBUaGUgZWRpdG9ycyAoc3BlY2lmaWNhbGx5IE1hcnRp bikgaXMgcHJlcGFyaW5nIGEgbmV3IHJldmlzaW9uDQo+ID4+Pj4gYmFzZWQNCj4gPj4+Pj4+PiBv biB0aGUgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9ucy4gV2lsbCBwcm9iYWJseSBzaG93IHVwIGxh dGVyDQo+ID4+Pj4gdG9kYXkuDQo+ID4+Pj4+Pj4gT3VyIHBsYW4gYXMgV0ctY2hhaXJzIGlzIHRv IGFsbG93IHRoZSBXRyBhIGZldyBkYXlzIHRvIHF1aWNrbHkNCj4gPj4+PiBjaGVjaw0KPiA+Pj4+ Pj4+IGlmIHRoZSBjaGFuZ2VzIGFyZSBPSy4gVGhlbiBhc2sgb3VyIEFkIHRvIGJyaW5nIGl0IGZv cndhcmQgdG8NCj4gPj4+PiBJRVRGDQo+ID4+Pj4+Pj4gTGFzdCBDYWxsIGFuZCBJRVNHIHJldmll dy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4+PiBCZXJ0IGFuZCBNZWht ZXQNCj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+Pj4+Pj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4gTmV0Y29uZkBp ZXRmLm9yZw0KPiA+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0KPiA+Pj4+Pj4+IGUtbWFpbCBtZXNzYWdlIGF0dGFjaG1lbnQNCj4gPj4+Pj4+Pj4g LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPj4+Pj4+Pj4gRnJvbTogSW50 ZXJuZXQtRHJhZnRzQGlldGYub3JnDQo+ID4+Pj4+Pj4+IFJlcGx5LXRvOjxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPj4+ Pj4+Pj4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4gU3ViamVjdDogSS1EIEFjdGlv bjpkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNDc0MmJpcy0wMy50eHQNCj4gPj4+Pj4+Pj4gRGF0ZTog V2VkLCAyMCBPY3QgMjAxMCAxNzowMDowMiArMDIwMA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC0NCj4gPj4+PiBEcmFmdHMNCj4gPj4+Pj4+IGRpcmVjdG9yaWVzLg0KPiA+Pj4+Pj4+PiBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV29ya2lu Zw0KPiA+Pj4+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4+Pj4+Pj4+ICAgICAgVGl0bGUgICAg ICAgICAgIDogVXNpbmcgdGhlIE5FVENPTkYgQ29uZmlndXJhdGlvbiBQcm90b2NvbA0KPiA+Pj4+ IG92ZXINCj4gPj4+Pj4+IFNlY3VyZSBTaGVsbCAoU1NIKQ0KPiA+Pj4+Pj4+PiAgICAgIEF1dGhv cihzKSAgICAgICA6IE0uIFdhc3Nlcm1hbiwgVC4gR29kZGFyZA0KPiA+Pj4+Pj4+PiAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM0NzQyYmlzLTAzLnR4dA0KPiA+ Pj4+Pj4+PiAgICAgIFBhZ2VzICAgICAgICAgICA6IDEwDQo+ID4+Pj4+Pj4+ICAgICAgRGF0ZSAg ICAgICAgICAgIDogMjAxMC0xMC0yMA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgaW52b2tpbmcgYW5kIHJ1bm5pbmcgdGhlDQo+ID4+ Pj4+PiBORVRDT05GDQo+ID4+Pj4+Pj4+IHByb3RvY29sIHdpdGhpbiBhIFNlY3VyZSBTaGVsbCAo U1NIKSBzZXNzaW9uIGFzIGFuIFNTSA0KPiA+Pj4+IHN1YnN5c3RlbS4NCj4gPj4+Pj4+Pj4gQSBV UkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+ID4+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi0NCj4gPj4+PiByZmM0NzQy YmlzLQ0KPiA+Pj4+Pj4gMDMudHh0DQo+ID4+Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4+Pj4+Pj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQmVsb3cgaXMg dGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsDQo+ID4+Pj4g cmVhZGVyDQo+ID4+Pj4+Pj4+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmll dmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YNCj4gPj4+PiB0aGUNCj4gPj4+Pj4+Pj4gSW50ZXJuZXQt RHJhZnQuDQo+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+Pj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+IE5ldGNv bmZAaWV0Zi5vcmcNCj4gPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCj4gPj4+Pj4+IC0tDQo+ID4+Pj4+PiBMYWRpc2xhdiBMaG90a2EsIENFU05F VA0KPiA+Pj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPj4+PiAtLQ0KPiA+Pj4+IExhZGlz bGF2IExob3RrYSwgQ0VTTkVUDQo+ID4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBOZXRj b25mIG1haWxpbmcgbGlzdA0KPiA+Pj4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTmV0Y29uZiBtYWlsaW5n IGxpc3QNCj4gPj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPg0KDQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDRVNO RVQNClBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg== From mehmet.ersue@nsn.com Fri Oct 22 12:15:43 2010 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 88D7E3A680B for ; Fri, 22 Oct 2010 12:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 bLUpx1Tro1IC for ; Fri, 22 Oct 2010 12:15:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 469DA3A6807 for ; Fri, 22 Oct 2010 12:15:39 -0700 (PDT) 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 o9MJHALD001989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 21:17:10 +0200 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 o9MJH70i020859; Fri, 22 Oct 2010 21:17:09 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 21:16:39 +0200 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: Fri, 22 Oct 2010 21:16:36 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E59B9@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: ActyBlKcFpzUgEkoS7eQu5asAZfkBAABPlbwAAQ2hSA= References: <80A0822C5E9A4440A5117C2F4CD36A64011B6C9D@DEMUEXC006.nsn-intra.net> <1287595401.5999.7.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E539D@DEMUEXC006.nsn-intra.net> <1287681006.1606.106.camel@missotis> <80A0822C5E9A4440A5117C2F4CD36A64011E53C5@DEMUEXC006.nsn-intra.net> <4CC1736D.4010903@bwijnen.net> <1287747488.12363.35.camel@missotis> <4CC17FFB.8020406@bwijnen.net> <1287764974.12363.43.camel@missotis> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Ladislav Lhotka" , "Bert (IETF) Wijnen" X-OriginalArrivalTime: 22 Oct 2010 19:16:39.0655 (UTC) FILETIME=[A74B7770:01CB721D] Cc: ext Margaret Wasserman , Netconf Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 22 Oct 2010 19:15:43 -0000 QWdyZWUsIHRoZSBXRyBkZWNpZGVkIHRvIGRvIHRoZSBmcmFtaW5nIGNoYW5nZSB3aXRoIHYyLjAu DQoNCk1laG1ldA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0 IEFuZHkgQmllcm1hbiBbbWFpbHRvOmJpZXJtYW5hQEJyb2NhZGUuY29tXQ0KPiBTZW50OiBGcmlk YXksIE9jdG9iZXIgMjIsIDIwMTAgNzoxOSBQTQ0KPiBUbzogTGFkaXNsYXYgTGhvdGthOyBCZXJ0 IChJRVRGKSBXaWpuZW4NCj4gQ2M6IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCk7IGV4 dCBNYXJnYXJldCBXYXNzZXJtYW47IE5ldGNvbmYNCj4gU3ViamVjdDogUkU6IFtOZXRjb25mXSBT dGF0dXMgV0dMQyBSRkM0NzQyYmlzIFdBUzpGVzogc3RhdHVzIFdHTEMNCj4gUkZDNDc0MWJpcw0K PiANCj4gSGksDQo+IA0KPiBXZSB3ZW50IHRocm91Z2ggYWxsIHRoaXMgYWxyZWFkeSBhdCB0aGUg bGFzdCBJRVRGLg0KPiANCj4gSW4gb3JkZXIgdG8gY2hhbmdlIHRoZSBmcmFtaW5nIGZvciBTU0gs IGEgbmV3IHN1YnN5c3RlbSBvciBwb3J0IG51bWJlcg0KPiBuZWVkcyB0byBiZSB1c2VkLCBzbyB0 aGUgbmV3IGZyYW1pbmcgaXMgdXNlZCBmb3IgZXZlcnkgbWVzc2FnZSwNCj4gZXZlbiB0aGUgPGhl bGxvPi4gQSBoYWNrZXIgY291bGQgcG9zc2libHkgcGlnZ3liYWNrIGFuIDxycGM+IG9udG8gdGhl DQo+IDxoZWxsbz4sDQo+IHNvIHN3aXRjaGluZyBmcmFtaW5nIG1vZGVzIGFmdGVyIHRoZSA8aGVs bG8+IGRvZXMgbm90IGZpeCB0aGUgcHJvYmxlbS4NCj4gDQo+IFVzaW5nIG11bHRpcGxlIHN1YnN5 c3RlbXMgYWRkcyBjb21wbGV4aXR5IHRvIE5NUyBhcHBsaWNhdGlvbnMsDQo+IGFuZCByZXF1aXJl cyB0aGF0IGEgbmV3IE5NUyBtYWtlIDIgY29ubmVjdGlvbiBhdHRlbXB0cyB0byBkZXRlcm1pbmUN Cj4gaWYgd2hpY2ggcHJvdG9jb2wgdmVyc2lvbnMgYXJlIHN1cHBvcnRlZCBvbiB0aGUgc2VydmVy Lg0KPiBVc2luZyBhYmlsaXR5LXRvLWNvbm5lY3QtcmlnaHQtbm93IGlzIGEgYmFkIHdheSB0byBt YW5hZ2UgdmVyc2lvbg0KPiBjb250cm9sLg0KPiANCj4gVGhlc2UgYXJlIHRoZSByZWFzb25zIHRo ZSBXRyBkZWNpZGVkIHRvIHdhaXQgdW50aWwgYSBtYWpvciByZWxlYXNlDQo+IHRvIGNoYW5nZSB0 aGUgZnJhbWluZy4NCj4gDQo+IA0KPiBBbmR5DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAY2VzbmV0LmN6XQ0K PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMTAgOTozMCBBTQ0KPiBUbzogQmVydCAoSUVU RikgV2lqbmVuDQo+IENjOiBBbmR5IEJpZXJtYW47IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011 bmljaCk7IGV4dCBNYXJnYXJldA0KPiBXYXNzZXJtYW47IE5ldGNvbmYNCj4gU3ViamVjdDogUmU6 IFtOZXRjb25mXSBTdGF0dXMgV0dMQyBSRkM0NzQyYmlzIFdBUzpGVzogc3RhdHVzIFdHTEMNCj4g UkZDNDc0MWJpcw0KPiANCj4gT24gUMOhLCAyMDEwLTEwLTIyIGF0IDE0OjEzICswMjAwLCBCZXJ0 IChJRVRGKSBXaWpuZW4gd3JvdGU6DQo+ID4gT24gMTAvMjIvMTAgMTozOCBQTSwgTGFkaXNsYXYg TGhvdGthIHdyb3RlOg0KPiA+ID4gT24gUMOhLCAyMDEwLTEwLTIyIGF0IDEzOjIwICswMjAwLCBC ZXJ0IChJRVRGKSBXaWpuZW4gd3JvdGU6DQo+ID4gPj4gQXMgYSB0ZWNobmljYWwgY29udHJpYnV0 b3IuDQo+ID4gPj4NCj4gPiA+PiBNeSB1bmRlcnN0YW5kaW5nIHdhcyAoYW5kIHN0aWxsIGlzKToN Cj4gPiA+Pg0KPiA+ID4+IC0gYXQgcmZjNDc0MSB0aW1lLCB3ZSB0aG91Z2h0IHRoYXQgdGhlIHNl cXVlbmNlIGNvdWxkIE5PVCBsZWdhbGx5DQo+IG9jY3VyDQo+ID4gPj4gICAgICBpbiBhbiBYTUwg ZG9jdW1lbnQuDQo+ID4gPj4gLSBzbyB3ZSBkZWNpZGVkIHRoYXQgdGhlIHNlcXVlbmNlIHNlcnZl cyBhcyBhbiBFT00uIFdoaWNoIEkNCj4gdW5kZXJzdGFuZCB0byBtZWFuDQo+ID4gPj4gICAgICB0 aGF0IHRoZSBTU0ggbGF5ZXIgZG9lcyBub3QgKGF0IGxlYXN0IGRvZXMgbm90IG5lZWQgdG8pIHBh cnNlDQo+IFhNTCBhdCBhbGwuIEl0IGp1c3QNCj4gPiA+PiAgICAgIHNlYXJjaGVkIGluIHRoZSBz dHJlYW0gZm9yIHRoZSBFT00gc2VxdWVuY2UsIGFuZCB0aGVuIHBhc3Nlcw0KPiB0aGUgZGF0YSB1 cA0KPiA+ID4+ICAgICAgdG8gdGhhdCBwb2ludCB0byB0aGUgbmV0Y29uZiBsYXllci4NCj4gPiA+ PiAtIHdlIGxlYXJuZWQgbGF0ZXIgdGhhdCB0aGUgc2VxdWVuY2UgbWF5IG9jY3VyIGluIGNvbW1l bnRzIGFuZA0KPiBkZWNpZGVkIHRoYXQNCj4gPiA+PiAgICAgIHdlIGRvIG5vdCBjb25zaWRlciB0 aGF0IGFzIGEgcHJvYmxlbSwgYW5zIGRvIHdlIGRvIChvcg0KPiBzaG91bGQpIGFkdmlzZQ0KPiA+ ID4+ICAgICAgdXNlcnMgdG8gTk9UIHVzZSB0aGUgRU9NIHNlcXVlbmNlIGluIFhNTCBjb21tZW50 cw0KPiA+ID4+IC0gdGhlbiB5ZXQgbGF0ZXIgd2UgbGVhcm5lZCB0aGF0IGl0IGNhbiBvY2N1ciBp biBQSSBhbmQgYXR0cmlidXRlDQo+IHZhbHVlcywgYnV0IHdlIGRlY2lkZWQNCj4gPiA+PiAgICAg IChvciBjb25jbHVkZWQgYmFzZWQgb24gZXhwZXJpZW5jZSkgdGhhdCB3ZSBhcmUgbm90DQo+IHVz aW5nL25lZWRpbmcgUEkgaW4gTkVUQ09ORg0KPiA+ID4+ICAgICAgb3IgTkVUQ09ORiBjb250ZW50 LCBhbmQgdGhhdCB3ZSBhbHNvIGRvIG5vdCBuZWVkIGl0IGluDQo+IGF0dHJpYnV0ZSB2YWx1ZXMu DQo+ID4gPj4gICAgICBTbywgd2UgZmlndXJlIGl0IGlzIHN0aWxsIE9LIHRvIHVzZSB0aGUgRU9N IG1hcmtlciwgYXQgbGVhc3QNCj4gdW50aWxsIHNvbWVvbmUgc2hvd3MgdXMNCj4gPiA+PiAgICAg IGEgZ29vZCB1c2UgY2FzZSB3aGVyZSBvdXIgRU9NIG1hcmtlciBpcyBuZWVkZWQgd2l0aCBORVRD T05GLg0KPiA+ID4gSXQgbWF5IG5vdCBiZSBuZWVkZWQgYnV0IGl0IGlzIGF2YWlsYWJsZSB0byBh dHRhY2tlcnMgd2hvIG1heSB0cnkNCj4gdG8NCj4gPiA+IGluamVjdCB0aGUgbWFya2VyIGluIHZh cmlvdXMgcGxhY2VzLiBUaGlzIGNvdWxkIGJlIGRvbmUgaW5kaXJlY3RseSwNCj4gYnkNCj4gPiA+ IGV4cGxvaXRpbmcgb3RoZXIgaG9sZXMgc3VjaCBhcyBzdGFjayBvdmVyZmxvdyBpbiB0aGUgY2xp ZW50IGNvZGUuDQo+ID4gPg0KPiA+ID4gSWYgdGhpcyBldmVyIGhhcHBlbnMsIGFsbCBORVRDT05G IGltcGxlbWVudGF0aW9ucyB3aWxsIGhhdmUgdG8gYmUNCj4gPiA+IHBhdGNoZWQgdmVyeSBxdWlj a2x5LiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBmaXggaXQgTk9XIHRoYW4gaW4NCj4gc3VjaCBh bg0KPiA+ID4gZW1lcmdlbmN5IHNpdHVhdGlvbi4NCj4gPiA+DQo+ID4NCj4gPiBMYWRhLCB0aGF0 ICJmaXggaXQgbm93IiBtYXkgYmUgYmV0dGVyIGluIHRoZSB2aWV3IG9mIHNvbWUgcGVvcGxlLCBi dXQNCj4gPiB3ZSB3ZXJlIHVuYWJsZSB0byByZWFjaCBhZ3JlZW1lbnQNCj4gPiBvbiBmaXhpbmcg aXQgbm93LiBTbyB0aGF0ICJiZXR0ZXIgZml4IGl0IG5vdyIgaXMgbm8gbG9uZ2VyIG9wZW4gZm9y DQo+IGRpc2N1c3Npb24uDQo+IA0KPiBPSywgSSBqdXN0IGRvbid0IGFncmVlIHdpdGggdGhlIGxv Z2ljIHRoYXQgYXMgbG9uZyB0aGVyZSBhcmUgbm8gdXNlDQo+IGNhc2VzIGZvciB0aGUgRU9NIG1h cmtlciBpbnNpZGUgTkVUQ09ORiBtZXNzYWdlcyB0aGUgbWFya2VyIGlzIGdvb2QNCj4gZW5vdWdo LiBUaGUgcHJvYmxlbSBhcmUgbWlzdXNlIGNhc2VzLCBub3QgdXNlIGNhc2VzLg0KPiANCj4gPg0K PiA+IFdlJ3JlIGRpc2N1c3NpbmcgaG93IHRvIGJlc3QgZG9jdW1lbnQgdGhlIHNpdHVhdGlvbiB3 ZSBoYXZlIGNyZWF0ZWQuDQo+IA0KPiBZZXMsIEkgdW5kZXJzdGFuZCBhbmQgdHJpZWQgdG8gd29y ayBpbiB0aGF0IGRpcmVjdGlvbiwgdG9vLiBJIGp1c3QNCj4gY291bGRuJ3QgcmVzaXN0IGhlcmUu IDotKQ0KPiANCj4gTGFkYQ0KPiANCj4gPg0KPiA+IEJlcnQgKG5vdyBzcGVha2luZyBhcyBhIFdH IGNoYWlyKQ0KPiA+ID4gTGFkYQ0KPiA+ID4NCj4gPiA+PiBTbywgd2Ugd2FudCBiZSBjb3JyZWN0 L3ByZWNpc2UvaG9uZXN0IGluIGV4YWN0bHkgc3BlY2lmeWluZyBob3cNCj4gdGhlIHNlcXVlbmNl IGNhbg0KPiA+ID4+IHRoZW9yZXRpY2FsbHkgYW5kIGxlZ2FsbHkgYXBwZWFyIGluIGFuIFhNTCBk b2N1bWVudC4NCj4gPiA+PiBXZSB0aGVuIHdhbnQgdG8gc3RhdGUgdGhhdCB3ZSBiZWxpZXZlLCBi YXNlZCBvbiBvdXIgZXhwZXJpZW5jZSwNCj4gdGhhdCB0aGF0IHNlcXVlbmNlDQo+ID4gPj4gaXMg aW4gcHJhY3RpY2Ugbm90IHVzZWQvbmVlZGVkIGluIE5FVENPTkYsIGFuZCBzbyB0aGF0IHdlIHN0 aWxsDQo+IGJlbGlldmUgaXQgaXMgT0sNCj4gPiA+PiB0byB1c2UgdGhhdCBzZXF1ZW5jZSBhcyBF T00gbWFya2VyLCBubyBtYXR0ZXIgd2hlcmUgaW4gdGhlDQo+IHRyYW5zcG9ydCBzdHJlYW0gaXQN Cj4gPiA+PiBvY2N1cnMuDQo+ID4gPj4NCj4gPiA+PiBXZSBjb3VsZCBhZGQgYSBxdWVzdGlvbiB0 aGF0IGlmIGFueW9uZSBldmVyIHNlZXMgYSBuZWVkIHRvIHVzZSB0aGUNCj4gc2VxdWVuY2UgdGhh dA0KPiA+ID4+IHRoZXkgYmV0dGVyIGluZm9ybSB1cyAobmV0Y29uZiBXRykgYXNhcCB3aXRoIGEg Z29vZCBkZXNjcmlwdGlvbiBvZg0KPiB0aGUgc2NlbmFyaW8uDQo+ID4gPj4NCj4gPiA+PiBCZXJ0 DQo+ID4gPj4NCj4gPiA+PiBPbiAxMC8yMS8xMCA4OjUxIFBNLCBBbmR5IEJpZXJtYW4gd3JvdGU6 DQo+ID4gPj4+IEhpLA0KPiA+ID4+Pg0KPiA+ID4+PiBUaGUgb3JpZ2luYWwgaW50ZW50IHdhcyB0 byB1c2UgYSBjaGFyIHNlcXVlbmNlIHRoYXQgd2FzIG5vdCBsZWdhbA0KPiBpbg0KPiA+ID4+PiBh biBYTUwgaW5zdGFuY2UgZG9jdW1lbnQuICBOb2JvZHkgaW4gdGhlIFdHIGF0IHRoZSB0aW1lIGtu ZXcgZm9yDQo+IHN1cmUsDQo+ID4gPj4+IHNvIHdlIGFza2VkIHRoZSBYTUwgRGlyZWN0b3JhdGUu ICBXZSB3b3JrZWQgdW5kZXIgdGhlIGFzc3VtcHRpb24NCj4gdGhhdA0KPiA+ID4+PiB0aGUgXV0+ XV0+ICAgc2VxdWVuY2Ugd2FzIGEgc3VpdGFibGUgbWVzc2FnZSBib3VuZGFyeSBtYXJrZXIuDQo+ ID4gPj4+DQo+ID4gPj4+IEkgd291bGQgbGlrZSB0byBoZWFyIGV2aWRlbmNlIHRoYXQgdGhpcyBF T00gc2VxdWVuY2UgaXMgY2F1c2luZw0KPiBwcm9ibGVtcw0KPiA+ID4+PiBmb3Igb3BlcmF0b3Jz IHVzaW5nIE5FVENPTkYuICBJcyB0aGlzIHJlYWxseSBhIGNvbmNlcm4gdG8NCj4gb3BlcmF0b3Jz Pw0KPiA+ID4+PiBXb3VsZCBhIHNpZ25pZmljYW50IHByb3RvY29sIGNoYW5nZSB0byBhZGRyZXNz IHRoaXMgaXNzdWUgY2F1c2UNCj4gbW9yZQ0KPiA+ID4+PiBvcGVyYXRpb25hbCBwcm9ibGVtcyB0 aGFuIGl0IHNvbHZlcz8NCj4gPiA+Pj4NCj4gPiA+Pj4gSSBkbyBub3QgYWdyZWUgdGhhdCB0aGlz IG11c3QgYmUgZml4ZWQgaW4gTkVUQ09ORiAyLjAsIHdoZW5ldmVyDQo+IHRoYXQgaXMuDQo+ID4g Pj4+IFdlIHNob3VsZCBkZWNpZGUgYXQgdGhlIHRpbWUsIGFmdGVyIHNvbWUgbW9yZSBkZXBsb3lt ZW50DQo+IGV4cGVyaWVuY2UuDQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IEFuZHkNCj4gPiA+ Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4g RnJvbTogbmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnXQ0KPiBPbiBCZWhhbGYgT2YgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0K PiA+ID4+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMSwgMjAxMCAxMToyMSBBTQ0KPiA+ID4+ PiBUbzogZXh0IExhZGlzbGF2IExob3RrYQ0KPiA+ID4+PiBDYzogZXh0IE1hcmdhcmV0IFdhc3Nl cm1hbjsgTmV0Y29uZg0KPiA+ID4+PiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFN0YXR1cyBXR0xD IFJGQzQ3NDJiaXMgV0FTOkZXOiBzdGF0dXMgV0dMQw0KPiBSRkM0NzQxYmlzDQo+ID4gPj4+DQo+ ID4gPj4+IEhpIExhZGEsDQo+ID4gPj4+DQo+ID4gPj4+PiBIaSBNZWhtZXQsDQo+ID4gPj4+Pg0K PiA+ID4+Pj4gT24gxIx0LCAyMDEwLTEwLTIxIGF0IDE4OjQ5ICswMjAwLCBFcnN1ZSwgTWVobWV0 IChOU04gLQ0KPiBERS9NdW5pY2gpDQo+ID4gPj4+PiB3cm90ZToNCj4gPiA+Pj4+PiBIaSBMYWRh LA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gW3NwZWFraW5nIGFzIGEgY29udHJpYnV0b3JdDQo+ID4g Pj4+Pj4NCj4gPiA+Pj4+PiBpZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB5b3Ugd2FudCB0 byBhbGxvdyB0aGUgRU9NDQo+ID4gPj4+Pj4gbm90IG9ubHkgaW4gY29tbWVudHMgYnV0IGFsc28g aW4gWE1MIGF0dHJpYnV0ZXMgYW5kIFBJcy4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IEluIGNhc2Ug dGhlIGFuc3dlciBpcyBubzogSSBhcHBlYXIgdG8gbWlzdW5kZXJzdGFuZCB3aGF0DQo+ID4gPj4+ Pj4geW91IHdlcmUgc2F5aW5nLiBTbyBwbHMgZXhwbGFpbi4NCj4gPiA+Pj4+IEkgY2VydGFpbmx5 IGRvbid0IHdhbnQgdG8gYWxsb3cgYW55dGhpbmcgdGhhdCBpc24ndCBhbHJlYWR5DQo+IGFsbG93 ZWQuIDotDQo+ID4gPj4+PiApDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGhlIGN1cnJlbnQgdGV4dCBz YXlzLCBhcyBJIHVuZGVyc3RhbmQgaXQsIHRoYXQgWE1MDQo+IHNwZWNpZmljYXRpb24NCj4gPiA+ Pj4+IGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8gYXBwZWFyIG91dHNpZGUgY29tbWVu dHMgaW4gYW4NCj4gWE1MDQo+ID4gPj4+PiBkb2N1bWVudCAoYW5kIHRoZXJlZm9yZSBpdCBpcyBh IGdvb2QgY2hvaWNlKS4gQnV0IHRoaXMgaXMgbm90DQo+IHRydWU6IFhNTA0KPiA+ID4+Pj4gZG9j dW1lbnRzIGhhdmluZyB0aGUgc2VxdWVuY2UgaW4gUElzIGFuZCBhdHRyaWJ1dGUgdmFsdWVzIGFy ZQ0KPiA+ID4+Pj4gd2VsbC1mb3JtZWQgYXMgd2VsbC4gVGhlIG9ubHkgcGxhY2Ugd2hlcmUgdGhl IHNlcXVlbmNlIGlzIHJlYWxseQ0KPiA+ID4+Pj4gZm9yYmlkZGVuIGlzIGVsZW1lbnQgdGV4dC4N Cj4gPiA+Pj4gIlRoaXMgY2hhcmFjdGVyIHNlcXVlbmNlIGNhbm5vdCBsZWdhbGx5IGFwcGVhciBp biBhbiBYTUwNCj4gZG9jdW1lbnQsIHNvDQo+ID4gPj4+IGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5 IHVzZWQgdG8gaW5kZW50aWZ5IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQNCj4gPiA+Pj4gZG9jdW1l bnQgaW4gdGhlIGV2ZW50IG9mIGFuIFhNTCBzeW50YXggb3IgcGFyc2luZyBlcnJvciwgYWxsb3dp bmcNCj4gPiA+Pj4gcmVzeW5jaHJvbml6YXRpb24gb2YgdGhlIE5FVENPTkYgZXhjaGFuZ2UuIg0K PiA+ID4+Pg0KPiA+ID4+PiBUaGUgc2VudGVuY2UgaXMgYWN0dWFsbHkgc2luY2UgTWF5IDIwMDQg KHYwMSkgaW4gU1NIIGRvY3VtZW50DQo+ID4gPj4+IGFuZCBkaWQgbm90IGNoYW5nZSB1bnRpbCB0 b2RheS4gSSBkb24ndCBrbm93IGV4YWN0bHkgd2hhdCB0aGUNCj4gPiA+Pj4gYWltIG9mIHRoZSBh dXRob3JzIHdhcyB0byB3cml0ZSBpdCB0aGF0IHdheS4NCj4gPiA+Pj4NCj4gPiA+Pj4gT25lIG9w dGlvbiBpcyB0aGV5IHdhbnRlZCB0byBzdGF0ZSB0aGF0IHRoZSBFT00gIi4uLiBNVVNUIE5PVA0K PiA+ID4+PiBhcHBlYXIgb3V0c2lkZSBvZiBhIGNvbW1lbnQgaW4gYW4gWE1MIGRvY3VtZW50Iiwg d2hpY2ggd291bGQNCj4gPiA+Pj4gYmUgYSBjb25zaXN0ZW50IHJlc3RyaWN0aW9uLg0KPiA+ID4+ Pg0KPiA+ID4+PiBUaGUgb3RoZXIgb3B0aW9uIGlzIGhvdyB5b3UgdW5kZXJzdGFuZCBpdDoNCj4g PiA+Pj4gIlhNTCBzcGVjaWZpY2F0aW9uIGRvZXNuJ3QgYWxsb3cgdGhlIEVPTSBtYXJrZXIgdG8g YXBwZWFyDQo+ID4gPj4+IG91dHNpZGUgY29tbWVudHMiDQo+ID4gPj4+DQo+ID4gPj4+IC4uLndo aWNoIGlzIG9idmlvdXNseSBub3QgY29ycmVjdCBhbmQgY2FuIGJlIGFkZHJlc3NlZCBhcw0KPiA+ ID4+PiB5b3Ugc3VnZ2VzdC4gQnV0IHRoaXMgd291bGQgbWVhbiBhZGRpdGlvbmFsIGltcGxlbWVu dGF0aW9uDQo+ID4gPj4+IGVmZm9ydCBmb3IgU1NIIHRyYW5zcG9ydC4NCj4gPiA+Pj4NCj4gPiA+ Pj4gTWFyZ2FyZXQsIFRlZCwgQW5keToNCj4gPiA+Pj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3 aGF0IHRoZSBvcmlnaW5hbCBhaW0gd2FzPw0KPiA+ID4+Pg0KPiA+ID4+PiBXaGF0IGRvIG90aGVy cyBpbiB0aGUgV0cgdGhpbms/DQo+ID4gPj4+IFBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYmVm b3JlIEZyaWRheSBFT0IuDQo+ID4gPj4+DQo+ID4gPj4+IE1laG1ldA0KPiA+ID4+Pg0KPiA+ID4+ Pj4gTGFkYQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiBJbiBjYXNlIHRoZSBhbnN3ZXIgaXMgeWVzOg0K PiA+ID4+Pj4+DQo+ID4gPj4+Pj4gVGhlb3JldGljYWxseSB0aGUgRU9NIHNlcXVlbmNlIGNhbiBh cHBlYXIgZXZlcnl3aGVyZSBpbg0KPiA+ID4+Pj4+IGFuIFhNTCBkb2N1bWVudC4NCj4gPiA+Pj4+ Pg0KPiA+ID4+Pj4+IEhvd2V2ZXIsIHRoZSB0cmFuc3BvcnQgbGF5ZXIgc2hvdWxkbid0IGRvIGZp bmUgZ3JhaW5lZA0KPiA+ID4+Pj4+IHBhcnNpbmcgb2YgdGhlIFhNTCBkb2N1bWVudCwgdG8gZmlu ZCBvdXQgd2hlcmUgdGhlDQo+ID4gPj4+Pj4gYXR0cmlidXRlcyBvciBQSXMgYXJlLg0KPiA+ID4+ Pj4+IFRoaXMgaXMgdGhlIHJlYXNvbiB3aHkgNDc0MiBrZXB0IGl0IHNpbXBsZSBhbmQsIGFzIEkN Cj4gPiA+Pj4+PiB0aGluaywgYXBwcm9wcmlhdGUgZm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJIGRvbid0IHNlZSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIFhN TCBlbGVtZW50cyBhbmQNCj4gPiA+Pj4+PiBbYXR0cmlidXRlcyBvciBQSV0uIFRoZXkgYWxsIGFy ZSBYTUwgZGF0YS4gQW5kIEVPTSBjYW4NCj4gPiA+Pj4+PiBhcHBlYXIgaW4gWE1MIGRhdGEgb3Ig YXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQuDQo+ID4gPj4+Pj4gSWYgc29tZWJvZHkgd2FudHMg dG8gZGlzcnVwdCB0aGUgcnBjIGNvbW1hbmQgaGUgY2FuDQo+ID4gPj4+Pj4gZG8gaXQgbm8gbWF0 dGVyIGluIGVsZW1lbnRzIG9yIGF0dHJpYnV0ZXMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBTbywg YXQgdGhlIGVuZCBJIGRvbid0IHNlZSBhbnkgYmVuZWZpdCBpbiByZWR1Y2luZyB0aGUNCj4gPiA+ Pj4+PiByZXN0cmljdGlvbiBhbmQgdGhpbms6DQo+ID4gPj4+Pj4gVG8gYmUgb24gdGhlIHNhZmUg c2lkZSBhbmQgdG8ga2VlcCBpdCBzaW1wbGUgZm9yIHRoZQ0KPiA+ID4+Pj4+IGltcGxlbWVudGVy IG9mIDQ3NDJiaXMgdGhlIHNlcXVlbmNlIG11c3Qgbm90IGFwcGVhcg0KPiA+ID4+Pj4+IGluIHRo ZSBYTUwgZG9jdW1lbnQgKGV4Y2VwdCBvdXRzaWRlIG9mIGNvbW1lbnRzKS4NCj4gPiA+Pj4+Pg0K PiA+ID4+Pj4+IFtub3cgdGhlIGNoYWlyIGhhdCBvbl06DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBQ bGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0aGUgbWFuZGF0ZQ0KPiA+ID4+ Pj4+IGZvciB2Mi4wLiBXZSBhcmUganVzdCBkb2luZyBidWctZml4aW5nLg0KPiA+ID4+Pj4+DQo+ ID4gPj4+Pj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHYyLjAgc2hvdWxkIHNvbHZlIHRoaXMgaXNz dWUNCj4gPiA+Pj4+PiB3aXRoIGEgdGhvcm91Z2ggc29sdXRpb24uIFdvdWxkIHlvdSBsaWtlIHRv IHByZXBhcmUNCj4gPiA+Pj4+PiBhIGZldyBzbGlkZXMgZm9yIHRoZSBORVRDT05GIHNlc3Npb24g aW4gQmVpamluZyBmb3INCj4gPiA+Pj4+PiBhIHNvbHV0aW9uLCB3aGljaCBjb3VsZCBiZSBwdXQg bGF0ZXIgaW50byB2Mi4wPw0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gQ2hlZXJzLA0KPiA+ID4+Pj4+ IE1laG1ldA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+Pj4+Pj4gRnJvbTogZXh0IExhZGlzbGF2IExob3RrYSBbbWFpbHRv Omxob3RrYUBjZXNuZXQuY3pdDQo+ID4gPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAy MCwgMjAxMCA3OjIzIFBNDQo+ID4gPj4+Pj4+IFRvOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9N dW5pY2gpDQo+ID4gPj4+Pj4+IENjOiBOZXRjb25mOyBleHQgTWFyZ2FyZXQgV2Fzc2VybWFuDQo+ ID4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gU3RhdHVzIFdHTEMgUkZDNDc0MmJpcyBX QVM6Rlc6IHN0YXR1cw0KPiBXR0xDDQo+ID4gPj4+Pj4+IFJGQzQ3NDFiaXMNCj4gPiA+Pj4+Pj4N Cj4gPiA+Pj4+Pj4gT24gU3QsIDIwMTAtMTAtMjAgYXQgMTg6MjcgKzAyMDAsIEVyc3VlLCBNZWht ZXQgKE5TTiAtDQo+IERFL011bmljaCkNCj4gPiA+Pj4+Pj4gd3JvdGU6DQo+ID4gPj4+Pj4+PiBI aSBBbGwsDQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4gc2FtZSBpcyB3aXRoIDQ3NDJiaXMgV0dM QyBkaXNjdXNpb24uIFdlIGhhZCBvbmx5IG1pbm9yDQo+ID4gPj4+Pj4+PiBjaGFuZ2VzIGFmdGVy IElFVEYgNzguIE91ciBpbXByZXNzaW9uIGlzIHRoYXQgd2UgaGF2ZQ0KPiA+ID4+Pj4+Pj4gY29u c2Vuc3VzIHRvIHNlZSB0aGUgZHJhZnQgYXMgZmluYWwuDQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+ Pj4gTWFyZ2FyZXQgc3VibWl0dGVkIHRoZSBkcmFmdCB0b2RheSBtYWtpbmcgaXQgcmVhZHkgZm9y DQo+ID4gPj4+Pj4+PiBBRCByZXZpZXcuIFBsZWFzZSBjaGVjayB0aGUgY2hhbmdlcyBieSAxMC8y MiBzbyB0aGF0DQo+ID4gPj4+Pj4+PiB3ZSBoYXZlIGEgY2hhbmNlIHRvIHJlLXN1Ym1pdCBiZWZv cmUgZGVhZGxpbmUuIFRoYW5rcy4NCj4gPiA+Pj4+Pj4gVGhlIGp1c3RpZmljYXRpb24gZm9yIHRo ZSBFT00gbWFya2VyIGluIHNlYy4gMy4xIGlzDQo+IHRlY2huaWNhbGx5DQo+ID4gPj4+Pj4+IGlu Y29ycmVjdCAtIGFuZCBJIG9iamVjdGVkIGFnYWluc3QgaXQgcHJldmlvdXNseToNCj4gPiA+Pj4+ Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJl bnQvbXNnMDYyNzcuaHRtbA0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBIZXJlIGlzIHRoZSBjaGFu Z2UgSSBwcm9wb3NlICh0aGVyZSdzIGFsc28gYSB0eXBvIGluDQo+ID4gPj4+PiAidW5hbWJpZ3Vv dXNseSIpOg0KPiA+ID4+Pj4+PiBPTEQNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gVGhpcyBjaGFy YWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUgb2YgYQ0KPiBjb21t ZW50DQo+ID4gPj4+PiBpbg0KPiA+ID4+Pj4+PiBhbg0KPiA+ID4+Pj4+PiBYTUwgZG9jdW1lbnQs IHNvIGl0IGNhbiBiZSB1bmFtYmlnaW91c2x5IHVzZWQgdG8gaWRlbnRpZnkgdGhlDQo+IGVuZA0K PiA+ID4+Pj4gb2YNCj4gPiA+Pj4+Pj4gdGhlDQo+ID4gPj4+Pj4+IGN1cnJlbnQgZG9jdW1lbnQs IGFsbG93aW5nIHJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBORVRDT05GDQo+ID4gPj4+PiBleGNo YW5nZSBpbg0KPiA+ID4+Pj4+PiB0aGUgZXZlbnQgb2YgYW4gWE1MIHN5bnRheCBvciBwYXJzaW5n IGVycm9yLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBORVcNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+ Pj4gVGhpcyBjaGFyYWN0ZXIgc2VxdWVuY2UgY2Fubm90IGxlZ2FsbHkgYXBwZWFyIG91dHNpZGUg b2YgYQ0KPiBjb21tZW50LA0KPiA+ID4+Pj4+PiBwcm9jZXNzaW5nIGluc3RydWN0aW9uIGFuZCBh dHRyaWJ1dGUgdmFsdWUgaW4gYW4gWE1MIGRvY3VtZW50LA0KPiBzbw0KPiA+ID4+Pj4gaXQNCj4g PiA+Pj4+Pj4gY2FuDQo+ID4gPj4+Pj4+IGJlIHVuYW1iaWd1b3VzbHkgdXNlZCB0byBpZGVudGlm eSB0aGUgZW5kIG9mIHRoZSBjdXJyZW50DQo+IGRvY3VtZW50LA0KPiA+ID4+Pj4+PiBhbGxvd2lu ZyByZXN5bmNocm9uaXphdGlvbiBvZiB0aGUgTkVUQ09ORiBleGNoYW5nZSBpbiB0aGUNCj4gZXZl bnQgb2YNCj4gPiA+Pj4+IGFuDQo+ID4gPj4+Pj4+IFhNTCBzeW50YXggb3IgcGFyc2luZyBlcnJv ci4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gTGFkYQ0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+Pj4g Q2hlZXJzLA0KPiA+ID4+Pj4+Pj4gTWVobWV0DQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4NCj4g PiA+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4+Pj4+PiBGcm9tOiBu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRjb25mLQ0KPiBib3VuY2VzQGlldGYu b3JnXQ0KPiA+ID4+Pj4gT24NCj4gPiA+Pj4+Pj4+IEJlaGFsZiBPZiBleHQgQmVydCBXaWpuZW4g KElFVEYpDQo+ID4gPj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMTAgMzo1 MiBQTQ0KPiA+ID4+Pj4+Pj4gVG86IE5ldGNvbmYNCj4gPiA+Pj4+Pj4+IFN1YmplY3Q6IFtOZXRj b25mXSBzdGF0dXMgV0dMQyBSRkM0NzQxYmlzDQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4gSXQg c2VlbXMgdGhhdCB0aGUgV0dMQyBkaXNjdXNzaW9uIGhhcyBub3cgZGllZCBvdXQgb24gdGhlDQo+ IG1haWxpbmcNCj4gPiA+Pj4+Pj4gbGlzdC4NCj4gPiA+Pj4+Pj4+ICAgIEZyb20gcmUtcmVhZGlu ZyBhbGwgdGhvc2UgY29tbWVudHMsIEkgYWxzbyBnZXQgdGhlDQo+IGltcHJlc3Npb24NCj4gPiA+ Pj4+IHRoYXQNCj4gPiA+Pj4+Pj4+IHRoZXJlIGlzIGNvbnNlbnN1cy9hZ3JlZW1lbnQgb24gdGhl IGNoYW5nZXMgdGhhdCBuZWVkIHRvIGJlDQo+ID4gPj4+Pj4+IGFkZHJlc3NlZC4NCj4gPiA+Pj4+ Pj4+IFRoZSBlZGl0b3JzIChzcGVjaWZpY2FsbHkgTWFydGluKSBpcyBwcmVwYXJpbmcgYSBuZXcg cmV2aXNpb24NCj4gPiA+Pj4+IGJhc2VkDQo+ID4gPj4+Pj4+PiBvbiB0aGUgcmVzdWx0IG9mIHRo ZSBkaXNjdXNzaW9ucy4gV2lsbCBwcm9iYWJseSBzaG93IHVwIGxhdGVyDQo+ID4gPj4+PiB0b2Rh eS4NCj4gPiA+Pj4+Pj4+IE91ciBwbGFuIGFzIFdHLWNoYWlycyBpcyB0byBhbGxvdyB0aGUgV0cg YSBmZXcgZGF5cyB0bw0KPiBxdWlja2x5DQo+ID4gPj4+PiBjaGVjaw0KPiA+ID4+Pj4+Pj4gaWYg dGhlIGNoYW5nZXMgYXJlIE9LLiBUaGVuIGFzayBvdXIgQWQgdG8gYnJpbmcgaXQgZm9yd2FyZCB0 bw0KPiA+ID4+Pj4gSUVURg0KPiA+ID4+Pj4+Pj4gTGFzdCBDYWxsIGFuZCBJRVNHIHJldmlldy4N Cj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBUaGFua3MsDQo+ID4gPj4+Pj4+PiBCZXJ0IGFuZCBN ZWhtZXQNCj4gPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPj4+Pj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4+Pj4g TmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mDQo+ID4gPj4+Pj4+PiBlLW1haWwgbWVzc2FnZSBhdHRhY2htZW50 DQo+ID4gPj4+Pj4+Pj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPiA+ Pj4+Pj4+PiBGcm9tOiBJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4+PiBSZXBs eS10bzo8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+ID4+Pj4+Pj4+IFRvOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4+PiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4+ Pj4+Pj4+IFN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzQ3NDJiaXMt MDMudHh0DQo+ID4gPj4+Pj4+Pj4gRGF0ZTogV2VkLCAyMCBPY3QgMjAxMCAxNzowMDowMiArMDIw MA0KPiA+ID4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtDQo+ID4gPj4+PiBEcmFmdHMNCj4gPiA+ Pj4+Pj4gZGlyZWN0b3JpZXMuDQo+ID4gPj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uDQo+IFdvcmtpbmcNCj4gPiA+Pj4+Pj4gR3Jv dXAgb2YgdGhlIElFVEYuDQo+ID4gPj4+Pj4+Pj4gICAgICBUaXRsZSAgICAgICAgICAgOiBVc2lu ZyB0aGUgTkVUQ09ORiBDb25maWd1cmF0aW9uDQo+IFByb3RvY29sDQo+ID4gPj4+PiBvdmVyDQo+ ID4gPj4+Pj4+IFNlY3VyZSBTaGVsbCAoU1NIKQ0KPiA+ID4+Pj4+Pj4+ICAgICAgQXV0aG9yKHMp ICAgICAgIDogTS4gV2Fzc2VybWFuLCBULiBHb2RkYXJkDQo+ID4gPj4+Pj4+Pj4gICAgICBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNDc0MmJpcy0wMy50eHQNCj4gPiA+ Pj4+Pj4+PiAgICAgIFBhZ2VzICAgICAgICAgICA6IDEwDQo+ID4gPj4+Pj4+Pj4gICAgICBEYXRl ICAgICAgICAgICAgOiAyMDEwLTEwLTIwDQo+ID4gPj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgaW52b2tpbmcgYW5kIHJ1bm5pbmcNCj4g dGhlDQo+ID4gPj4+Pj4+IE5FVENPTkYNCj4gPiA+Pj4+Pj4+PiBwcm90b2NvbCB3aXRoaW4gYSBT ZWN1cmUgU2hlbGwgKFNTSCkgc2Vzc2lvbiBhcyBhbiBTU0gNCj4gPiA+Pj4+IHN1YnN5c3RlbS4N Cj4gPiA+Pj4+Pj4+PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gPiA+Pj4+ Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNv bmYtDQo+ID4gPj4+PiByZmM0NzQyYmlzLQ0KPiA+ID4+Pj4+PiAwMy50eHQNCj4gPiA+Pj4+Pj4+ PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+ID4gPj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiA+ Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxl IGEgTUlNRSBjb21wbGlhbnQgbWFpbA0KPiA+ID4+Pj4gcmVhZGVyDQo+ID4gPj4+Pj4+Pj4gaW1w bGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbg0K PiBvZg0KPiA+ID4+Pj4gdGhlDQo+ID4gPj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnQuDQo+ID4gPj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4+Pj4+Pj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+Pj4+IE5ldGNvbmZAaWV0Zi5v cmcNCj4gPiA+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZg0KPiA+ID4+Pj4+PiAtLQ0KPiA+ID4+Pj4+PiBMYWRpc2xhdiBMaG90a2EsIENFU05FVA0K PiA+ID4+Pj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiA+ID4+Pj4gLS0NCj4gPiA+Pj4+IExh ZGlzbGF2IExob3RrYSwgQ0VTTkVUDQo+ID4gPj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiA+ ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4g Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+ PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4gPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+DQo+IA0K PiAtLQ0KPiBMYWRpc2xhdiBMaG90a2EsIENFU05FVA0KPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0K DQo= From mehmet.ersue@nsn.com Sun Oct 24 10:34:50 2010 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 674253A691B for ; Sun, 24 Oct 2010 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 EcNZuhhSp-TP for ; Sun, 24 Oct 2010 10:34:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D60603A68DB for ; Sun, 24 Oct 2010 10:34:48 -0700 (PDT) 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 o9OHaO0c022532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Oct 2010 19:36:24 +0200 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 o9OHaOhJ030761; Sun, 24 Oct 2010 19:36:24 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.19]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 19:36:24 +0200 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: Sun, 24 Oct 2010 19:36:20 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E5AE0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of 4742bis before deadline WAS:Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis thread-index: Actzofha0vFX1G2CQ9y7k/MDplmGAw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Margaret Wasserman" , "Netconf" X-OriginalArrivalTime: 24 Oct 2010 17:36:24.0373 (UTC) FILETIME=[FABBC650:01CB73A1] Subject: [Netconf] Update of 4742bis before deadline WAS:Re: Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 24 Oct 2010 17:34:50 -0000 Hi Margaret, All, the result of the discussion showed that there is consensus on the=20 last proposed text for this issue (below). With this we will update=20 4742bis before deadline. Margaret: Can you please update 4742bis with the text below?=20 Thanks. Mehmet OLD: "This character sequence cannot legally appear outside of a comment in an XML document, so it can be unambigiously used to identify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error." NEW: "This character sequence MUST NOT appear in an XML document." NEW in Security Considerations section: "RFC 4742 assumes that the EOM sequence cannot appear in any XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in an XML document. It is however believed that the associated threat is not very high. This document keeps using the EOM sequence to avoid incompatibility with existing implementations. Implementations of SSH transport must exercise=20 extra care and make sure the EOM sequence is not present in an XML=20 document." > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, October 22, 2010 6:21 PM > To: ext Phil Shafer; Juergen Schoenwaelder > Cc: Andy Bierman; ext Margaret Wasserman; Netconf > Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > RFC4741bis >=20 > Hi Phil, All, >=20 > ::>> NEW: > ::>> "This character sequence MUST NOT appear in an XML document." >=20 > > >Works for me. > > > > This is a change to the NETCONF protocol, since it makes a previously > > legal character sequence illegal. If we're willing to change > > NETCONF, why not just repair the SSH transport mapping, where the > > problem really exists. > > > > But if the WG really is following the "it's not a bug" line, then > > I suggest: > > > > (a) The draft should include an explanation of why this is illegal, > > with the history, etc. > > > > (b) The draft should include a description of the means to avoid > > this sequence (amper escaping) and a list of places where that > > escaping is not possible (processing instructions). > > > > That is, the draft should give all the details as we know them so > > an implementor can understand and properly address the issues. > > > > Me, I think it's a bug. A minor one, sure, but at least on par with > > the other issues addressed with netconf-1.1. >=20 > Yes, it is a bug. We found out it can only be addressed "thoroughly" > in v2.0. We are now trying to fix the mistaken text in v1.0 of 4742bis. >=20 > SSH v1.0 is specified to recognize end of document with this character > sequence. As we all were thinking, the character sequence cannot appear > in an XML document, I don't think it is a change for the NETCONF > protocol > (this BTW was the case since May 2004, see v01 of SSH draft which > leaded >=20 > to 4742). >=20 > If you think "MUST NOT" is too strict I can go also with "SHOULD NOT". > OTOH, if we know already it is bad, why not "MUST"? >=20 > The explanation text you are proposing should go into the security > considerations section of 4742bis, e.g.: >=20 > NEW: >=20 > :: "RFC 4742 assumes that the EOM sequence cannot appear in any XML > document, > :: which turned out to be mistaken. The EOM sequence can cause > operational > :: problems and open space for attacks if sent deliberately in an XML > document. > :: It is however believed that the associated threat is not very high. > This > :: document keeps using the EOM sequence to avoid incompatibility with > :: existing clients. > :: Implementations of SSH transport must exercise extra care and make > sure > :: the EOM sequence is not present in an XML document." >=20 > All: > : Knowing that this is only a (limited) bug fixing for v1.0, can we go > : with the proposed two NEW text blocks in 4742bis? >=20 > We need a decision kind of soon to resubmit before deadline. Thank you. >=20 > Mehmet >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From root@core3.amsl.com Mon Oct 25 13:00:04 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 20D683A6AF3; Mon, 25 Oct 2010 13:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025200004.20D683A6AF3@core3.amsl.com> Date: Mon, 25 Oct 2010 13:00:03 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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, 25 Oct 2010 20:00: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-06.txt Pages : 121 Date : 2010-10-25 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-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-4741bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25125428.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 13:30:12 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F15B73A6B61; Mon, 25 Oct 2010 13:30:11 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025203011.F15B73A6B61@core3.amsl.com> Date: Mon, 25 Oct 2010 13:30:11 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-access-control-01.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, 25 Oct 2010 20:30:12 -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 Access Control Model Author(s) : A. Bierman, M. Bjorklund Filename : draft-ietf-netconf-access-control-01.txt Pages : 62 Date : 2010-10-25 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment, which promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content. This document discusses requirements for a suitable access control model, and provides one solution which meets these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-01.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-access-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25132737.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Mon Oct 25 13:53:27 2010 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 E09103A6893 for ; Mon, 25 Oct 2010 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.021 X-Spam-Level: X-Spam-Status: No, score=-100.021 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 urlVeFRQoLGJ for ; Mon, 25 Oct 2010 13:53:27 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id D96843A6407 for ; Mon, 25 Oct 2010 13:53:25 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PAU4U-0007ie-Jb for netconf@ietf.org; Mon, 25 Oct 2010 22:55:10 +0200 Message-ID: <1175499ED8E74E969625B2FCF6D0F53E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" References: <64A0B7E0557141968E99BCC4331E9C11@BertLaptop> In-Reply-To: <64A0B7E0557141968E99BCC4331E9C11@BertLaptop> Date: Mon, 25 Oct 2010 22:54:26 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: [Netconf] RFC4741bis will now go to our AD. 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, 25 Oct 2010 20:53:28 -0000 I am preparing the write-up and will send it to our AD in a day or so. The new revision 6 that came out today has some additional text in the secuirty considerations section as follows: > This section provides security considerations for the base > NETCONF message layer and the base operations of the NETCONF > protocol. Security considerations for the NETCONF transports > are provided in the transport documents and security > considerations for the content manipulated by NETCONF can be > found in the document defining data models. > The Wg did have agreement on that in our reading. Bert and Mehmet. ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Netconf" Sent: Wednesday, October 20, 2010 3:52 PM Subject: [Netconf] status WGLC RFC4741bis It seems that the WGLC discussion has now died out on the mailing list. >From re-reading all those comments, I also get the impression that there is consensus/agreement on the changes that need to be addressed. The editors (specifically Martin) is preparing a new revision based on the result of the discussions. Will probably show up later today. Our plan as WG-chairs is to allow the WG a few days to quickly check if the changes are OK. Then ask our Ad to bring it forward to IETF Last Call and IESG review. Thanks, Bert and Mehmet From bertietf@bwijnen.net Mon Oct 25 13:53:27 2010 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 E0ABC3A689F for ; Mon, 25 Oct 2010 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.974 X-Spam-Level: X-Spam-Status: No, score=-99.974 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 CLWmF87Iqdju for ; Mon, 25 Oct 2010 13:53:27 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id D96EE3A67B3 for ; Mon, 25 Oct 2010 13:53:25 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PAU4U-0007ie-9a for netconf@ietf.org; Mon, 25 Oct 2010 22:55:10 +0200 Message-ID: <3F2C09581DE34095A22CC934F14D4E50@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Mon, 25 Oct 2010 22:47:09 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: [Netconf] Pls read in preparation for IETF meeting: I-D Action:draft-ietf-netconf-access-control-01.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, 25 Oct 2010 20:53:28 -0000 WG participants, You have nearly 2 weeks to read and prepare. Please do so, so that we can have a productive meeting. Bert and Mehmet ----- Original Message ----- From: To: Cc: Sent: Monday, October 25, 2010 10:30 PM Subject: [Netconf] I-D Action:draft-ietf-netconf-access-control-01.txt 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 Access Control Model Author(s) : A. Bierman, M. Bjorklund Filename : draft-ietf-netconf-access-control-01.txt Pages : 62 Date : 2010-10-25 From margaretw42@gmail.com Mon Oct 25 13:50:16 2010 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 CE0733A68D3 for ; Mon, 25 Oct 2010 13:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 2ehO9hfAcDHx for ; Mon, 25 Oct 2010 13:50:14 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BD89B3A6407 for ; Mon, 25 Oct 2010 13:50:10 -0700 (PDT) Received: by qyk5 with SMTP id 5so1942478qyk.10 for ; Mon, 25 Oct 2010 13:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=X97MMCP33xJzF/gu5ZTGMXknQuQNyWH9Oa00UvaK5TE=; b=mjUmn2EvoDgvt5EURZI1Eo8uFY8cujle5K3c3UyGO5RGKjf+kJmme1PpIHkgDOpQ83 26uJF1tA0CGkgouOMlc9TLEf+R4rM/u8nZYDSSQz1xJArbQ5TNHTsB/hznVSHzEa570s syzMr7/0cvtWrilC3acgvOtIt6pHoyy27Yg2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=pJYcP3cfjCSA9uV8QIPa6CAcOGzcvGOumMPY9tvigvOX90c1YIWm2gnk9NA3WaJrbl x7WHzhAuqpAKGOH8et+mz+Ec4KitJy7Kj3rlMq/SiD7/OzYWpRQAnVRqf4Yx6NShochQ VOK+tvCSYyQVzI0g2ubOIeRg33QsIUkivnGV4= Received: by 10.229.99.131 with SMTP id u3mr6944201qcn.17.1288039914942; Mon, 25 Oct 2010 13:51:54 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id n7sm6470408qcu.4.2010.10.25.13.51.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 13:51:54 -0700 (PDT) Message-Id: From: Margaret Wasserman To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011E5AE0@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Oct 2010 16:51:53 -0400 References: <80A0822C5E9A4440A5117C2F4CD36A64011E5AE0@DEMUEXC006.nsn-intra.net> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 25 Oct 2010 13:54:19 -0700 Cc: Netconf Subject: Re: [Netconf] Update of 4742bis before deadline WAS:Re: Status WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis 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, 25 Oct 2010 20:50:17 -0000 Hi Mehmet, This update has been done, and the -04 version of the draft has been posted. Thanks, Margaret On Oct 24, 2010, at 1:36 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Margaret, All, > > the result of the discussion showed that there is consensus on the > last proposed text for this issue (below). With this we will update > 4742bis before deadline. > > Margaret: Can you please update 4742bis with the text below? > Thanks. > > Mehmet > > > OLD: > "This character sequence cannot legally appear outside of a comment > in an > XML document, so it can be unambigiously used to identify the end of > the current document, allowing resynchronization of the NETCONF > exchange in the event of an XML syntax or parsing error." > > NEW: > "This character sequence MUST NOT appear in an XML document." > > > NEW in Security Considerations section: > "RFC 4742 assumes that the EOM sequence cannot appear in any XML > document, which turned out to be mistaken. The EOM sequence can > cause > operational problems and open space for attacks if sent deliberately > in an XML > document. It is however believed that the associated threat is not > very high. > This document keeps using the EOM sequence to avoid incompatibility > with > existing implementations. Implementations of SSH transport must > exercise > extra care and make sure the EOM sequence is not present in an XML > document." > > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) >> Sent: Friday, October 22, 2010 6:21 PM >> To: ext Phil Shafer; Juergen Schoenwaelder >> Cc: Andy Bierman; ext Margaret Wasserman; Netconf >> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC >> RFC4741bis >> >> Hi Phil, All, >> >> ::>> NEW: >> ::>> "This character sequence MUST NOT appear in an XML document." >> >>>> Works for me. >>> >>> This is a change to the NETCONF protocol, since it makes a > previously >>> legal character sequence illegal. If we're willing to change >>> NETCONF, why not just repair the SSH transport mapping, where the >>> problem really exists. >>> >>> But if the WG really is following the "it's not a bug" line, then >>> I suggest: >>> >>> (a) The draft should include an explanation of why this is illegal, >>> with the history, etc. >>> >>> (b) The draft should include a description of the means to avoid >>> this sequence (amper escaping) and a list of places where that >>> escaping is not possible (processing instructions). >>> >>> That is, the draft should give all the details as we know them so >>> an implementor can understand and properly address the issues. >>> >>> Me, I think it's a bug. A minor one, sure, but at least on par with >>> the other issues addressed with netconf-1.1. >> >> Yes, it is a bug. We found out it can only be addressed "thoroughly" >> in v2.0. We are now trying to fix the mistaken text in v1.0 of > 4742bis. >> >> SSH v1.0 is specified to recognize end of document with this >> character >> sequence. As we all were thinking, the character sequence cannot > appear >> in an XML document, I don't think it is a change for the NETCONF >> protocol >> (this BTW was the case since May 2004, see v01 of SSH draft which >> leaded >> >> to 4742). >> >> If you think "MUST NOT" is too strict I can go also with "SHOULD >> NOT". >> OTOH, if we know already it is bad, why not "MUST"? >> >> The explanation text you are proposing should go into the security >> considerations section of 4742bis, e.g.: >> >> NEW: >> >> :: "RFC 4742 assumes that the EOM sequence cannot appear in any XML >> document, >> :: which turned out to be mistaken. The EOM sequence can cause >> operational >> :: problems and open space for attacks if sent deliberately in an XML >> document. >> :: It is however believed that the associated threat is not very >> high. >> This >> :: document keeps using the EOM sequence to avoid incompatibility >> with >> :: existing clients. >> :: Implementations of SSH transport must exercise extra care and make >> sure >> :: the EOM sequence is not present in an XML document." >> >> All: >> : Knowing that this is only a (limited) bug fixing for v1.0, can we >> go >> : with the proposed two NEW text blocks in 4742bis? >> >> We need a decision kind of soon to resubmit before deadline. Thank > you. >> >> Mehmet >> >> >> _______________________________________________ >> 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 root@core3.amsl.com Mon Oct 25 14:00:02 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F3ECB3A6BDE; Mon, 25 Oct 2010 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025210001.F3ECB3A6BDE@core3.amsl.com> Date: Mon, 25 Oct 2010 14:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-04.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, 25 Oct 2010 21:00:02 -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-04.txt Pages : 11 Date : 2010-10-25 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25134810.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Mon Oct 25 22:03:54 2010 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 4047C3A67BE for ; Mon, 25 Oct 2010 22:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 OYfyeSjx+eZ3 for ; Mon, 25 Oct 2010 22:03:53 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 223043A67E2 for ; Mon, 25 Oct 2010 22:03:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=M1RYh96Urtbvzbh9flxaVPkBJdV6LLuHRUBZe9Rj+pWPzRvg6iBmI2CwnPhHfwt9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.145.181] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAbj9-0005Hy-Au for netconf@ietf.org; Tue, 26 Oct 2010 01:05:39 -0400 Message-ID: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf" References: Date: Mon, 25 Oct 2010 22:07:46 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe07aaa02428d132fae22ad3f7d3f8e3ca350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.181 Subject: Re: [Netconf] NACM draft 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, 26 Oct 2010 05:03:54 -0000 Hi - > From: "Andy Bierman" > To: "Netconf" > Sent: Wednesday, October 20, 2010 9:08 AM > Subject: [Netconf] NACM draft ... > There have not been any comments on this draft: > http://www.ietf.org/id/draft-ietf-netconf-access-control-00.txt > > Juergen made a comment that the authentication objects should be removed. > Nobody else commented on that, and so they were not removed from -00. FWIW, I agree with Juergen that the "authentication objects" should be removed. In particular, if RADIUS is required to provide "group" mappings, then the material on user/group mappings can be greatly simplified, as well as the "superuser" stuff, which reduces to an all-powerful, potentially pre-installed group, much like the appendix material in VACM). It should also spell out what happens when RADIUS fails to provide a group mapping, but has authenticated the user. I think any references to RADIUS should clearly identify the RADIUS attributes involved. If there is any possibility that this MAY be used with DIAMETER, that should be spelled out, too. Randy From mbj@tail-f.com Tue Oct 26 00:37:05 2010 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 5E6473A689F for ; Tue, 26 Oct 2010 00:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.120, 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 9LM+MGGaounw for ; Tue, 26 Oct 2010 00:37:02 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 589043A68CF for ; Tue, 26 Oct 2010 00:37:01 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C62E616004; Tue, 26 Oct 2010 09:38:47 +0200 (CEST) Date: Tue, 26 Oct 2010 09:38:46 +0200 (CEST) Message-Id: <20101026.093846.100862283.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> References: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> 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] NACM draft 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, 26 Oct 2010 07:37:05 -0000 Hi, "Randy Presuhn" wrote: > Hi - > > > From: "Andy Bierman" > > To: "Netconf" > > Sent: Wednesday, October 20, 2010 9:08 AM > > Subject: [Netconf] NACM draft > ... > > There have not been any comments on this draft: > > http://www.ietf.org/id/draft-ietf-netconf-access-control-00.txt > > > > Juergen made a comment that the authentication objects should be removed. > > Nobody else commented on that, and so they were not removed from -00. > > FWIW, I agree with Juergen that the "authentication objects" should be removed. Do you think authentication should be split into a separate document, or do you think that the solution should not cover authentication at all? Why? It seems the term "access control" means different things to different people. Some people thinks it is just authorization, some think it is authentication + authorization, and some even include audit (e.g. http://en.wikipedia.org/wiki/Access_control#Computer_security) Personally, I think we need both authentication and authorization. If it is done in one or two documents is not very important, although I perfer one document at this stage. > In particular, if RADIUS is required to provide "group" mappings Currently RADIUS support is not required, and if RADIUS is supported, it is not required to support the "group" mapping. > , then the > material on user/group mappings can be greatly simplified, as well as the > "superuser" stuff, which reduces to an all-powerful, potentially pre-installed > group, much like the appendix material in VACM). It should also spell out > what happens when RADIUS fails to provide a group mapping, but has > authenticated the user. Ok. The idea is that group names are accumulative, i.e. the list of local groups are added to the result from RADIUS. > I think any references to RADIUS should clearly identify the RADIUS attributes > involved. Don't you think that the currect draft does that? > If there is any possibility that this MAY be used with DIAMETER, > that > should be spelled out, too. Ok. /martin From mehmet.ersue@nsn.com Tue Oct 26 03:21:26 2010 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 7F8583A67AC for ; Tue, 26 Oct 2010 03:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 k5bclwKovksg for ; Tue, 26 Oct 2010 03:21:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5C31F3A6939 for ; Tue, 26 Oct 2010 03:21:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9QANAEe030166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Oct 2010 12:23:10 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9QAN7Gw015281 for ; Tue, 26 Oct 2010 12:23:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 12:23:07 +0200 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: Tue, 26 Oct 2010 12:23:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401232119@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011B6AC0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft agenda for NETCONF session in Beijing Thread-Index: ActwWs6YRe4rKHRpQuaC8q/7sxR6DQEnMAmw References: <80A0822C5E9A4440A5117C2F4CD36A64011B6AC0@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 26 Oct 2010 10:23:07.0829 (UTC) FILETIME=[C8697650:01CB74F7] Subject: Re: [Netconf] Draft agenda for NETCONF session in Beijing 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, 26 Oct 2010 10:21:26 -0000 Hi All, please find below the updated session agenda: http://www.ietf.org/proceedings/79/agenda/netconf.txt=20 Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Wednesday, October 20, 2010 3:29 PM > To: Netconf > Subject: [Netconf] Draft agenda for NETCONF session in Beijing >=20 > Dear NETCONF WG, >=20 > we uploaded the draft agenda for NETCONF session in Beijing. >=20 > Pls let us know any requests. >=20 > http://www.ietf.org/proceedings/79/agenda/netconf.txt >=20 > Mehmet & Bert >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Tue Oct 26 06:24:31 2010 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 CA7693A67E7 for ; Tue, 26 Oct 2010 06:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 TyEaby9awRmV for ; Tue, 26 Oct 2010 06:24:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6F2153A6817 for ; Tue, 26 Oct 2010 06:24:29 -0700 (PDT) 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 o9QDQE5T004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Oct 2010 15:26:14 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9QDQ8kC003837; Tue, 26 Oct 2010 15:26:14 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 15:26:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB7511.5BABD3F1" Date: Tue, 26 Oct 2010 15:26:10 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64012323C3@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4742bis going to the next step WAS:RE: [Netconf] Update of 4742bis before deadline Thread-Index: Act0hnci9mpo7t8yT+uW4U8Afxhs9gAimSYw References: <80A0822C5E9A4440A5117C2F4CD36A64011E5AE0@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Margaret Wasserman" , "Netconf" X-OriginalArrivalTime: 26 Oct 2010 13:26:12.0995 (UTC) FILETIME=[5C14C530:01CB7511] Subject: [Netconf] 4742bis going to the next step WAS:RE: Update of 4742bis before deadline 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, 26 Oct 2010 13:24:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7511.5BABD3F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, based on the consensus on the NETCONF ML and as discussed=20 with the authors of the NETCONF 4742bis draft the document=20 is going to AD review. Pls find attached the doc write-up. Cheers, Mehmet > -----Original Message----- > From: ext Margaret Wasserman [mailto:margaretw42@gmail.com] > Sent: Monday, October 25, 2010 10:52 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Netconf > Subject: Re: [Netconf] Update of 4742bis before deadline WAS:Re: Status > WGLC RFC4742bis WAS:FW: status WGLC RFC4741bis >=20 >=20 > Hi Mehmet, >=20 > This update has been done, and the -04 version of the draft has been > posted. >=20 > Thanks, > Margaret >=20 > On Oct 24, 2010, at 1:36 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >=20 > > Hi Margaret, All, > > > > the result of the discussion showed that there is consensus on the > > last proposed text for this issue (below). With this we will update > > 4742bis before deadline. > > > > Margaret: Can you please update 4742bis with the text below? > > Thanks. > > > > Mehmet > > > > > > OLD: > > "This character sequence cannot legally appear outside of a comment > > in an > > XML document, so it can be unambigiously used to identify the end of > > the current document, allowing resynchronization of the NETCONF > > exchange in the event of an XML syntax or parsing error." > > > > NEW: > > "This character sequence MUST NOT appear in an XML document." > > > > > > NEW in Security Considerations section: > > "RFC 4742 assumes that the EOM sequence cannot appear in any XML > > document, which turned out to be mistaken. The EOM sequence can > > cause > > operational problems and open space for attacks if sent > deliberately > > in an XML > > document. It is however believed that the associated threat is not > > very high. > > This document keeps using the EOM sequence to avoid incompatibility > > with > > existing implementations. Implementations of SSH transport must > > exercise > > extra care and make sure the EOM sequence is not present in an XML > > document." > > > > > > > >> -----Original Message----- > >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >> Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > >> Sent: Friday, October 22, 2010 6:21 PM > >> To: ext Phil Shafer; Juergen Schoenwaelder > >> Cc: Andy Bierman; ext Margaret Wasserman; Netconf > >> Subject: Re: [Netconf] Status WGLC RFC4742bis WAS:FW: status WGLC > >> RFC4741bis > >> > >> Hi Phil, All, > >> > >> ::>> NEW: > >> ::>> "This character sequence MUST NOT appear in an XML document." > >> > >>>> Works for me. > >>> > >>> This is a change to the NETCONF protocol, since it makes a > > previously > >>> legal character sequence illegal. If we're willing to change > >>> NETCONF, why not just repair the SSH transport mapping, where the > >>> problem really exists. > >>> > >>> But if the WG really is following the "it's not a bug" line, then > >>> I suggest: > >>> > >>> (a) The draft should include an explanation of why this is illegal, > >>> with the history, etc. > >>> > >>> (b) The draft should include a description of the means to avoid > >>> this sequence (amper escaping) and a list of places where that > >>> escaping is not possible (processing instructions). > >>> > >>> That is, the draft should give all the details as we know them so > >>> an implementor can understand and properly address the issues. > >>> > >>> Me, I think it's a bug. A minor one, sure, but at least on par > with > >>> the other issues addressed with netconf-1.1. > >> > >> Yes, it is a bug. We found out it can only be addressed "thoroughly" > >> in v2.0. We are now trying to fix the mistaken text in v1.0 of > > 4742bis. > >> > >> SSH v1.0 is specified to recognize end of document with this > >> character > >> sequence. As we all were thinking, the character sequence cannot > > appear > >> in an XML document, I don't think it is a change for the NETCONF > >> protocol > >> (this BTW was the case since May 2004, see v01 of SSH draft which > >> leaded > >> > >> to 4742). > >> > >> If you think "MUST NOT" is too strict I can go also with "SHOULD > >> NOT". > >> OTOH, if we know already it is bad, why not "MUST"? > >> > >> The explanation text you are proposing should go into the security > >> considerations section of 4742bis, e.g.: > >> > >> NEW: > >> > >> :: "RFC 4742 assumes that the EOM sequence cannot appear in any XML > >> document, > >> :: which turned out to be mistaken. The EOM sequence can cause > >> operational > >> :: problems and open space for attacks if sent deliberately in an > XML > >> document. > >> :: It is however believed that the associated threat is not very > >> high. > >> This > >> :: document keeps using the EOM sequence to avoid incompatibility > >> with > >> :: existing clients. > >> :: Implementations of SSH transport must exercise extra care and > make > >> sure > >> :: the EOM sequence is not present in an XML document." > >> > >> All: > >> : Knowing that this is only a (limited) bug fixing for v1.0, can we > >> go > >> : with the proposed two NEW text blocks in 4742bis? > >> > >> We need a decision kind of soon to resubmit before deadline. Thank > > you. > >> > >> Mehmet > >> > >> > >> _______________________________________________ > >> 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 ------_=_NextPart_001_01CB7511.5BABD3F1 Content-Type: text/plain; name="101026_NETCONF-4742bis-Doc-Writeup.txt" Content-Transfer-Encoding: base64 Content-Description: 101026_NETCONF-4742bis-Doc-Writeup.txt Content-Disposition: attachment; filename="101026_NETCONF-4742bis-Doc-Writeup.txt" DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVy ZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRoZSAgDQogICAgICBEb2N1bWVudCBTaGVwaGVyZCBw ZXJzb25hbGx5IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUgIA0KICAgICAgZG9jdW1lbnQg YW5kLCBpbiBwYXJ0aWN1bGFyLCBkb2VzIGhlIG9yIHNoZSBiZWxpZXZlIHRoaXMgIA0KICAgICAg dmVyc2lvbiBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24/IA0KIA0KICAgICAgDQogICAgIEksIE1laG1ldCBFcnN1ZSwgYW0gdGhlIERvY3VtZW50IFNo ZXBhcmQgZm9yIHRoaXMgZG9jdW1lbnQuIA0KICAgICBJIGhhdmUgcGVyc29uYWxseSByZXZpZXdl ZCB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGFuZCBJIA0KICAgICBiZWxpZXZlIGl0IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQogICAgICANCiAgICAgQWRlcXVhdGUgcmV2aWV3IGhh cyBvY2N1cnJlZCBmcm9tIFdHIG1lbWJlcnMsIGFuZCBpdCBoYXMgYmVlbiANCiAgICAgcmV2aWV3 ZWQgZXNwZWNpYWxseSBieSBCZXJ0IFdpam5lbiwgQW5keSBCaWVybWFuLCBQaGlsIFNoYWVmZXIs DQogICAgIE1hcnRpbiBCam9ya2x1bmQsIExhZGEgTG90aGthLCBhbmQgSnVlcmdlbiBTY2hvZW53 YWVsZGVyLiANCiAgICAgVGhlIGlzc3VlcyByYWlzZWQgaW4gdGhlIHJldmlld3MgaGF2ZSBiZWVu IGRpc2N1c3NlZCBvbiB0aGUgDQogICAgIG1haWxpbmcgbGlzdCBhbmQgZml4ZWQgaW4gdGhlIGxh c3QgdmVyc2lvbnMuIA0KICAgICAgICANCiANCigxLmIpIEhhcyB0aGUgZG9jdW1lbnQgaGFkIGFk ZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5IFdHIG1lbWJlcnMgIA0KICAgICAgYW5kIGZyb20g a2V5IG5vbi1XRyBtZW1iZXJzPyBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlICANCiAg ICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZiB0aGUgcmV2aWV3 cyB0aGF0ICANCiAgICAgIGhhdmUgYmVlbiBwZXJmb3JtZWQ/ICAgICAgDQogDQogICAgICBUaGUg ZG9jdW1lbnQgaGFzIGhhZCBhZGVxdWF0ZSByZXZpZXcgZnJvbSB3b3JraW5nIGdyb3VwIGFuZCAN CiAgICAgIG5vbi13b3JraW5nIGdyb3VwIG1lbWJlcnMsIG1vc3RseSBmcm9tIE5FVENPTkYgYW5k IE5FVE1PRCBXR3MuICANCiAgICAgIEkgZG8gbm90IGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRo ZSBkZXB0aCBvciBicmVhZHRoIG9mIHJldmlldy4gICANCiAgICAgIA0KIA0KKDEuYykgRG9lcyB0 aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBjb25jZXJucyB0aGF0IHRoZSBkb2N1bWVudCAgDQog ICAgICAgIG5lZWRzIG1vcmUgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVy c3BlY3RpdmUsICANCiAgICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhp dHksIHNvbWVvbmUgZmFtaWxpYXIgd2l0aCAgDQogICAgICAgIEFBQSwgaW50ZXJuYXRpb25hbGl6 YXRpb24gb3IgWE1MPyANCiANCiAgICAgICAgTm8uIA0KIA0KKDEuZCkgRG9lcyB0aGUgRG9jdW1l bnQgU2hlcGhlcmQgaGF2ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgIA0KICAgICAgaXNzdWVz IHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yICAN CiAgICAgIGFuZC9vciB0aGUgSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBw ZXJoYXBzIGhlICANCiAgICAgIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBw YXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yICANCiAgICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRo ZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgIA0KICAgICAgZXZlbnQsIGlmIHRo ZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZCAgDQogICAg ICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRo b3NlICANCiAgICAgIGNvbmNlcm5zIGhlcmUuIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSByZWxhdGVk IHRvIHRoaXMgZG9jdW1lbnQgIA0KICAgICAgYmVlbiBmaWxlZD8gSWYgc28sIHBsZWFzZSBpbmNs dWRlIGEgcmVmZXJlbmNlIHRvIHRoZSAgDQogICAgICBkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUg dGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24gIA0KICAgICAgdGhpcyBpc3N1ZS4N Cg0KICAgICAgVGhlcmUgYXJlIG5vIGNvbmNlcm5zIGFib3V0IHRoZSB0ZWNobmljYWwgbWVyaXQg b2YgdGhlIGRvY3VtZW50LiANCg0KIA0KKDEuZSkgSG93IHNvbGlkIGlzIHRoZSBXRyBjb25zZW5z dXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMgaXQgIA0KICAgICAgICByZXByZXNlbnQgdGhl IHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCAgDQogICAgICAg IG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFu ZCBhbmQgIA0KICAgICAgICBhZ3JlZSB3aXRoIGl0PyANCiAgDQogICAgICAgVGhlcmUgaXMgc3Ry b25nIGNvbnNlbnN1cyBpbiB0aGUgV0cgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50Lg0KDQogDQoo MS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0 ZWQgZXh0cmVtZSAgDQogICAgICAgZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2Ug dGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluICANCiAgICAgICBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdl cyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0ICANCiAgICAgICBzaG91bGQg YmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyAgDQog ICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJRCBUcmFja2VyLikgDQogDQogICAgICBOby4gDQogDQog DQooMS5nKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVyaWZpZWQgdGhh dCB0aGUgIA0KICAgICAgIGRvY3VtZW50IHNhdGlzZmllcyBhbGwgSUQgbml0cz8gKFNlZSAgDQog ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9JRC1DaGVja2xpc3QuaHRtbCBhbmQgIA0KICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9pZG5pdHMvKS4gQm9pbGVycGxhdGUgY2hlY2tz IGFyZSAgDQogICAgICAgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3Vn aC4gSGFzIHRoZSBkb2N1bWVudCAgDQogICAgICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNyaXRl cmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRoZSBNSUIgIA0KICAgICAgIERvY3RvciwgbWVkaWEg dHlwZSBhbmQgVVJJIHR5cGUgcmV2aWV3cz8gDQogICAgICANCiAgICAgIFllcy4gVGhlcmUgaXMg b25seSBvbmUgb3V0ZGF0ZWQgcmVmZXJlbmNlIChmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLTQ3NDFi aXMpLg0KICAgDQogDQooMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2Vz IGludG8gbm9ybWF0aXZlIGFuZCAgDQogICAgICAgaW5mb3JtYXRpdmU/IEFyZSB0aGVyZSBub3Jt YXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCAgDQogICAgICAgYXJlIG5vdCByZWFk eSBmb3IgYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyICANCiAgICAg ICBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUg IA0KICAgICAgIHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9ybWF0 aXZlIHJlZmVyZW5jZXMgIA0KICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFz IGRlc2NyaWJlZCBpbiBbUkZDMzk2N10/IElmICANCiAgICAgICBzbywgbGlzdCB0aGVzZSBkb3du d2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgIA0KICAgICAgIERpcmVjdG9yIGlu IHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4gDQogDQogICAgICBU aGUgZG9jdW1lbnQgaGFzIHNwbGl0IHJlZmVyZW5jZXMgaW50byBub3JtYXRpdmUgYW5kIGluZm9y bWF0aXZlLiANCiANCiANCigxLmkpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQg dGhhdCB0aGUgZG9jdW1lbnQgSUFOQSAgDQogICAgICBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXhp c3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkgIA0KICAgICAgb2YgdGhlIGRvY3Vt ZW50PyBJZiB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sICANCiAgICAgIGV4dGVuc2lv bnMsIGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEgIA0KICAg ICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVk PyBJZiAgDQogICAgICB0aGUgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyByZWdpc3RyeSwgZG9lcyBp dCBkZWZpbmUgdGhlICANCiAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJl Z2lzdHJ5IGFuZCBhbiBhbGxvY2F0aW9uICANCiAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJl Z2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhICANCiAgICAgIHJlYXNvbmFibGUgbmFtZSBm b3IgdGhlIG5ldyByZWdpc3RyeT8gU2VlIFtSRkM1MjI2XS4gSWYgdGhlICANCiAgICAgIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nlc3MgaGFzIFNoZXBoZXJkICANCiAg ICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQg dGhlIElFU0cgIA0KICAgICAgY2FuIGFwcG9pbnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIHRo ZSBJRVNHIEV2YWx1YXRpb24/IA0KIA0KICAgICAgSUFOQSBjb25zaWRlcmF0aW9ucyBhcmUgcHJl c2VudCBhbmQgY29tcGxldGUuIFRoZSBkcmFmdCANCiAgICAgIHJlcXVlc3RzIHRvIHVwZGF0ZSB0 aGUgYWxsb2NhdGlvbnMsIHdoaWNoIGhhdmUgYmVlbiBkb25lIA0KICAgICAgZm9yIFJGQyA0NzQy Lg0KDQogDQooMS5qKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2Vj dGlvbnMgb2YgdGhlICANCiAgICAgIGRvY3VtZW50IHRoYXQgYXJlIHdyaXR0ZW4gaW4gYSBmb3Jt YWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MICANCiAgICAgIGNvZGUsIEJORiBydWxlcywgTUlCIGRl ZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0bHkgaW4gIA0KICAgICAgYW4gYXV0b21h dGVkIGNoZWNrZXI/DQoNCiAgICAgIFRoZXJlIGlzIG5vIGRhdGEgbW9kZWwgaW4gdGhpcyBkb2N1 bWVudC4gDQoNCiANCigxLmspIFRoZSBJRVNHIGFwcHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRl cyBhIERvY3VtZW50ICANCiAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcC4gUGxlYXNlIHByb3Zp ZGUgc3VjaCBhIERvY3VtZW50ICANCiAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50 IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUgDQogICAgICAiQWN0aW9uIiBhbm5vdW5jZW1l bnRzIGZvciBhcHByb3ZlZCBkb2N1bWVudHMuIFRoZSBhcHByb3ZhbCAgDQogICAgICBhbm5vdW5j ZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczogICAgICAgICAgICANCiANCiAg ICAgIFRlY2huaWNhbCBTdW1tYXJ5ICANCg0KICAgICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YSBtZXRob2QgZm9yIGludm9raW5nIGFuZCBydW5uaW5nIA0KICAgICAgdGhlIE5FVENPTkYgcHJv dG9jb2wgd2l0aGluIGEgU2VjdXJlIFNoZWxsIChTU0gpIHNlc3Npb24gDQogICAgICBhcyBhbiBT U0ggc3Vic3lzdGVtLg0KDQogICAgICBXb3JraW5nIEdyb3VwIFN1bW1hcnkgIA0KDQogICAgICBU aGlzIGRvY3VtZW50IGhhcyBiZWVuIGxvbmdseSBkaXNjdXNzZWQgaW4gdGhlIFdvcmtpbmcgR3Jv dXAsIA0KICAgICAgaW5jbHVkaW5nIHNldmVyYWwgV0cgTGFzdCBDYWxscy4gVGhlIGNvbW1lbnRz IGFuZCByZXZpZXdzIGhlbHBlZCANCiAgICAgIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50IGEgbG90 IGFuZCB0aGUgY3VycmVudCB2ZXJzaW9uIHJlZmxlY3RzIHRoZSANCiAgICAgIGNvbnNlbnN1cyBv ZiB0aGUgV29ya2luZyBHcm91cC4gDQogICAgICBUaGUgZG9jdW1lbnQgaW5jb3Jwb3JhdGVzIGFs bCBhY2NlcHRlZCBlcnJhdGEgYWdhaW5zdCBSRkM0NzQyLg0KICAgICAgQWZ0ZXIgYSBsb25nIGRl YmF0ZSB0aGUgV0cgZGVjaWRlZCB0byBoYXZlIHRoZSB3YXkgYSBORVRDT05GIA0KICAgICAgU2Vy dmVyIGV4dHJhY3RzIHRoZSBTU0ggdXNlciBuYW1lIGZyb20gdGhlIFNTSCBsYXllciBhcyANCiAg ICAgIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4NCiAgICAgIFRoZXJlIHdhcyBhIGxvbmcgZGlz Y3Vzc2lvbiBvbiB0aGUgaGFuZGxpbmcgb2YgdGhlIEVPTSBjaGFyYWN0ZXINCiAgICAgIHNlcXVl bmNlLiBUaGUgd29ya2dyb3VwIGFncmVlcyB0aGF0IHRoaXMgaXNzdWUgc2hvdWxkIGJlIHNvbHZl ZCANCiAgICAgIHdpdGggYW4gYWRkaXRpb25hbCBmcmFtaW5nLCB3aGljaCB3b3VsZCBsZWFkIHRv IGEgbmV3IHZlcnNpb24gDQogICAgICBpbmNvbXBhdGlibGUgd2l0aCB2ZXJzaW9uIHYxLjAuIEFz IGRlc2NyaWJlZCBpbiB0aGUgU2VjdXJpdHkgDQogICAgICBDb25zaWRlcmF0aW9ucyBzZWN0aW9u IHRoZSBFT00gc2VxdWVuY2UgY2FuIGNhdXNlIG9wZXJhdGlvbmFsIA0KICAgICAgaXNzdWVzIGhv d2V2ZXIgdGhlIHdvcmtncm91cCBiZWxpZXZlcyB0aGUgYXNzb2NpYXRlZCB0aHJlYXQgaXMgDQog ICAgICBub3QgdmVyeSBoaWdoLiAgQXMgdGhlIHdvcmtnb3VwIGhhcyBvbmx5IGEgbWFuZGF0ZSBm b3IgYnVnIGZpeGluZyANCiAgICAgIHRoZSBkb2N1bWVudCBrZWVwcyB1c2luZyB0aGUgRU9NIHNl cXVlbmNlIHRvIGF2b2lkIGluY29tcGF0aWJpbGl0eSANCiAgICAgIHdpdGggZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zLg0KDQoNCiANCiAgICAgIERvY3VtZW50IFF1YWxpdHkgDQoNCiAgICAgIEFy ZSB0aGVyZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHByb3RvY29sPyBIYXZlIGEg DQogICAgICBzaWduaWZpY2FudCBudW1iZXIgb2YgdmVuZG9ycyBpbmRpY2F0ZWQgdGhlaXIgcGxh biB0byANCiAgICAgIGltcGxlbWVudCB0aGUgc3BlY2lmaWNhdGlvbj8gQXJlIHRoZXJlIGFueSBy ZXZpZXdlcnMgdGhhdCANCiAgICAgIG1lcml0IHNwZWNpYWwgbWVudGlvbiBhcyBoYXZpbmcgZG9u ZSBhIHRob3JvdWdoIHJldmlldywgDQogICAgICBlLmcuLCBvbmUgdGhhdCByZXN1bHRlZCBpbiBp bXBvcnRhbnQgY2hhbmdlcyBvciBhIGNvbmNsdXNpb24gDQogICAgICB0aGF0IHRoZSBkb2N1bWVu dCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiB0aGVyZSB3YXMgYSANCiAgICAgIE1JQiBE b2N0b3IsIE1lZGlhIFR5cGUgb3Igb3RoZXIgZXhwZXJ0IHJldmlldywgd2hhdCB3YXMgaXRzIA0K ICAgICAgY291cnNlIChicmllZmx5KT8gSW4gdGhlIGNhc2Ugb2YgYSBNZWRpYSBUeXBlIHJldmll dywgb24gDQogICAgICB3aGF0IGRhdGUgd2FzIHRoZSByZXF1ZXN0IHBvc3RlZD8NCg0KICAgICAg U2luY2UgU1NIIGlzIG1hbmRhdG9yeSB0cmFuc3BvcnQgZm9yIE5FVENPTkYgdGhlcmUgYXJlIG51 bWVyb3VzDQogICAgICBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIDQ3NDIuIDQ3NDJiaXMgaXMgZG9p bmcgb25seSBidWcgZml4aW5nIGFuZCAgICAgICAgIA0KICAgICAgZXhpc3RpbmcgaW1wbGVtZW50 YXRpb25zIGNhbiBiZSB1cGRhdGVkIG9uY2UgNDc0MmJpcyBiZWNvbWVzIA0KICAgICAgcHJvcG9z ZWQgc3RhbmRhcmQuDQoNCg0KTWVobWV0IEVyc3VlDQpEb2N1bWVudCBTaGVwaGVyZA0K ------_=_NextPart_001_01CB7511.5BABD3F1-- From bertietf@bwijnen.net Tue Oct 26 07:08:10 2010 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 D80FB3A68EC for ; Tue, 26 Oct 2010 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 BySagOAeqBgr for ; Tue, 26 Oct 2010 07:08:09 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 37C633A68FC for ; Tue, 26 Oct 2010 07:08:08 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PAkDk-0007MX-Bo; Tue, 26 Oct 2010 16:09:54 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PAkDj-0000Hq-WD; Tue, 26 Oct 2010 16:09:48 +0200 Message-ID: <4CC6E12B.9050504@bwijnen.net> Date: Tue, 26 Oct 2010 16:09:47 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: MArtin Bjorklund References: <64A0B7E0557141968E99BCC4331E9C11@BertLaptop> <1175499ED8E74E969625B2FCF6D0F53E@BertLaptop> In-Reply-To: <1175499ED8E74E969625B2FCF6D0F53E@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44d479a437f656afa4f46051b6a396967 X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44d479a437f656afa4f46051b6a396967 Cc: Netconf Subject: Re: [Netconf] RFC4741bis will now go to our AD. 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, 26 Oct 2010 14:08:10 -0000 OK, before sending my document-shepherd write-up to our AD with a request to consider this document for standards track RFC publication, I of course did another quite detailed review (I have to, in order to answer all the questions that the shepherd write-up asks). The document looks really good, except a few editorial nits/remarks. So I propose that they can be considered initial IETF Last Call comments (ID cutoff was yday, so Martin cannot quickly submit a new revision). Here are the things I found. Speak up asap if you disagree with any of this. The IDNITs page http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-netconf-4741bis-06.txt shows a few warnings and comments as follows: Checking nits according to http://www.ietf.org/id-info/checklist : ----------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A lock MUST not be granted if either of the following conditions is true: XX-- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) XX-- Possible downref: Non-RFC (?) normative reference: ref. '1' XX-- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-04) exists of draft-ietf-netconf-rfc4742bis-03 -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '15') (Obsoleted by RFC 5246) I discussed them with the main editor (Martin) and he agrees to fix then all except the ones I marked XX, because we know that this is correct. Futher, I notoced that our figire 1 (which is an update to the one in RFC4741) also differes from figire 1 in rfc5277. The reason for this is that we have renamed the layers (to more appropriate names), and so the figure in this 4741bis document is the most accurate and best representation of our protocol layers. Martin and I have agreed that it is best to add a bullet to appendix F, to explicitly state that we have changed the names of our layers (fort clarification) and that as a result figure 1 changed. I found one place where "data store" is written while "datastore" is intended (page 18). For consistency and clarity, I think it is best to fix that. Document Shepherd Bert From dromasca@avaya.com Tue Oct 26 10:52:47 2010 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 EDD893A69D4 for ; Tue, 26 Oct 2010 10:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 t2MeSRVg3Khp for ; Tue, 26 Oct 2010 10:52:46 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id DFB1F3A69BE for ; Tue, 26 Oct 2010 10:52:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,242,1286164800"; d="scan'208";a="41656330" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 26 Oct 2010 13:54:33 -0400 X-IronPort-AV: E=Sophos;i="4.58,242,1286164800"; d="scan'208";a="528911076" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Oct 2010 13:53:52 -0400 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: Tue, 26 Oct 2010 19:53:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: Thread-Index: ActynvYM1Kf88dbeRJyCM6X/rmbMSgCl4Dng From: "Romascanu, Dan (Dan)" To: , Cc: netconf Subject: [Netconf] FW: DISCUSS and COMMENT: 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, 26 Oct 2010 17:52:47 -0000 Andy, Balazs,=20 Please address the question raised by Alaxey in his DISCUSS.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Saturday, October 23, 2010 12:41 PM To: iesg@ietf.org Cc: draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: Discuss: While I was initially skeptical about usability of this extension, I think the document is making a compelling argument for having this extension. However, there is one question I would like to discuss: A NETCONF server implementing the :with-defaults capability: o MUST indicate its basic mode behavior by including the 'basic- mode' parameter in the capability URI, as defined in Section 4.4. o MUST support the YANG module defined in Section 5. o SHOULD support the 'report-all' or 'report-all-tagged' defaults handling mode. o MAY support additional defaults handling modes. DISCUSS DISCUSS (this might result in no changes to the document): Is the goal here to allow servers to advertise what they support, but pushing complexity of dealing with multiple modes to clients? My personal experience with other protocols suggest that simpler operations for clients would result in more widespread deployment of extensions. So to translate this into something actionable: I am a bit concerned that various things are optional for compliant servers to support. I would feel more comfortable changing the SHOULD/MAY to MUSTs (at least for the SHOULD). Is this something that was discussed in the WG? Comment: I think XSD needs a Normative reference. From randy_presuhn@mindspring.com Tue Oct 26 11:16:47 2010 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 DDB103A6844 for ; Tue, 26 Oct 2010 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 s7lfAzp8-QUH for ; Tue, 26 Oct 2010 11:16:46 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 2B5DD3A6818 for ; Tue, 26 Oct 2010 11:16:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WwGSiZQf1r+X5kfrgbwQJ8KYx03oQFUZP2UuxNG8VaIDZQ9cdTOO97/H/8K1Fi8x; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.42] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAo6J-0002hA-Jw for netconf@ietf.org; Tue, 26 Oct 2010 14:18:23 -0400 Message-ID: <001701cb753a$707ec420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> <20101026.093846.100862283.mbj@tail-f.com> Date: Tue, 26 Oct 2010 11:19:50 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe3464fa8e0c72bb965245b45f7fe73943350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.42 Subject: Re: [Netconf] NACM draft 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, 26 Oct 2010 18:16:48 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, October 26, 2010 12:38 AM > Subject: Re: [Netconf] NACM draft ... > Do you think authentication should be split into a separate document, > or do you think that the solution should not cover authentication at > all? Why? It's not meaningful to talk about access control without reference to the authentication of the entities. (Not just the party being given access permission, but also the authentication of the party providing the information.) In my opinion, if RADIUS support is to be optional, then authentication details would belong in a (mercifully brief) separate document, in order to maintain modularity. (If modularity is a goal - I'm not convinced that it really is a goal of netconf.) Something should identify what the mandatory-to-implement authentication mechanism is. Access control without a mandatory-to-implement authentication mechanism seems a cruel joke from an interoperability perspective. > It seems the term "access control" means different things to different > people. Some people thinks it is just authorization, some think it is > authentication + authorization, and some even include audit > (e.g. http://en.wikipedia.org/wiki/Access_control#Computer_security) Also, folks mean different things by "authorization". Here, as in isms, the policies for authorizing use of the communication channel are separated from the policies for authorizing access to specific bits of information. If RADIUS handles the authentication and provides the group mapping, the only reason the netconf machinery would need the user name would be to support a (future, probably optional) audit funtion. > Personally, I think we need both authentication and authorization. If > it is done in one or two documents is not very important, although I > perfer one document at this stage. FWIW, I don't care a great deal about the question, though I think two documents would give better future-proofing if mechanisms other than RADIUS are to be supported in the future, or if the mandatory-to implement mechanism takes more than a paragraph or two to specify. On the other hand, if RADIUS support is mandatory-to-implement, then it would be OK to do it in a single document. > > In particular, if RADIUS is required to provide "group" mappings > > Currently RADIUS support is not required, and if RADIUS is supported, > it is not required to support the "group" mapping. > > > , then the > > material on user/group mappings can be greatly simplified, as well as the > > "superuser" stuff, which reduces to an all-powerful, potentially pre-installed > > group, much like the appendix material in VACM). It should also spell out > > what happens when RADIUS fails to provide a group mapping, but has > > authenticated the user. > > Ok. The idea is that group names are accumulative, i.e. the list of > local groups are added to the result from RADIUS. In that case, you'll need to work through how you want it to work when the RADIUS-provided mapping is different from one in the configuration. We already went through that exercise in isms. > > I think any references to RADIUS should clearly identify the RADIUS attributes > > involved. > > Don't you think that the currect draft does that? Not consistently. Randy From j.schoenwaelder@jacobs-university.de Tue Oct 26 11:21:11 2010 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 862693A6877 for ; Tue, 26 Oct 2010 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MW700Snh2yBy for ; Tue, 26 Oct 2010 11:21:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDCFD3A6818 for ; Tue, 26 Oct 2010 11:21:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F012CC0036; Tue, 26 Oct 2010 20:22:56 +0200 (CEST) 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 eHfqrPBA0ScX; Tue, 26 Oct 2010 20:22:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A922C0011; Tue, 26 Oct 2010 20:22:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F3BD1581E2B; Tue, 26 Oct 2010 20:22:15 +0200 (CEST) Date: Tue, 26 Oct 2010 20:22:15 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20101026182215.GA73918@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701cb753a$707ec420$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft 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: Tue, 26 Oct 2010 18:21:11 -0000 On Tue, Oct 26, 2010 at 11:19:50AM -0700, Randy Presuhn wrote: > In my opinion, if RADIUS support is to be optional, then authentication > details would belong in a (mercifully brief) separate document, in order > to maintain modularity. (If modularity is a goal - I'm not convinced that > it really is a goal of netconf.) I believe in modularity. As fas as I understand the mandatory to implement transport, authentication is handled by the SSH layer and not by NETCONF directly. In other words, there should be a YANG module to configure SSH and the problem is solved. And for the other NETCONF transports, we should realize that their ways of authenticating a principal is sometimes radically different from SSH. If we want to give up modularity, the first step would be to declare those transports Historic. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Tue Oct 26 11:21:17 2010 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 E01153A68FC for ; Tue, 26 Oct 2010 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.138, 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 tCP7Nyp0MW+3 for ; Tue, 26 Oct 2010 11:21:16 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id DB5593A68EE for ; Tue, 26 Oct 2010 11:21:15 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9QIM6ei020572; Tue, 26 Oct 2010 11:22:58 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id s644xg02g-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Oct 2010 11:22:58 -0700 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; Tue, 26 Oct 2010 11:22:42 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 26 Oct 2010 11:22:54 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" , "balazs.lengyel@ericsson.com" Date: Tue, 26 Oct 2010 11:22:54 -0700 Thread-Topic: DISCUSS and COMMENT: Thread-Index: ActynvYM1Kf88dbeRJyCM6X/rmbMSgCl4DngAADTmrA= Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-26_09:2010-10-26, 2010-10-26, 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-1004200000 definitions=main-1010260118 X-Proofpoint-SSN: Sensitivity2 Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 26 Oct 2010 18:21:17 -0000 Hi, I already did -- will send another email I guess. Yes, there is a goal here to allow servers to advertise what they support, But pushing complexity of dealing with multiple modes to clients, where 'multiple modes' means the client needs to be able to support all 3 modes in order to support all possible compliant servers. The WG is not going to get N-1 vendors to change to the way 1 vendor implemented defaults. A server has to pick 1 of 3 modes and stick to it. Why is this too complicated? Andy -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Tuesday, October 26, 2010 10:54 AM To: Andy Bierman; balazs.lengyel@ericsson.com Cc: netconf Subject: FW: DISCUSS and COMMENT: Andy, Balazs,=20 Please address the question raised by Alaxey in his DISCUSS.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Saturday, October 23, 2010 12:41 PM To: iesg@ietf.org Cc: draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: Discuss: While I was initially skeptical about usability of this extension, I think the document is making a compelling argument for having this extension. However, there is one question I would like to discuss: A NETCONF server implementing the :with-defaults capability: o MUST indicate its basic mode behavior by including the 'basic- mode' parameter in the capability URI, as defined in Section 4.4. o MUST support the YANG module defined in Section 5. o SHOULD support the 'report-all' or 'report-all-tagged' defaults handling mode. o MAY support additional defaults handling modes. DISCUSS DISCUSS (this might result in no changes to the document): Is the goal here to allow servers to advertise what they support, but pushing complexity of dealing with multiple modes to clients? My personal experience with other protocols suggest that simpler operations for clients would result in more widespread deployment of extensions. So to translate this into something actionable: I am a bit concerned that various things are optional for compliant servers to support. I would feel more comfortable changing the SHOULD/MAY to MUSTs (at least for the SHOULD). Is this something that was discussed in the WG? Comment: I think XSD needs a Normative reference. From dromasca@avaya.com Tue Oct 26 11:26:57 2010 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 BBF773A6958 for ; Tue, 26 Oct 2010 11:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 Axeutp-9YxWv for ; Tue, 26 Oct 2010 11:26:56 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9AE783A67F9 for ; Tue, 26 Oct 2010 11:26:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,242,1286164800"; d="scan'208";a="41678227" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 26 Oct 2010 14:28:44 -0400 X-IronPort-AV: E=Sophos;i="4.58,242,1286164800"; d="scan'208";a="532194667" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Oct 2010 14:28:43 -0400 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: Tue, 26 Oct 2010 20:28:21 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: Thread-Index: ActynvYM1Kf88dbeRJyCM6X/rmbMSgCl4DngAADTmrAAAGtpgA== References: From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 26 Oct 2010 18:26:57 -0000 Thanks, I found the mails and will follow up with Alexey.=20 Dan =20 > -----Original Message----- > From: Andy Bierman [mailto:biermana@Brocade.com]=20 > Sent: Tuesday, October 26, 2010 8:23 PM > To: Romascanu, Dan (Dan); balazs.lengyel@ericsson.com > Cc: netconf > Subject: RE: DISCUSS and COMMENT:=20 > >=20 > Hi, >=20 > I already did -- will send another email I guess. >=20 > Yes, there is a goal here to allow servers to advertise what=20 > they support, But pushing complexity of dealing with multiple=20 > modes to clients, where 'multiple modes' means the client=20 > needs to be able to support all 3 modes in order to support=20 > all possible compliant servers. >=20 > The WG is not going to get N-1 vendors to change to the way 1=20 > vendor implemented defaults. A server has to pick 1 of 3=20 > modes and stick to it. > Why is this too complicated? >=20 >=20 > Andy >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, October 26, 2010 10:54 AM > To: Andy Bierman; balazs.lengyel@ericsson.com > Cc: netconf > Subject: FW: DISCUSS and COMMENT:=20 > >=20 > Andy, Balazs,=20 >=20 > Please address the question raised by Alaxey in his DISCUSS.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Alexey Melnikov > Sent: Saturday, October 23, 2010 12:41 PM > To: iesg@ietf.org > Cc: draft-ietf-netconf-with-defaults@tools.ietf.org; > netconf-chairs@tools.ietf.org > Subject: DISCUSS and COMMENT:=20 > >=20 > Discuss: > While I was initially skeptical about usability of this=20 > extension, I think the document is making a compelling=20 > argument for having this extension. >=20 > However, there is one question I would like to discuss: >=20 > A NETCONF server implementing the :with-defaults capability: >=20 > o MUST indicate its basic mode behavior by including the 'basic- > mode' parameter in the capability URI, as defined in=20 > Section 4.4. > o MUST support the YANG module defined in Section 5. > o SHOULD support the 'report-all' or 'report-all-tagged' defaults > handling mode. > o MAY support additional defaults handling modes. >=20 > DISCUSS DISCUSS (this might result in no changes to the document): > Is the goal here to allow servers to advertise what they=20 > support, but pushing complexity of dealing with multiple=20 > modes to clients? My personal experience with other protocols=20 > suggest that simpler operations for clients would result in=20 > more widespread deployment of extensions. >=20 > So to translate this into something actionable: I am a bit=20 > concerned that various things are optional for compliant=20 > servers to support. I would feel more comfortable changing=20 > the SHOULD/MAY to MUSTs (at least for the SHOULD). > Is this something that was discussed in the WG? >=20 >=20 >=20 > Comment: > I think XSD needs a Normative reference. >=20 >=20 >=20 From mbj@tail-f.com Tue Oct 26 13:15:12 2010 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 652A83A68D8 for ; Tue, 26 Oct 2010 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.113, 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 IqJhQLmGcC2k for ; Tue, 26 Oct 2010 13:15:00 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6769D3A68E9 for ; Tue, 26 Oct 2010 13:15:00 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 19889616004; Tue, 26 Oct 2010 22:16:47 +0200 (CEST) Date: Tue, 26 Oct 2010 22:16:44 +0200 (CEST) Message-Id: <20101026.221644.147981779.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001701cb753a$707ec420$6801a8c0@oemcomputer> References: <001601cb74cb$bc327e80$6801a8c0@oemcomputer> <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> 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] NACM draft 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, 26 Oct 2010 20:15:13 -0000 Hi, "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Tuesday, October 26, 2010 12:38 AM > > Subject: Re: [Netconf] NACM draft > ... > > Do you think authentication should be split into a separate document, > > or do you think that the solution should not cover authentication at > > all? Why? > > It's not meaningful to talk about access control without reference to > the authentication of the entities. (Not just the party being given access > permission, but also the authentication of the party providing the > information.) > > In my opinion, if RADIUS support is to be optional, then authentication > details would belong in a (mercifully brief) separate document, in order > to maintain modularity. (If modularity is a goal - I'm not convinced that > it really is a goal of netconf.) I do think modularity is a goal. But it doesn't necessarily mean that all different components must be defined in separate documents. Are you saying that any mandatory authentication mechanism should be defined in the NACM document? > > > I think any references to RADIUS should clearly identify the RADIUS > > > attributes > > > involved. > > > > Don't you think that the currect draft does that? > > Not consistently. Can you be specific? /martin From mbj@tail-f.com Tue Oct 26 13:23:58 2010 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 C0A033A68CE for ; Tue, 26 Oct 2010 13:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.107, 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 CjJ8hGfeCLHc for ; Tue, 26 Oct 2010 13:23:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C4ED03A68F5 for ; Tue, 26 Oct 2010 13:23:27 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 60DB4616004; Tue, 26 Oct 2010 22:25:15 +0200 (CEST) Date: Tue, 26 Oct 2010 22:25:13 +0200 (CEST) Message-Id: <20101026.222513.144818361.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101026182215.GA73918@elstar.local> References: <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> <20101026182215.GA73918@elstar.local> 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] NACM draft 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, 26 Oct 2010 20:23:58 -0000 Juergen Schoenwaelder wrote: > On Tue, Oct 26, 2010 at 11:19:50AM -0700, Randy Presuhn wrote: > > > In my opinion, if RADIUS support is to be optional, then authentication > > details would belong in a (mercifully brief) separate document, in order > > to maintain modularity. (If modularity is a goal - I'm not convinced that > > it really is a goal of netconf.) > > I believe in modularity. As fas as I understand the mandatory to > implement transport, authentication is handled by the SSH layer and > not by NETCONF directly. In other words, there should be a YANG module > to configure SSH and the problem is solved. But configuration of an SSH server in general is a much bigger task than configuration of SSH on a typical networking device that can be configured with NETCONF. > And for the other NETCONF transports, we should realize that their > ways of authenticating a principal is sometimes radically different > from SSH. Absolutely. The draft tries to take this into account. /martin From randy_presuhn@mindspring.com Tue Oct 26 14:20:42 2010 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 868E13A68DE for ; Tue, 26 Oct 2010 14:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=0.702, 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 6AheMbUyYf2F for ; Tue, 26 Oct 2010 14:20:41 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id A6EFA3A682C for ; Tue, 26 Oct 2010 14:20:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ooIvrRxFtwvCq7z0KYJh3RB0qMcgaYTkl/gRIF6w6BCtMsUE71qov+OPvRSRrB8i; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.51.212] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAqyT-0007bk-C1 for netconf@ietf.org; Tue, 26 Oct 2010 17:22:29 -0400 Message-ID: <002d01cb7554$1bcb44c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001601cb74cb$bc327e80$6801a8c0@oemcomputer><20101026.093846.100862283.mbj@tail-f.com><001701cb753a$707ec420$6801a8c0@oemcomputer> <20101026.221644.147981779.mbj@tail-f.com> Date: Tue, 26 Oct 2010 14:23:59 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe5b96aa8e7ea888950817c2d50569dc4d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.212 Subject: Re: [Netconf] NACM draft 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, 26 Oct 2010 21:20:42 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, October 26, 2010 1:16 PM > Subject: Re: [Netconf] NACM draft ... > > Not consistently. > > Can you be specific? The new I-D (October 25) addresses the issue. Randy From bertietf@bwijnen.net Tue Oct 26 15:21:41 2010 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 AACD03A6897 for ; Tue, 26 Oct 2010 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 14SntvySTNPF for ; Tue, 26 Oct 2010 15:21:38 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 4B4063A6835 for ; Tue, 26 Oct 2010 15:21:38 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PArvM-0001JU-IB for netconf@ietf.org; Wed, 27 Oct 2010 00:23:26 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PArvM-0006G3-A3 for netconf@ietf.org; Wed, 27 Oct 2010 00:23:20 +0200 Message-ID: <4CC754D7.8090006@bwijnen.net> Date: Wed, 27 Oct 2010 00:23:19 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43a44bea79b95f93d35c7227203b712ce X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43a44bea79b95f93d35c7227203b712ce Subject: [Netconf] Fwd FYI: Request to consider 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: Tue, 26 Oct 2010 22:21:42 -0000 FYI, this request was sent to Dan and the iesg-secretary Bert ------------------- Hi Dan, based on the consensus in the NETCONF WG and as discussed with Mehmet and the authors of the NETCONF 4741bis draft we think that we are ready to bring the document to the next step. Please initiate the necessary process for the publication of draft-ietf-netconf-4741bis-06.txt as Proposed Standard obseleting RFC 4741. Please find below the document write-up for http://tools.ietf.org/html/draft-ietf-netconf-4741bis-06. Doing my shepherd review I found a few editorial changes that need to be made (posted to NETCONF WG list), but I prefer that they be considered as first IETF LC comments (currently the ID-submission is closed, so we can't quickly submit a new rev). Thank you. Document shepherd, Bert Wijnen ------ (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 6, that I believe is ready for forwarding to the AD/IESG. (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-06.txt There are no errors, but there are a few comments and warnings. We're addressing those, but we're in ID-cutoff, so we cannot submit a fixed version immediately. (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. 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 (including reported rfc4741 errata) 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 6th revision of the docuemnt. Document Quality There are implementations of this protocol, and in fact the rfc4741bis revision is based on implementation experience. From j.schoenwaelder@jacobs-university.de Tue Oct 26 15:58:39 2010 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 E5E813A6895 for ; Tue, 26 Oct 2010 15:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 oXw-JTCsG-Mp for ; Tue, 26 Oct 2010 15:58:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C8F13A68D5 for ; Tue, 26 Oct 2010 15:58:38 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B721C0031; Wed, 27 Oct 2010 01:00:23 +0200 (CEST) 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 LME-XKZGZ5YR; Wed, 27 Oct 2010 01:00:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81A3FC000A; Wed, 27 Oct 2010 01:00:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 48CDF15824DB; Wed, 27 Oct 2010 00:59:44 +0200 (CEST) Date: Wed, 27 Oct 2010 00:59:44 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101026225944.GD74170@elstar.local> Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netconf@ietf.org References: <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> <20101026182215.GA73918@elstar.local> <20101026.222513.144818361.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101026.222513.144818361.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft 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: Tue, 26 Oct 2010 22:58:40 -0000 On Tue, Oct 26, 2010 at 10:25:13PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Oct 26, 2010 at 11:19:50AM -0700, Randy Presuhn wrote: > > > > > In my opinion, if RADIUS support is to be optional, then authentication > > > details would belong in a (mercifully brief) separate document, in order > > > to maintain modularity. (If modularity is a goal - I'm not convinced that > > > it really is a goal of netconf.) > > > > I believe in modularity. As fas as I understand the mandatory to > > implement transport, authentication is handled by the SSH layer and > > not by NETCONF directly. In other words, there should be a YANG module > > to configure SSH and the problem is solved. > > But configuration of an SSH server in general is a much bigger task > than configuration of SSH on a typical networking device that can be > configured with NETCONF. But I do at the end configure sshd on NETCONF servers I happen to have. So why not try to have a minimal SSH configuration model that can be extended with more features? Does it match reality to have some SSH config in a NETCONF access control model, some in an SNMP transport model, and the rest elsewhere? How is an implementation expected to resolve conflicts? I am also concerned about /nacm/authentication/user - I consider local accounts a system property, not specifically a NETCONF property. Is this /nacm/authentication/user covering all accounts on a system or only a proper subset that is allowed to be used by NETCONF? On my system, RADIUS is also not really a property of NETCONF; it is PAM that takes care of how a password is validated and whether it is sent to a RADIUS server. In other words, sshd calls PAM and the PAM config tells whether RADIUS is involved and if so, the PAM RADIUS config tells how to talk to the right RADIUS server. We can pretend all this is not happening. But then, what do we do if someone has to configure a different protocol that authenticates in a similar way via RADIUS? Are we expecting them to use or augment /nacm/authentication/user? Or do they do their own little thing, leaving it to surprises if things collide and fail in non-obvious ways? My proposal back in Maastricht was to remove the authentication material from NACM so that this module can focus on the access control decision and the document can move on according to schedule. The notion of system accounts (= local users) and account authentication can be taken up as part of a core system model in NETMOD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Tue Oct 26 16:20:22 2010 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 38CCC3A690C for ; Tue, 26 Oct 2010 16:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.131, 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 2dI4gEjr+QRg for ; Tue, 26 Oct 2010 16:20:21 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id EB2C03A67AD for ; Tue, 26 Oct 2010 16:20:20 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9QNLXSN025564; Tue, 26 Oct 2010 16:22:08 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id s65q2046s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Oct 2010 16:22:08 -0700 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; Tue, 26 Oct 2010 16:21:54 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 26 Oct 2010 16:22:06 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "Martin Bjorklund" Date: Tue, 26 Oct 2010 16:22:06 -0700 Thread-Topic: [Netconf] NACM draft Thread-Index: Act1YaTRyR65HbB2RTOx38DOafvqhAAAVBWA Message-ID: References: <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> <20101026182215.GA73918@elstar.local> <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> In-Reply-To: <20101026225944.GD74170@elstar.local> 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=2010-10-26_11:2010-10-26, 2010-10-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010260179 X-Proofpoint-SSN: Sensitivity2 Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM draft 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, 26 Oct 2010 23:20:22 -0000 Hi, It seems clear that the new authentication objects are controversial. I had some concerns that the scope would expand too much, and it looks like that could happen. I don't think we signed up for modeling sshd.conf. I could also see how a user that wanted to configure CLI access using NETCO= NF scripts might be confused if the user table was in the NACM module. If the authentication objects were moved to a separate draft, then some complex procedures that Martin updated need to be undone. That means if authorization is added in the future, the NACM RFC might need to be updated as well. Getting bogged down on complex optional-to-implement data model objects is not something I have a lot of time for. ;-) Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Tuesday, October 26, 2010 4:00 PM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft On Tue, Oct 26, 2010 at 10:25:13PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Oct 26, 2010 at 11:19:50AM -0700, Randy Presuhn wrote: > > =20 > > > In my opinion, if RADIUS support is to be optional, then authenticati= on > > > details would belong in a (mercifully brief) separate document, in or= der > > > to maintain modularity. (If modularity is a goal - I'm not convinced= that > > > it really is a goal of netconf.) > >=20 > > I believe in modularity. As fas as I understand the mandatory to > > implement transport, authentication is handled by the SSH layer and > > not by NETCONF directly. In other words, there should be a YANG module > > to configure SSH and the problem is solved. >=20 > But configuration of an SSH server in general is a much bigger task > than configuration of SSH on a typical networking device that can be > configured with NETCONF. But I do at the end configure sshd on NETCONF servers I happen to have. So why not try to have a minimal SSH configuration model that can be extended with more features? Does it match reality to have some SSH config in a NETCONF access control model, some in an SNMP transport model, and the rest elsewhere? How is an implementation expected to resolve conflicts? I am also concerned about /nacm/authentication/user - I consider local accounts a system property, not specifically a NETCONF property. Is this /nacm/authentication/user covering all accounts on a system or only a proper subset that is allowed to be used by NETCONF? On my system, RADIUS is also not really a property of NETCONF; it is PAM that takes care of how a password is validated and whether it is sent to a RADIUS server. In other words, sshd calls PAM and the PAM config tells whether RADIUS is involved and if so, the PAM RADIUS config tells how to talk to the right RADIUS server. We can pretend all this is not happening. But then, what do we do if someone has to configure a different protocol that authenticates in a similar way via RADIUS? Are we expecting them to use or augment /nacm/authentication/user? Or do they do their own little thing, leaving it to surprises if things collide and fail in non-obvious ways? My proposal back in Maastricht was to remove the authentication material from NACM so that this module can focus on the access control decision and the document can move on according to schedule. The notion of system accounts (=3D local users) and account authentication can be taken up as part of a core system model in NETMOD. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Tue Oct 26 23:37:49 2010 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 3DAED3A67D1 for ; Tue, 26 Oct 2010 23:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, 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 Y7gCI5qjax5X for ; Tue, 26 Oct 2010 23:37:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1BA8B3A67F6 for ; Tue, 26 Oct 2010 23:37:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,244,1286164800"; d="scan'208";a="246276893" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Oct 2010 02:38:59 -0400 X-IronPort-AV: E=Sophos;i="4.58,244,1286164800"; d="scan'208";a="529684539" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Oct 2010 02:38:21 -0400 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: Wed, 27 Oct 2010 08:37:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENT: Thread-Index: Act1f8X0ytxwGguMR6awsyXFsc1YSwAIZzqg From: "Romascanu, Dan (Dan)" To: "netconf" Subject: [Netconf] FW: COMMENT: 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, 27 Oct 2010 06:37:49 -0000 Hi Andy, Please address the issues raised by Peter in his COMMENT.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, October 27, 2010 4:35 AM To: iesg@ietf.org Cc: draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: COMMENT: Comment: 1. I would like to echo Alexey's "discuss-discuss". 2. It's not clear why the 'default' attribute qualified by the "urn:ietf:params:xml:ns:netconf:default:1.0" namespace is called "the 'wd:default' attribute"; does this assume that the attribute will always be prefixed with "wd:"? If so, why? 3. The text mentions that a server will check if default=3D"true", but = the boolean datatype in XML Schema Part 2 has two lexical representations for logical TRUE (both "true" and "1" are valid). An implementation note might be appropriate, such as: In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes,=20 the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept of false and the strings "1" and=20 "true" for the concept of true; implementations MUST support both styles=20 of lexical representation. From j.schoenwaelder@jacobs-university.de Tue Oct 26 23:43:01 2010 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 E73493A681F for ; Tue, 26 Oct 2010 23:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FnG9Go5GcMwb for ; Tue, 26 Oct 2010 23:42:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F03C43A6879 for ; Tue, 26 Oct 2010 23:42:55 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BB57C0017; Wed, 27 Oct 2010 08:44:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yxNmntXzhQkh; Wed, 27 Oct 2010 08:44:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CCCAC0008; Wed, 27 Oct 2010 08:44:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E669C1582AE0; Wed, 27 Oct 2010 08:44:04 +0200 (CEST) Date: Wed, 27 Oct 2010 08:44:04 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101027064404.GB74829@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <20101026.093846.100862283.mbj@tail-f.com> <001701cb753a$707ec420$6801a8c0@oemcomputer> <20101026182215.GA73918@elstar.local> <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> 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] NACM draft 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: Wed, 27 Oct 2010 06:43:01 -0000 On Tue, Oct 26, 2010 at 04:22:06PM -0700, Andy Bierman wrote: > If the authentication objects were moved to a separate draft, then > some complex procedures that Martin updated need to be undone. > That means if authorization is added in the future, the NACM RFC might > need to be updated as well. I can't follow. Can you be precise? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Oct 27 00:42:51 2010 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 C5B073A677E for ; Wed, 27 Oct 2010 00:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.200, 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 wbB+A8XFjR8i for ; Wed, 27 Oct 2010 00:42:50 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 35C533A69BC for ; Wed, 27 Oct 2010 00:42:49 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F336D616005; Wed, 27 Oct 2010 09:44:37 +0200 (CEST) Date: Wed, 27 Oct 2010 09:44:37 +0200 (CEST) Message-Id: <20101027.094437.04364904.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101026225944.GD74170@elstar.local> References: <20101026182215.GA73918@elstar.local> <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> 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] NACM draft 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, 27 Oct 2010 07:42:51 -0000 Hi, Juergen Schoenwaelder wrote: > On Tue, Oct 26, 2010 at 10:25:13PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Oct 26, 2010 at 11:19:50AM -0700, Randy Presuhn wrote: > > > > > > > In my opinion, if RADIUS support is to be optional, then authentication > > > > details would belong in a (mercifully brief) separate document, in order > > > > to maintain modularity. (If modularity is a goal - I'm not convinced that > > > > it really is a goal of netconf.) > > > > > > I believe in modularity. As fas as I understand the mandatory to > > > implement transport, authentication is handled by the SSH layer and > > > not by NETCONF directly. In other words, there should be a YANG module > > > to configure SSH and the problem is solved. > > > > But configuration of an SSH server in general is a much bigger task > > than configuration of SSH on a typical networking device that can be > > configured with NETCONF. > > But I do at the end configure sshd on NETCONF servers I happen to > have. This is one deployment scenario, but there are also systems that use embedded ssh stacks integrated with the NETCONF server. Both scenarios should be supported. > So why not try to have a minimal SSH configuration model that > can be extended with more features? Does it match reality to have some > SSH config in a NETCONF access control model, some in an SNMP > transport model, and the rest elsewhere? No, I agree. > I am also concerned about /nacm/authentication/user - I consider local > accounts a system property, not specifically a NETCONF property. Is > this /nacm/authentication/user covering all accounts on a system or > only a proper subset that is allowed to be used by NETCONF? I agree it make sense to move this to /system, for example. But at the same time, I don't think we should do a model for configuration of any user account. There are many parameters to configure, and they depend on the OS and services available. > On my system, RADIUS is also not really a property of NETCONF; it is > PAM that takes care of how a password is validated and whether it is > sent to a RADIUS server. In other words, sshd calls PAM and the PAM > config tells whether RADIUS is involved and if so, the PAM RADIUS > config tells how to talk to the right RADIUS server. We can pretend > all this is not happening. But then, what do we do if someone has to > configure a different protocol that authenticates in a similar way via > RADIUS? Are we expecting them to use or augment > /nacm/authentication/user? Or do they do their own little thing, > leaving it to surprises if things collide and fail in non-obvious > ways? On most embedded system, even if PAM is used behind the scenes, it is not obvious that the operator directly configures PAM from the CLI or over NETCONF. > My proposal back in Maastricht was to remove the authentication > material from NACM so that this module can focus on the access control > decision and the document can move on according to schedule. The > notion of system accounts (= local users) and account authentication > can be taken up as part of a core system model in NETMOD. Ok. /martin From j.schoenwaelder@jacobs-university.de Wed Oct 27 00:48:29 2010 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 67E333A6821 for ; Wed, 27 Oct 2010 00:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.04 X-Spam-Level: X-Spam-Status: No, score=-102.04 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ly9mkQyscpdg for ; Wed, 27 Oct 2010 00:48:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 42AA83A677E for ; Wed, 27 Oct 2010 00:48:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5E21C000D; Wed, 27 Oct 2010 09:50:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m+p2N42iTANt; Wed, 27 Oct 2010 09:50:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16BC6C0006; Wed, 27 Oct 2010 09:50:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E33261582DFA; Wed, 27 Oct 2010 09:49:36 +0200 (CEST) Date: Wed, 27 Oct 2010 09:49:36 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101027074936.GA75161@elstar.local> Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netconf@ietf.org References: <20101026182215.GA73918@elstar.local> <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> <20101027.094437.04364904.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027.094437.04364904.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft 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: Wed, 27 Oct 2010 07:48:29 -0000 On Wed, Oct 27, 2010 at 09:44:37AM +0200, Martin Bjorklund wrote: > On most embedded system, even if PAM is used behind the scenes, it is > not obvious that the operator directly configures PAM from the CLI or > over NETCONF. True. The challenge of writing configuration models is to make them flexible enough so that different systems can be supported. Getting this right is hard. But lets at least try. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Oct 27 00:56:06 2010 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 3C4DE3A69D8 for ; Wed, 27 Oct 2010 00:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.189, 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 kGrMOQJgooqs for ; Wed, 27 Oct 2010 00:56:05 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 598803A69D4 for ; Wed, 27 Oct 2010 00:52:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D1DF7616005; Wed, 27 Oct 2010 09:54:43 +0200 (CEST) Date: Wed, 27 Oct 2010 09:54:42 +0200 (CEST) Message-Id: <20101027.095442.33604042.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> 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] NACM draft 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, 27 Oct 2010 07:56:06 -0000 Hi, Andy Bierman wrote: > If the authentication objects were moved to a separate draft, then > some complex procedures that Martin updated need to be undone. Yes. The current NACM spec gives access to a session from a set of group names. If we move authentication, will the NACM spec leave it as an implementation-specific matter how users are mapped to groups? Or will we have a NETCONF-specific mapping from user names to groups? (and a SNMP-specific mapping, and CLI-specifc mapping, etc). If we have such protocol specific mappings, does that mean that RADIUS, or other mechanisms, cannot be used to do the mapping? /martin From randy_presuhn@mindspring.com Wed Oct 27 02:11:43 2010 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 A93F33A67E1 for ; Wed, 27 Oct 2010 02:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 L6JiiKpMTbpR for ; Wed, 27 Oct 2010 02:11:42 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 5AB3F3A6905 for ; Wed, 27 Oct 2010 02:11:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hQ+prjj5fzvXSPjdNQe25c57zyQQ3R/aPoF6RvXYN9M4Tf2y1nT7VvezUV7+7tNT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.7.86] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PB24Z-0002cr-8g for netconf@ietf.org; Wed, 27 Oct 2010 05:13:31 -0400 Message-ID: <012801cb75b7$71acb500$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20101026.222513.144818361.mbj@tail-f.com><20101026225944.GD74170@elstar.local> <20101027.095442.33604042.mbj@tail-f.com> Date: Wed, 27 Oct 2010 02:15:03 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fed4aa06435005a5a5d907830d3ec517f1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.7.86 Subject: Re: [Netconf] NACM draft 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, 27 Oct 2010 09:11:43 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, October 27, 2010 12:54 AM > Subject: Re: [Netconf] NACM draft ... > Yes. The current NACM spec gives access to a session from a set of > group names. If we move authentication, will the NACM spec leave it > as an implementation-specific matter how users are mapped to groups? > Or will we have a NETCONF-specific mapping from user names to groups? > (and a SNMP-specific mapping, and CLI-specifc mapping, etc). If we > have such protocol specific mappings, does that mean that RADIUS, or > other mechanisms, cannot be used to do the mapping? ... Ignoring session authorization for the moment, I think there are three interesting cases to consider: (a) the authentication mechanism is able to determine the group mapping (RADIUS) (b) the user/group mapping for a particular authentication mechanism will be configurable via netconf, but is peculiar to that mechanism. (c) the authentication mechanism does not not provide a mapping, but does provide a user name. (a) by itself is trivial. (c) could be handled in two ways - by a (1) user/group mapping "table" associated with the mechanism, or a (2) mechanism/user/group mapping table associated with netconf. (1) seems simpler until one starts thinking about managing access control for this access control policy information. (2) has the advantage of allowing a consistent, integrated discussion of of how conflicts between (a) and the configuration are to be handled. (b) could get really ugly if the protocol used by the mechanism can also carry group mapping information, since the user/group conflict resolution policy would potentially be mechanism-specific. Such flexibility would be a trap for the unwary, and would also require the most specification effort. I think this could all be made to work with something like the following: - service interface to netconf provides mechanism identifer, authenticated user name, and optional group mapping provided by mechanism - netconf looks up (mechanism, user) tuple in its configured group mappings determines configured group, if any - if no group was provided by the service, and no group found in the mappings, then categorical DENY. - if group provided by service, and no group found in the mappings, use that group. - if group provided by mappings, and none provided by the service, use that group. - if group provided by service and group provided by mapping are the same, use that group, otherwise (if group provided by service and group provided by mapping are different) apply netconf's conflict resolution algorithm (whatever it might be) But this is roughly how RADIUS/ VACM works. However, I think the conflict resolution part is potentially harder in netconf land, if we admit the possibility that a conflict resolution process could potentially result in operational state at odds with configuration data. (In RADIUS/VACM, configuration takes precedence over what the mechanism says, avoiding the problem.) Randy From j.schoenwaelder@jacobs-university.de Wed Oct 27 02:13:23 2010 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 1080D3A6905 for ; Wed, 27 Oct 2010 02:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 R-OEOtDzbtAp for ; Wed, 27 Oct 2010 02:13:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 637FC3A696C for ; Wed, 27 Oct 2010 02:13:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50C89C0006; Wed, 27 Oct 2010 11:15:10 +0200 (CEST) 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 l1viWnZmya99; Wed, 27 Oct 2010 11:15:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98A05C000D; Wed, 27 Oct 2010 11:15:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6F2CF1582F9C; Wed, 27 Oct 2010 11:14:31 +0200 (CEST) Date: Wed, 27 Oct 2010 11:14:31 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101027091431.GD73493@elstar.local> Mail-Followup-To: Martin Bjorklund , biermana@Brocade.com, netconf@ietf.org References: <20101026.222513.144818361.mbj@tail-f.com> <20101026225944.GD74170@elstar.local> <20101027.095442.33604042.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027.095442.33604042.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] NACM draft 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: Wed, 27 Oct 2010 09:13:23 -0000 On Wed, Oct 27, 2010 at 09:54:42AM +0200, Martin Bjorklund wrote: > Yes. The current NACM spec gives access to a session from a set of > group names. If we move authentication, will the NACM spec leave it > as an implementation-specific matter how users are mapped to groups? > Or will we have a NETCONF-specific mapping from user names to groups? > (and a SNMP-specific mapping, and CLI-specifc mapping, etc). That is a good question to discuss. Perhaps the answer can be found by looking what implementations commonly do. > If we have such protocol specific mappings, does that mean that > RADIUS, or other mechanisms, cannot be used to do the mapping? For SNMP, there is an ID describing how RADIUS can influence the user to group mapping. So I do not see why this "cannot" be done if there are protocol specific user to group mappings. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Oct 27 05:39:14 2010 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 AEFAA3A69F5 for ; Wed, 27 Oct 2010 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 SBydYjjhe3dp for ; Wed, 27 Oct 2010 05:39:10 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 2B4E33A69F1 for ; Wed, 27 Oct 2010 05:39:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTMgd12wAoL2/+P7LU0a7nHz9pmxXe15I@postini.com; Wed, 27 Oct 2010 05:41:00 PDT 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; Wed, 27 Oct 2010 05:36:46 -0700 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 o9RCakU87960; Wed, 27 Oct 2010 05:36:46 -0700 (PDT) (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 o9RCFiiQ008572; Wed, 27 Oct 2010 12:15:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010271215.o9RCFiiQ008572@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20101027.094437.04364904.mbj@tail-f.com> Date: Wed, 27 Oct 2010 08:15:44 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft 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, 27 Oct 2010 12:39:15 -0000 Martin Bjorklund writes: >I agree it make sense to move this to /system, for example. FWIW: in JUNOS, we put local services under /system/services/ so netconf is under /system/services/netconf and ssh is under /system/services/ssh. These are protocols that are local to the box, rather than part of the box's role in the network, which are under /protocols/. It would be _very_ nice if we had some sort of understanding (and over-arching organization) for how we want ietf standards to mesh, rather than just "wild west" style where everything ends up in the root. >But at >the same time, I don't think we should do a model for configuration of >any user account. There are many parameters to configure, and they >depend on the OS and services available. It seems you really need to decide if you are configuring NETCONF users or users that might happen to use NETCONF. My experience is that most operators will want the latter. IIRC one of the "wins" for using ssh was reusing existing infrastructure (deployed ssh keys) so this view of configuring NETCONF users would lose that. Unless your model has a big boolean leaf that says "use-your-real-users". >On most embedded system, even if PAM is used behind the scenes, it is >not obvious that the operator directly configures PAM from the CLI or >over NETCONF. If the operator doesn't configure it, who does? Or are you saying this is sometimes hard coded and your model needs to reflect that (via "feature")? FWIW: In JUNOS, this is done with the following config: system { authentication-order [ radius password ]; radius-server { 10.1.2.3 secret "$9$SfPe87bs4Ui.X7s4"; ## SECRET-DATA 10.1.3.2 secret "$9$GOimTn/t1EyfT/t"; ## SECRET-DATA } } Where "authentication-order" controls the order in which the authentication methods are attempted (pam.conf) and the radius servers are (in order) the servers used (radius.conf). (In JUNOS we write this information to the standard UNIX files and run the stock UNIX daemons and libraries) (which makes life so much simpler). s/radius/tacplus/ for TACACS+ support. In a YANG-based model, this might look something like: 10.1.2.3 $9$SfPe87bs4Ui.X7s4 10.1.3.2 $9$GOimTn/t1EyfT/t Thanks, Phil From mbj@tail-f.com Wed Oct 27 06:23:28 2010 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 2B65D3A6953 for ; Wed, 27 Oct 2010 06:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.179, 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 C98dbQuVAFIX for ; Wed, 27 Oct 2010 06:23:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DF5853A6A1C for ; Wed, 27 Oct 2010 06:23:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 08030616012; Wed, 27 Oct 2010 15:25:15 +0200 (CEST) Date: Wed, 27 Oct 2010 15:25:12 +0200 (CEST) Message-Id: <20101027.152512.74513715.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201010271215.o9RCFiiQ008572@idle.juniper.net> References: <20101027.094437.04364904.mbj@tail-f.com> <201010271215.o9RCFiiQ008572@idle.juniper.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] NACM draft 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, 27 Oct 2010 13:23:28 -0000 Phil Shafer wrote: > >But at > >the same time, I don't think we should do a model for configuration of > >any user account. There are many parameters to configure, and they > >depend on the OS and services available. > > It seems you really need to decide if you are configuring NETCONF > users or users that might happen to use NETCONF. My experience is > that most operators will want the latter. IIRC one of the "wins" > for using ssh was reusing existing infrastructure (deployed ssh > keys) so this view of configuring NETCONF users would lose that. What is "this view"? If we move the user authentication to /system, we would configure users that might happen to use NETCONF. So I think we agree. > >On most embedded system, even if PAM is used behind the scenes, it is > >not obvious that the operator directly configures PAM from the CLI or > >over NETCONF. > > If the operator doesn't configure it, who does? There is one simple model which gets mapped by the implementation on the device to PAM config files and whatnot. This seems to be what you are doing as well. It is not possible to tune all PAM knobs in this simple model. In fact, the operator might not even know that PAM is used in the implementation. /martin From phil@juniper.net Wed Oct 27 07:12:24 2010 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 2F3263A6A3F for ; Wed, 27 Oct 2010 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 W54Zzi4nVWIQ for ; Wed, 27 Oct 2010 07:12:23 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id BADFF3A6A42 for ; Wed, 27 Oct 2010 07:03:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTMgxt8ksJMdwe6KyRffDWnNDS1hY9Gim@postini.com; Wed, 27 Oct 2010 07:05:50 PDT 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; Wed, 27 Oct 2010 07:01:06 -0700 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 o9RE15U23320; Wed, 27 Oct 2010 07:01:06 -0700 (PDT) (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 o9RDe4Rs009451; Wed, 27 Oct 2010 13:40:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010271340.o9RDe4Rs009451@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20101027.152512.74513715.mbj@tail-f.com> Date: Wed, 27 Oct 2010 09:40:04 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM draft 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, 27 Oct 2010 14:12:24 -0000 Martin Bjorklund writes: >What is "this view"? If we move the user authentication to /system, >we would configure users that might happen to use NETCONF. So I think >we agree. Cool. >There is one simple model which gets mapped by the implementation on >the device to PAM config files and whatnot. This seems to be what you >are doing as well. It is not possible to tune all PAM knobs in this >simple model. In fact, the operator might not even know that PAM is >used in the implementation. Yup, since PAM is an internal-to-the-box software interface, the user should remain blissfully ignorant of it. But the model needs to reflect the functionality that it offers, since this is driven by operator needs. Thanks, Phil From biermana@Brocade.com Wed Oct 27 10:36:47 2010 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 40B6C3A68B1 for ; Wed, 27 Oct 2010 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=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 6qjcoiv446XW for ; Wed, 27 Oct 2010 10:36:46 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id C9E003A6888 for ; Wed, 27 Oct 2010 10:36:45 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9RHaKel019178; Wed, 27 Oct 2010 10:38:35 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s6p7fr3mk-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Oct 2010 10:38:34 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 10:43:47 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 27 Oct 2010 10:38:32 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" , netconf Date: Wed, 27 Oct 2010 10:38:31 -0700 Thread-Topic: COMMENT: Thread-Index: Act1f8X0ytxwGguMR6awsyXFsc1YSwAIZzqgABbRjTA= Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-27_08:2010-10-27, 2010-10-27, 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-1004200000 definitions=main-1010270084 X-Proofpoint-SSN: Sensitivity2 Subject: Re: [Netconf] COMMENT: 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, 27 Oct 2010 17:36:47 -0000 Hi, 1) The complexity that the client has to deal with is minimal. The 'merge' and 'remove' operations can be used instead of 'create' and 'delete', for example. In this case, the with-defaults behavior is irrelevant.=20 2) The default attribute needs to be qualified since it can appear anywhere in the configuration data. The prefix wd: is not intended to imply or require any particular XML encoding. Any legal XML encoding is allowed. Since you were confused by this, maybe it will help to s/wd:default/default. 3) I will add text that says the xs:boolean values '0' and '1' must be supported for the default attribute value. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Romascanu, Dan (Dan) Sent: Tuesday, October 26, 2010 11:38 PM To: netconf Subject: [Netconf] FW: COMMENT: Hi Andy, Please address the issues raised by Peter in his COMMENT.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, October 27, 2010 4:35 AM To: iesg@ietf.org Cc: draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: COMMENT: Comment: 1. I would like to echo Alexey's "discuss-discuss". 2. It's not clear why the 'default' attribute qualified by the "urn:ietf:params:xml:ns:netconf:default:1.0" namespace is called "the 'wd:default' attribute"; does this assume that the attribute will always be prefixed with "wd:"? If so, why? 3. The text mentions that a server will check if default=3D"true", but the boolean datatype in XML Schema Part 2 has two lexical representations for logical TRUE (both "true" and "1" are valid). An implementation note might be appropriate, such as: In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes,=20 the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept of false and the strings "1" and=20 "true" for the concept of true; implementations MUST support both styles=20 of lexical representation. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Wed Oct 27 10:59:49 2010 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 83A113A6888; Wed, 27 Oct 2010 10:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.132, 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 xbiic6rjlLGL; Wed, 27 Oct 2010 10:59:48 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 9BF8D3A6803; Wed, 27 Oct 2010 10:59:48 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9RHtpMC015752; Wed, 27 Oct 2010 11:01:38 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s6ruyg079-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Oct 2010 11:01:38 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 11:06:52 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 27 Oct 2010 11:01:37 -0700 From: Andy Bierman To: Robert Sparks , "iesg@ietf.org" Date: Wed, 27 Oct 2010 11:01:35 -0700 Thread-Topic: DISCUSS and COMMENT: Thread-Index: Act1/19iGIzOdVubQuW+fVFEt33h3AAAC9Nw Message-ID: References: <20101027174800.28832.62936.idtracker@localhost> In-Reply-To: <20101027174800.28832.62936.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-27_08:2010-10-27, 2010-10-27, 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-1004200000 definitions=main-1010270089 X-Proofpoint-SSN: Sensitivity2 Cc: "draft-ietf-netconf-with-defaults@tools.ietf.org" , netconf , "netconf-chairs@tools.ietf.org" Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 27 Oct 2010 17:59:49 -0000 SGksDQoNCjEpICBUaGUgV0cgY291bGQgbm90IGZvcmNlIHNvbWUgdmVuZG9ycyB0byByZXdyaXRl IGRlZmF1bHRzIHVzaW5nIHRoZQ0KICAgIGltcGxlbWVudGF0aW9uIGNob2ljZXMgb2Ygb3RoZXIg dmVuZG9ycy4gIFRoZXJlIGlzIG5vICdiZXN0Jw0KICAgIGRlZmF1bHRzIGhhbmRsaW5nIG1vZGUu ICBUaGVyZSB3YXMgYW4gYXR0ZW1wdCB0byBmb3JjZSBhbGwgdmVuZG9ycw0KICAgIHRvIGNob29z ZSBhbiBhcmJpdHJhcnkgbW9kZSBidXQgdGhpcyB3YXMgbm90IHN1Y2Nlc3NmdWwuDQoNCjIpIFRo aXMgaXMgYWxyZWFkeSBmaXhlZC4gIFNlZSBwcmV2aW91cyBjb21tZW50cy4gIFRoZSBwaHJhc2Ug IklmIHRoZSAnZm9vJw0KICAgYmFzaWMgbW9kZSBpcyB1c2VkIiB3aWxsIGJlIGFkZGVkIHRvIGVh Y2ggc2VudGVuY2UgdG8gbWFrZSBpdCBjbGVhciANCiAgIHRoZSByZXF1aXJlbWVudCBvbmx5IGFw cGxpZXMgaWYgdGhlIHBhcnRpY3VsYXIgYmFzaWMgbW9kZSBpcyB1c2VkLg0KDQozKSBUaGlzIGlz IGEgY2FwYWJpbGl0eSBleHRlbnNpb24uICBJdCBkb2VzIG5vdCB1cGRhdGUgb3IgY2hhbmdlIDQ3 NDFiaXMNCiAgIGNvbXBsaWFuY2UuICBJIGRvIG5vdCBzZWUgYW55IHByb2JsZW0gd2l0aCBzZWMu IDQuMywgYnV0IEkgY2FuIHJlbW92ZQ0KICAgdGhpcyBzZWN0aW9uLiAgQSBzZXJ2ZXIgdGhhdCBp bXBsZW1lbnRzIHRoaXMgY2FwYWJpbGl0eSBpcyByZXF1aXJlZA0KICAgdG8gcHJvY2VzcyBkZWZh dWx0cyBhY2NvcmRpbmcgdG8gdGhlIHNwZWMuICBTaW5jZSBORVRDT05GIHBsYWNlcw0KICAgbm8g cmVxdWlyZW1lbnRzIG9uIHRoZSBjb250ZW50IGxheWVyLCBhbnkgc2VydmVyIG5vdCBpbXBsZW1l bnRpbmcNCiAgIHRoaXMgY2FwYWJpbGl0eSBpcyBhbGxvd2VkIHRvIHByb2Nlc3MgZGVmYXVsdHMg YW55IHdheSB0aGV5IHdhbnQuDQogICBUaGVyZSBpcyBubyBhdHRlbXB0IHRvIGNoYW5nZSB0aGUg Y29uZm9ybWFuY2Ugb2YgYSBORVRDT05GIHNlcnZlcg0KICAgdGhhdCBkb2VzIG5vdCBpbXBsZW1l bnQgdGhpcyBjYXBhYmlsaXR5Lg0KDQoNCkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXSAN ClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyNywgMjAxMCAxMDo0OCBBTQ0KVG86IGllc2dAaWV0 Zi5vcmcNCkNjOiBuZXRjb25mLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRj b25mLXdpdGgtZGVmYXVsdHNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IERJU0NVU1MgYW5kIENP TU1FTlQ6IDxkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMi50eHQ+DQoNCkRpc2N1 c3M6DQoxKSBCdWlsZGluZyBvbiBBbGV4ZXkncyBkaXNjdXNzIC0gYXMgd3JpdHRlbiwgdGhpcyBk b2N1bWVudCByZXF1aXJlcyBhbnkNCmNsaWVudCB0aGF0IGNhcmVzIGFib3V0IGhvdyBkZWZhdWx0 cyBhcmUgaGFuZGxlZCB0byBpbXBsZW1lbnQgYWxsIHRocmVlDQooZm91cj8pIG1vZGVzLiBJdCB3 b3VsZCBoZWxwIHRvIGV4cGxpY2l0bHkgY2FsbCB0aGF0IG91dCBpbiB0aGUgdGV4dC4gIERpZCB0 aGUgDQpncm91cCBjb25zaWRlciBtYWtpbmcgb25lIG9mIHRoZSBtb2RlcyBtYW5kYXRvcnkgdG8g aW1wbGVtZW50IGF0IHRoZSANCnNlcnZlciAoZm9yIGluc3RhbmNlLCBtYWtpbmcgdGhlIFNIT1VM RCBpbiB0aGUgdGhpcmQgYnVsbGV0IG9mIDQuMSBhIE1VU1QpPw0KSWYgc28sIGNvdWxkIHRoZSBy ZWFzb25zIGZvciBub3QgZG9pbmcgc28gYmUgYmV0dGVyIGNhcHR1cmVkIGluIHRoZSBkb2N1bWVu dD8gDQoNCjIpIFRoZSBwaHJhc2luZyBvZiAyLjEuMiwgMi4yLjIsIGFuZCAyLjMuMiBpcyBhbWJp Z3VvdXMuIER1cmluZyBhIGNvbnZlcnNhdGlvbg0Kd2l0aCBEYW4sIEkgd2FzIGNvbnZpbmNlZCB0 aGF0IHRoZSBpbnRlbnQgd2FzIHRvIG1ha2UgdGhlbSBzdWJvcmRpbmF0ZSB0bw0KdGhlIHJlcXVp cmVtZW50IGF0IHRoZSB0b3Agb2Ygc2VjdGlvbiAyIHRoYXQgYSBzZXJ2ZXIgbXVzdCBwaWNrIG9u ZSBvZiB0aGUNCnRocmVlIGJhc2ljIG1vZGVzLCBhbmQgdGhhdCAyLjEuMiBzaG91bGQgYmUgcmVh ZCBhcw0KDQoiSWYgdGhlIHNlcnZlciBzdXBwb3J0cyB0aGUgJ3JlcG9ydC1hbGwnIG1vZGUgZm9y IGhhbmRsaW5nIGRlZmF1bHQgZGF0YSwNCmFuZCB0aGUgY2xpZW50IGhhcyByZXF1ZXN0ZWQgaXQg Ynkgc3BlY2lmeWluZyAncmVwb3J0LWFsbCcgd2hlbiB1c2luZw0KPHdpdGgtZGVmYXVsdHM+LCB0 aGVuIHRoZSBzZXJ2ZXIgTVVTVCBiZWhhdmUgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gMy4xIg0K DQphbmQgbm90IGFzDQoNCiJUaGUgc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgJ3JlcG9ydC1hbGwn IG1vZGUuDQoNCklmIHRoYXQncyBjb3JyZWN0LCBwbGVhc2UgYWRqdXN0IHRoZSB0ZXh0IHRvIG1h a2UgaXQgbGVzcyBsaWtlbHkgdGhhdA0Kc29tZW9uZSB3aWxsIG1pc2ludGVycHJldCB0aGUgcmVx dWlyZW1lbnQuIChJIHRob3VnaHQgMi4xLjIgYW5kIHRoZQ0KdGhpcmQgYnVsbGV0IG9mIDQuMSB3 ZXJlIGluIGNvbmZsaWN0IGJlZm9yZSB0aGUgY29udmVyc2F0aW9uIHdpdGgNCkRhbiBtZW50aW9u ZWQgYWJvdmUpLg0KDQozKSBTZWN0aW9uIDQuMyBhcyB3cml0dGVuIGlzIHVwZGF0aW5nIHRoZSBi YXNlIE5FVENPTkYgc3BlYy4gV2FzIHRoZSBpbnRlbnQgaXMNCnRvIGFkZCBhIHJlcXVpcmVtZW50 IHRvIHRoZSBiYXNlIHByb3RvY29sLCBhZmZlY3RpbmcgY29uZm9ybWFuY2Ugb2YgZXhpc3RpbmcN CmltcGxlbWVudGF0aW9ucywgb3Igb25seSB0byBwcm9tb3RlIGFkb3B0aW9uIG9mIHRoaXMgZXh0 ZW5zaW9uPyBJZiB0aGUgZm9ybWVyLA0KdGhlIGRvY3VtZW50IG5lZWRzIGFuICJVcGRhdGVzIiBo ZWFkZXIuIElmIHRoZSBsYXR0ZXIsIHBsZWFzZSByZW1vdmUgb3IgcmVwaHJhc2UNCnRoaXMgc2Vj dGlvbi4NCg0KQ29tbWVudDoNClRoZXJlIGlzIGEgYnVnIGluIDIuMi4yIC0gaXQgcG9pbnRzIHRv IDMuMSBpbnN0ZWFkIG9mIDMuMg0KDQoNCg== From biermana@Brocade.com Wed Oct 27 12:28:36 2010 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 002533A6803 for ; Wed, 27 Oct 2010 12:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.126, 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 b-U897ZgiLRP for ; Wed, 27 Oct 2010 12:28:35 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id E1E0D3A6774 for ; Wed, 27 Oct 2010 12:28:34 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9RJGVa4025000; Wed, 27 Oct 2010 12:30:22 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s6sdt81c3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Oct 2010 12:30:21 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 12:35:35 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 27 Oct 2010 12:30:20 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" Date: Wed, 27 Oct 2010 12:30:18 -0700 Thread-Topic: DISCUSS and COMMENT: Thread-Index: Act2CgU+AJiB+0+KTVG6/YMeuad2vgAAD7AwAACyk9A= Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-27_09:2010-10-27, 2010-10-27, 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-1004200000 definitions=main-1010270100 X-Proofpoint-SSN: Sensitivity2 Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 27 Oct 2010 19:28:36 -0000 Hi, I did answer this comment. This is from my reply on 10/26: 2.1.2: OLD: The server MUST support the parameter with a value equal to 'report-all', as specified in Section 3.1. NEW: If the 'report-all' basic mode is supported, the server MUST support=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the parameter with a value equal to 'report-all', as specified in Section 3.1. 2.2.2: The server MUST support the parameter with a value equal to 'trim', as specified in Section 3.1. NEW: If the 'trim' basic mode is supported, the server MUST support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the parameter with a value equal to 'trim', as specified in Section 3.1. 2.3.2: OLD: The server MUST support the parameter with a value equal to 'explicit', as specified in Section 3.3. NEW: If the 'explicit' basic mode is supported, the server MUST support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the parameter with a value equal to 'explicit', as specified in Section 3.3. Andy -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, October 27, 2010 12:11 PM To: Andy Bierman Cc: netconf Subject: FW: DISCUSS and COMMENT: =20 Hi Andy, Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2 also confused Robert Sparks as if they are read individually they seem to require support for each one of the individual modes and contradict the statements in sections 2 and 4.=20 Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, October 27, 2010 9:04 PM To: iesg@ietf.org Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: Discuss: The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern with Section 4 that needs to be addressed. Richard said: I'm confused by the existence of Section 4 in light of the fact that Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a value for each of the basic modes. If there are cases where a server doesn't support a given mode, what does it mean for it to "support the parameter" with a given value?=20 Comment: The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several concerns and a question. Please consider them. From dromasca@avaya.com Wed Oct 27 12:37:11 2010 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 E5F543A6910 for ; Wed, 27 Oct 2010 12:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 6ZvNaQ4TAYss for ; Wed, 27 Oct 2010 12:37:11 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CD7FF3A67B7 for ; Wed, 27 Oct 2010 12:37:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="42305704" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 27 Oct 2010 15:29:52 -0400 X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="533346305" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2010 15:11:31 -0400 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: Wed, 27 Oct 2010 21:11:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: Thread-Index: Act2CgU+AJiB+0+KTVG6/YMeuad2vgAAD7Aw From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netconf Subject: [Netconf] FW: DISCUSS and COMMENT: 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, 27 Oct 2010 19:37:12 -0000 =20 Hi Andy, Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2 also confused Robert Sparks as if they are read individually they seem to require support for each one of the individual modes and contradict the statements in sections 2 and 4.=20 Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, October 27, 2010 9:04 PM To: iesg@ietf.org Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: Discuss: The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern with Section 4 that needs to be addressed. Richard said: I'm confused by the existence of Section 4 in light of the fact that Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a value for each of the basic modes. If there are cases where a server doesn't support a given mode, what does it mean for it to "support the parameter" with a given value?=20 Comment: The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several concerns and a question. Please consider them. From dromasca@avaya.com Thu Oct 28 05:42:21 2010 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 C961B3A69BE for ; Thu, 28 Oct 2010 05:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 nGp1DUoZD7Hd for ; Thu, 28 Oct 2010 05:42:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B107A3A69B8 for ; Thu, 28 Oct 2010 05:42:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,251,1286164800"; d="scan'208";a="215537561" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2010 08:44:09 -0400 X-IronPort-AV: E=Sophos;i="4.58,251,1286164800"; d="scan'208";a="530581892" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Oct 2010 08:44:08 -0400 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: Thu, 28 Oct 2010 14:43:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENT: Thread-Index: Act2mLIZHGkQGLTTTnOIDhRxV+Fn1QABPwXQ From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netconf Subject: [Netconf] FW: COMMENT: 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, 28 Oct 2010 12:42:21 -0000 Hi Andy, Please address the issue raised by Tim in his comment.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Tim Polk Sent: Thursday, October 28, 2010 2:05 PM To: iesg@ietf.org Subject: COMMENT: Comment: I could not understand the meaning of Section 2.3.1. I suggest revising it for symmetry with sections 2.1.1 and 2.2.1, which I thought were very clear. I have proposed text which is probably wrong (since I had trouble with the current text) but at least illustrates what I am suggesting... OLD If a client sets a data node to its schema default value, it MUST always be reported. If the server sets a data node to its schema default value, it MUST NOT be reported. Non-configuration data nodes containing the schema default value MUST be reported. NEW When data is retrieved from a server using the 'explicit' basic mode, and the parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST NOT be reported. From dromasca@avaya.com Thu Oct 28 06:40:32 2010 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 13BC63A683C for ; Thu, 28 Oct 2010 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 zoyeo27CYe50 for ; Thu, 28 Oct 2010 06:40:30 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 93DA93A67F6 for ; Thu, 28 Oct 2010 06:40:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,252,1286164800"; d="scan'208";a="42628428" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 Oct 2010 09:42:09 -0400 X-IronPort-AV: E=Sophos;i="4.58,252,1286164800"; d="scan'208";a="530622186" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Oct 2010 09:41:33 -0400 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: Thu, 28 Oct 2010 15:41:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: Thread-Index: Act2ooogywNcUjA3TI6t14IxFCVvUgAAyneQ From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netconf Subject: [Netconf] FW: DISCUSS: 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, 28 Oct 2010 13:40:32 -0000 Hi Andy, Please address the issue raised by Adrian in his DISCUSS.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, October 28, 2010 3:16 PM To: iesg@ietf.org Subject: DISCUSS: Discuss: In a Discuss related to Alexey's, I am not clear about the "requirements" placed on servers and clients in this specification. Is the intention to say that "implementations conforming to this sepcification" should/must do stuff. Or, as the language of the I-D implies, "[new] implementations of Netconf" should/must do things? The former case really needs a little clarification in the text. The latter case implies that this I-D updates the Netconf spec. For example: 4.3. Conformance Every NETCONF server SHOULD implement this capability. which seems to conflict in tone from... 4.1... A NETCONF server implementing the :with-defaults capability: o MUST indicate its basic mode behavior by including the 'basic- mode' parameter in the capability URI, as defined in Section 4.4. o MUST support the YANG module defined in Section 5. o SHOULD support the 'report-all' or 'report-all-tagged' defaults handling mode. o MAY support additional defaults handling modes. I don't think this is a big deal, but you need to work out exactly what you are requiring, and then make a few tweaks accordingly. From biermana@Brocade.com Thu Oct 28 09:31:30 2010 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 6044B3A68EB for ; Thu, 28 Oct 2010 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.124, 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 wHuIdOo8ygai for ; Thu, 28 Oct 2010 09:31:29 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 55B143A6900 for ; Thu, 28 Oct 2010 09:31:29 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9SGMR3I028440; Thu, 28 Oct 2010 09:33:19 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s7b37r2hx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Oct 2010 09:33:19 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 28 Oct 2010 09:38:32 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 28 Oct 2010 09:33:18 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" Date: Thu, 28 Oct 2010 09:33:16 -0700 Thread-Topic: COMMENT: Thread-Index: Act2mLIZHGkQGLTTTnOIDhRxV+Fn1QABPwXQAAeZ46A= Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-28_08:2010-10-28, 2010-10-28, 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-1004200000 definitions=main-1010280060 X-Proofpoint-SSN: Sensitivity2 Cc: netconf Subject: Re: [Netconf] COMMENT: 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, 28 Oct 2010 16:31:30 -0000 Hi, OK, except s/MUST NOT/MUST/. You changed the semantics. When data is retrieved from a server using the 'explicit' basic mode, And the parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST be reported. Since the server explicitly sets all non-configuration data, none of it is considered default. Perhaps a basic mode summary would help in the=20 draft, ala: Trim mode: * A default is only based on the schema default value. Explicit mode: * A default is only based on whether a value was actually set by the client or the server. Report-all: * There is no concept of a missing node represented by a default. Every node that can exist, does exist. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Romascanu, Dan (Dan) Sent: Thursday, October 28, 2010 5:44 AM To: Andy Bierman Cc: netconf Subject: [Netconf] FW: COMMENT: Hi Andy, Please address the issue raised by Tim in his comment.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Tim Polk Sent: Thursday, October 28, 2010 2:05 PM To: iesg@ietf.org Subject: COMMENT: Comment: I could not understand the meaning of Section 2.3.1. I suggest revising it for symmetry with sections 2.1.1 and 2.2.1, which I thought were very clear. I have proposed text which is probably wrong (since I had trouble with the current text) but at least illustrates what I am suggesting... OLD If a client sets a data node to its schema default value, it MUST always be reported. If the server sets a data node to its schema default value, it MUST NOT be reported. Non-configuration data nodes containing the schema default value MUST be reported. NEW When data is retrieved from a server using the 'explicit' basic mode, and the parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST NOT be reported. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Thu Oct 28 10:01:20 2010 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 8243A3A685B for ; Thu, 28 Oct 2010 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 X0Ik8kKhF6Wo for ; Thu, 28 Oct 2010 10:01:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6F7A83A6856 for ; Thu, 28 Oct 2010 10:01:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,253,1286164800"; d="scan'208";a="247011137" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Oct 2010 13:03:11 -0400 X-IronPort-AV: E=Sophos;i="4.58,253,1286164800"; d="scan'208";a="533887365" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2010 13:03:10 -0400 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: Thu, 28 Oct 2010 19:02:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: Thread-Index: Act2CgU+AJiB+0+KTVG6/YMeuad2vgAAD7AwAACyk9AALNQ8IA== References: From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 28 Oct 2010 17:01:20 -0000 During the IESG discussion Robert suggested that a more clear change would be:=20 OLD: =20 The server MUST support the parameter with a value equal to 'report-all', as specified in Section 3.1. NEW:=20 If the 'report-all' basic mode is supported, the server MUST conform to the behavior in Section 3.1 when processing a parameter with a value equal to 'report-all'. And the equivalent for 2.2.2 and 2.3.2 Also, some of the IESG members are still confused on the behavior of servers and clients. For example - what is the behavior of the server that advertises default capabilities as in the second example in 4.4? urn:ietf:params:netconf:capability:with-defaults:1.0?basic- mode=3Dexplicit&also-supported=3Dreport-all,report-all-tagged Alexey cleared. The document will go into Revised-ID needed. I suggest that you circulate an intermediate version before Beijing (submissions are closed) and try to close the issues with the DISCUSSing ADs before and at the meeting.=20 Dan =20 > -----Original Message----- > From: Andy Bierman [mailto:biermana@Brocade.com]=20 > Sent: Wednesday, October 27, 2010 9:30 PM > To: Romascanu, Dan (Dan) > Cc: netconf > Subject: RE: DISCUSS and COMMENT:=20 > >=20 > Hi, >=20 > I did answer this comment. > This is from my reply on 10/26: >=20 >=20 > 2.1.2: >=20 >=20 > NEW: >=20 > If the 'report-all' basic mode is supported, the server=20 > MUST support=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to=20 > 'report-all', as > specified in Section 3.1. >=20 >=20 > 2.2.2: >=20 > The server MUST support the parameter with a value > equal to 'trim', as specified in Section 3.1. >=20 > NEW: >=20 > If the 'trim' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'trim', > as specified in Section 3.1. >=20 > 2.3.2: >=20 > OLD: >=20 > The server MUST support the parameter with a value > equal to 'explicit', as specified in Section 3.3. >=20 > NEW: >=20 > If the 'explicit' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'explicit', > as specified in Section 3.3. >=20 >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, October 27, 2010 12:11 PM > To: Andy Bierman > Cc: netconf > Subject: FW: DISCUSS and COMMENT:=20 > >=20 > =20 > Hi Andy, >=20 > Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2=20 > also confused Robert Sparks as if they are read individually=20 > they seem to require support for each one of the individual=20 > modes and contradict the statements in sections 2 and 4.=20 >=20 > Dan >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Russ Housley > Sent: Wednesday, October 27, 2010 9:04 PM > To: iesg@ietf.org > Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; > netconf-chairs@tools.ietf.org > Subject: DISCUSS and COMMENT:=20 > >=20 > Discuss: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern > with Section 4 that needs to be addressed. Richard said: >=20 > I'm confused by the existence of Section 4 in light of the fact that > Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a > value for each of the basic modes. If there are > cases where a server doesn't support a given mode, what does it mean > for it to "support the parameter" with a=20 > given value?=20 >=20 > Comment: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several > concerns and a question. Please consider them. >=20 >=20 From biermana@Brocade.com Thu Oct 28 10:14:33 2010 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 8A9A43A680C for ; Thu, 28 Oct 2010 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.121, 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 73D8ZBFCPKef for ; Thu, 28 Oct 2010 10:14:32 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 814C43A67F2 for ; Thu, 28 Oct 2010 10:14:32 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9SHGMIU013893; Thu, 28 Oct 2010 10:16:23 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id s7cuxr0uy-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Oct 2010 10:16:23 -0700 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; Thu, 28 Oct 2010 10:16:05 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 28 Oct 2010 10:16:20 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" Date: Thu, 28 Oct 2010 10:16:18 -0700 Thread-Topic: [Netconf] DISCUSS and COMMENT: Thread-Index: Act2CgU+AJiB+0+KTVG6/YMeuad2vgAAD7AwAACyk9AALNQ8IAAAouTA Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-28_08:2010-10-28, 2010-10-28, 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-1004200000 definitions=main-1010280065 X-Proofpoint-SSN: Sensitivity2 Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 28 Oct 2010 17:14:33 -0000 Hi, OK to 2.x.2 changes. Agree 4.4 is confusing. Here is a proposed change for the issue in 4.4: Sec. 4.4, para 2: OLD: The identifier MAY have another parameter: "also-supported". This parameter indicates which additional default handling modes the server supports. The value of the parameter is a comma separated list of one or more modes that are supported beside the mode indicated in the 'basic-mode' parameter. Possible modes are 'report- all', 'report-all-tagged', 'trim', and 'explicit', as defined in Section 3. NEW: The identifier MAY have another parameter: "also-supported". This parameter indicates which additional enumeration values (besides the basic-mode enumeration), the server will accept for the=20 parameter in section 5. =20 The value of the parameter is a comma separated list of one or more modes that are supported beside the mode indicated in the 'basic-mode' parameter. Possible modes are 'report- all', 'report-all-tagged', 'trim', and 'explicit', as defined in Section 3. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Romascanu, Dan (Dan) Sent: Thursday, October 28, 2010 10:03 AM To: Andy Bierman Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: During the IESG discussion Robert suggested that a more clear change would be:=20 OLD: =20 The server MUST support the parameter with a value equal to 'report-all', as specified in Section 3.1. NEW:=20 If the 'report-all' basic mode is supported, the server MUST conform to the behavior in Section 3.1 when processing a parameter with a value equal to 'report-all'. And the equivalent for 2.2.2 and 2.3.2 Also, some of the IESG members are still confused on the behavior of servers and clients. For example - what is the behavior of the server that advertises default capabilities as in the second example in 4.4? urn:ietf:params:netconf:capability:with-defaults:1.0?basic- mode=3Dexplicit&also-supported=3Dreport-all,report-all-tagged Alexey cleared. The document will go into Revised-ID needed. I suggest that you circulate an intermediate version before Beijing (submissions are closed) and try to close the issues with the DISCUSSing ADs before and at the meeting.=20 Dan =20 > -----Original Message----- > From: Andy Bierman [mailto:biermana@Brocade.com]=20 > Sent: Wednesday, October 27, 2010 9:30 PM > To: Romascanu, Dan (Dan) > Cc: netconf > Subject: RE: DISCUSS and COMMENT:=20 > >=20 > Hi, >=20 > I did answer this comment. > This is from my reply on 10/26: >=20 >=20 > 2.1.2: >=20 >=20 > NEW: >=20 > If the 'report-all' basic mode is supported, the server=20 > MUST support=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to=20 > 'report-all', as > specified in Section 3.1. >=20 >=20 > 2.2.2: >=20 > The server MUST support the parameter with a value > equal to 'trim', as specified in Section 3.1. >=20 > NEW: >=20 > If the 'trim' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'trim', > as specified in Section 3.1. >=20 > 2.3.2: >=20 > OLD: >=20 > The server MUST support the parameter with a value > equal to 'explicit', as specified in Section 3.3. >=20 > NEW: >=20 > If the 'explicit' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'explicit', > as specified in Section 3.3. >=20 >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, October 27, 2010 12:11 PM > To: Andy Bierman > Cc: netconf > Subject: FW: DISCUSS and COMMENT:=20 > >=20 > =20 > Hi Andy, >=20 > Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2=20 > also confused Robert Sparks as if they are read individually=20 > they seem to require support for each one of the individual=20 > modes and contradict the statements in sections 2 and 4.=20 >=20 > Dan >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Russ Housley > Sent: Wednesday, October 27, 2010 9:04 PM > To: iesg@ietf.org > Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; > netconf-chairs@tools.ietf.org > Subject: DISCUSS and COMMENT:=20 > >=20 > Discuss: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern > with Section 4 that needs to be addressed. Richard said: >=20 > I'm confused by the existence of Section 4 in light of the fact that > Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a > value for each of the basic modes. If there are > cases where a server doesn't support a given mode, what does it mean > for it to "support the parameter" with a=20 > given value?=20 >=20 > Comment: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several > concerns and a question. Please consider them. >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Thu Oct 28 11:47:55 2010 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 462113A69AF for ; Thu, 28 Oct 2010 11:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, 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 AyzGhUWmyiOe for ; Thu, 28 Oct 2010 11:47:54 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 3EEE43A695C for ; Thu, 28 Oct 2010 11:47:54 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9SIkvqK015741; Thu, 28 Oct 2010 11:49:28 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id s7emvr064-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Oct 2010 11:49:27 -0700 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; Thu, 28 Oct 2010 11:49:11 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 28 Oct 2010 11:49:25 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" Date: Thu, 28 Oct 2010 11:49:23 -0700 Thread-Topic: [Netconf] DISCUSS and COMMENT: Thread-Index: Act2CgU+AJiB+0+KTVG6/YMeuad2vgAAD7AwAACyk9AALNQ8IAADiAkA Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-28_09:2010-10-28, 2010-10-28, 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-1004200000 definitions=main-1010280081 X-Proofpoint-SSN: Sensitivity2 Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 28 Oct 2010 18:47:55 -0000 Hi, The only edit that is (much) more than editorial: - remove section 4.3 4.3. Conformance Every NETCONF server SHOULD implement this capability. The use-case of forcing the server to return the schema default for missing nodes in its database is now optional-to-implement. This led to the discussion about splitting the capability into 2 pieces - basic-mode - with-defaults The WG decided not to do this. Only a 4741 server actually needs to advertise its basic-mode. A 4741bis server must support the 'remove' operation, in addition to the defaults-sensitive 'delete' operation.=20 Since the client has the schemas for all the NETCONF data, retrieval operations that result in missing leafs (no error, access control, or filtering applies) can safely be filled in with the schema default. Therefore, a 4741bis does not really need to advertise its=20 basic-mode at all. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Romascanu, Dan (Dan) Sent: Thursday, October 28, 2010 10:03 AM To: Andy Bierman Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: During the IESG discussion Robert suggested that a more clear change would be:=20 OLD: =20 The server MUST support the parameter with a value equal to 'report-all', as specified in Section 3.1. NEW:=20 If the 'report-all' basic mode is supported, the server MUST conform to the behavior in Section 3.1 when processing a parameter with a value equal to 'report-all'. And the equivalent for 2.2.2 and 2.3.2 Also, some of the IESG members are still confused on the behavior of servers and clients. For example - what is the behavior of the server that advertises default capabilities as in the second example in 4.4? urn:ietf:params:netconf:capability:with-defaults:1.0?basic- mode=3Dexplicit&also-supported=3Dreport-all,report-all-tagged Alexey cleared. The document will go into Revised-ID needed. I suggest that you circulate an intermediate version before Beijing (submissions are closed) and try to close the issues with the DISCUSSing ADs before and at the meeting.=20 Dan =20 > -----Original Message----- > From: Andy Bierman [mailto:biermana@Brocade.com]=20 > Sent: Wednesday, October 27, 2010 9:30 PM > To: Romascanu, Dan (Dan) > Cc: netconf > Subject: RE: DISCUSS and COMMENT:=20 > >=20 > Hi, >=20 > I did answer this comment. > This is from my reply on 10/26: >=20 >=20 > 2.1.2: >=20 >=20 > NEW: >=20 > If the 'report-all' basic mode is supported, the server=20 > MUST support=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to=20 > 'report-all', as > specified in Section 3.1. >=20 >=20 > 2.2.2: >=20 > The server MUST support the parameter with a value > equal to 'trim', as specified in Section 3.1. >=20 > NEW: >=20 > If the 'trim' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'trim', > as specified in Section 3.1. >=20 > 2.3.2: >=20 > OLD: >=20 > The server MUST support the parameter with a value > equal to 'explicit', as specified in Section 3.3. >=20 > NEW: >=20 > If the 'explicit' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'explicit', > as specified in Section 3.3. >=20 >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, October 27, 2010 12:11 PM > To: Andy Bierman > Cc: netconf > Subject: FW: DISCUSS and COMMENT:=20 > >=20 > =20 > Hi Andy, >=20 > Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2=20 > also confused Robert Sparks as if they are read individually=20 > they seem to require support for each one of the individual=20 > modes and contradict the statements in sections 2 and 4.=20 >=20 > Dan >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Russ Housley > Sent: Wednesday, October 27, 2010 9:04 PM > To: iesg@ietf.org > Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; > netconf-chairs@tools.ietf.org > Subject: DISCUSS and COMMENT:=20 > >=20 > Discuss: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern > with Section 4 that needs to be addressed. Richard said: >=20 > I'm confused by the existence of Section 4 in light of the fact that > Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a > value for each of the basic modes. If there are > cases where a server doesn't support a given mode, what does it mean > for it to "support the parameter" with a=20 > given value?=20 >=20 > Comment: >=20 > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several > concerns and a question. Please consider them. >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Thu Oct 28 12:13:41 2010 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 850FA3A6833 for ; Thu, 28 Oct 2010 12:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 54f9DADfms0s for ; Thu, 28 Oct 2010 12:13:40 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id F21A83A67F6 for ; Thu, 28 Oct 2010 12:13:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTMnL01kwMXl5+OdbzNaE2SA1B+coqZMu@postini.com; Thu, 28 Oct 2010 12:15:33 PDT 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; Thu, 28 Oct 2010 12:13:18 -0700 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 o9SJDIU42316; Thu, 28 Oct 2010 12:13:18 -0700 (PDT) (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 o9SIqFc2023160; Thu, 28 Oct 2010 18:52:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010281852.o9SIqFc2023160@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 28 Oct 2010 14:52:15 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 28 Oct 2010 19:13:41 -0000 Andy Bierman writes: >The only edit that is (much) more than editorial: > - remove section 4.3 > 4.3. Conformance > Every NETCONF server SHOULD implement this capability. +1 for removing 4.3. Thanks, Phil From ietfc@btconnect.com Fri Oct 29 09:02:28 2010 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 824793A66B4 for ; Fri, 29 Oct 2010 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 8K4UGjDI9x7n for ; Fri, 29 Oct 2010 09:02:27 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 2CFC23A6405 for ; Fri, 29 Oct 2010 09:02:26 -0700 (PDT) Received: from host86-156-136-67.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.67]) by c2bthomr07.btconnect.com with SMTP id ASJ75466; Fri, 29 Oct 2010 17:04:15 +0100 (BST) Message-ID: <012801cb777a$602453a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Andy Bierman" , "Romascanu, Dan \(Dan\)" References: Date: Fri, 29 Oct 2010 16:53:52 +0200 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=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CCAF070.01B9, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4CCAF081.01DB,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 Cc: netconf Subject: Re: [Netconf] DISCUSS and COMMENT: 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, 29 Oct 2010 16:02:28 -0000 Andy picking up an earlier comment, 2.2.2 should reference 3.2 not 3.1 Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Romascanu, Dan (Dan)" Cc: "netconf" Sent: Wednesday, October 27, 2010 9:30 PM Subject: Re: [Netconf] DISCUSS and COMMENT: > Hi, > > I did answer this comment. > This is from my reply on 10/26: > > > 2.1.2: > > OLD: > > The server MUST support the parameter with a value > equal to 'report-all', as specified in Section 3.1. > > NEW: > > If the 'report-all' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'report-all', as > specified in Section 3.1. > > > 2.2.2: > > The server MUST support the parameter with a value > equal to 'trim', as specified in Section 3.1. > > NEW: > > If the 'trim' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'trim', > as specified in Section 3.1. > > 2.3.2: > > OLD: > > The server MUST support the parameter with a value > equal to 'explicit', as specified in Section 3.3. > > NEW: > > If the 'explicit' basic mode is supported, the server MUST support > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the parameter with a value equal to 'explicit', > as specified in Section 3.3. > > > > Andy > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, October 27, 2010 12:11 PM > To: Andy Bierman > Cc: netconf > Subject: FW: DISCUSS and COMMENT: > > > Hi Andy, > > Please answer this issue. The MUSTs in 2.1.2, 2.2.2 and 2.3.2 also > confused Robert Sparks as if they are read individually they seem to > require support for each one of the individual modes and contradict the > statements in sections 2 and 4. > > Dan > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Russ Housley > Sent: Wednesday, October 27, 2010 9:04 PM > To: iesg@ietf.org > Cc: rbarnes@bbn.com; draft-ietf-netconf-with-defaults@tools.ietf.org; > netconf-chairs@tools.ietf.org > Subject: DISCUSS and COMMENT: > > Discuss: > > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern > with Section 4 that needs to be addressed. Richard said: > > I'm confused by the existence of Section 4 in light of the fact that > Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a > value for each of the basic modes. If there are > cases where a server doesn't support a given mode, what does it mean > for it to "support the parameter" with a given value? > > Comment: > > The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several > concerns and a question. Please consider them. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf