From bertietf@bwijnen.net Sat Nov 6 23:41: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 354533A686B for ; Sat, 6 Nov 2010 23:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 dXGo0jnJ4RVv for ; Sat, 6 Nov 2010 23:41:22 -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 EE14A3A67FD for ; Sat, 6 Nov 2010 23:41:20 -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 1PEywV-0006il-PM for netconf@ietf.org; Sun, 07 Nov 2010 07:41:37 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PEywU-0005kv-9Q for netconf@ietf.org; Sun, 07 Nov 2010 07:41:31 +0100 Message-ID: <4CD64A16.3090408@bwijnen.net> Date: Sun, 07 Nov 2010 14:41:26 +0800 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a734656c1b963a66c6878a6e2c49967e X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a734656c1b963a66c6878a6e2c49967e Subject: [Netconf] nacm comments/notes - part 1 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, 07 Nov 2010 06:41:23 -0000 Part 1 of my current review/reading of the NACM document draft-ietf-netconf-access-control-01 1. RFC4741 is cited/referenced. Should be rfc4741bis 2. RFC4742 is cited/referenced. Should be rfc4742bis 3. Sect 2. are there no MUSTs needed here? 4. figure 1 (but also other places in the doc) talks about RPC operation. I thought that in the new terminology we talk about rpc messages and protocol operations (rfc4741bis seems to use " operation" once, maybe that should also be fixed? 5. figure 1 speaks about a "data node". I assume that is the data node as defined in RFC6020? Migth ewant to add this term to the terminology section and indicate it is taken from RFC6020 (if this indeed the case) 6. sect 3.4 It must be possible control access to specific s/possible control/possible to control/ 7. sect 3.4 page 10 speaks about databases. I think it is better to use datastores here, is it not? 8. sect 3.4 (at the end): Only a privileged user should be able to alter the factory-default access control rules. Did we define the term "privileged user"? Is this the superuser? or is it any use who has proper privilege (authorization) ? 9. Sect 3.8 It is customary for security-sensitive objects to be documented in the Security Considerations section of an RFC. Mmm... I thought it is mandatory instead of just customary. 10. WHat is the intent of sect 3.8 It seems to me to be a list of reasons as to why we might need some machine readable atg on data-nodes. Is that the intention? Are we implicitly saying that YANG is incomplete in this aspect? 11. Sect 3.10 A session must always be authorized to receive the and notification events, defined in [RFC5277] Do you mean "send" instead of "receive" ?? I thought NACM is applied at the server side, so theese two events would be "send" at the server, no? - additional notes In general, a thouroough check of termonilogy consistency within this document is needed. And make sure it is in sync with the terminology in the rfc4741bis and YANG rfc6020. 1. DBH mentioned something about XML accessControl work don in W3C Hannes may be able to help here Bert From j.schoenwaelder@jacobs-university.de Sun Nov 7 20:58: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 C8ADE28C0E4 for ; Sun, 7 Nov 2010 20:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYhnx9jCbfm for ; Sun, 7 Nov 2010 20:58:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E62228C11E for ; Sun, 7 Nov 2010 20:58:15 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EA40C0002 for ; Mon, 8 Nov 2010 05:58:35 +0100 (CET) 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 wNqXdnnncC-2; Mon, 8 Nov 2010 05:58:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C588C0008; Mon, 8 Nov 2010 05:58:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D1C271598081; Mon, 8 Nov 2010 05:58:27 +0100 (CET) Date: Mon, 8 Nov 2010 05:58:27 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20101108045827.GA52610@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] nacm module name 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: Mon, 08 Nov 2010 04:58:23 -0000 Hi, I suggest to rename 'ietf-nacm' to 'ietf-netconf-acm' - I think that name better aligns with ietf-netconf-monitoring and ietf-netconf-partial-lock and ietf-netconf. /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 Sun Nov 7 22:25: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 2B7EB3A69B5 for ; Sun, 7 Nov 2010 22:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 dmakas2xRKoU for ; Sun, 7 Nov 2010 22:25:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3B87C28C0EE for ; Sun, 7 Nov 2010 22:25:17 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 76B9C616001 for ; Mon, 8 Nov 2010 07:25:31 +0100 (CET) Date: Mon, 08 Nov 2010 07:25:29 +0100 (CET) Message-Id: <20101108.072529.22583674.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [Netconf] comments on 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: Mon, 08 Nov 2010 06:25:33 -0000 Hi, I have some minor comments on the text, otherwise I think the document is in good shape. Some comments are the same as I had for -00, but haven't received any replies for. 2.1.1. s/Generated when the NETCONF session is/ Generated when a NETCONF session is/g 2.1.1. s/sys-conformed-commit/sys-confirmed-commit 2.2 The module is called "ietf-netconf-system-notifications", but the document is called "System Notifications". This was discussed at the meeting, so I guess it will change. 2.2 In the sys-config-change, I think the leaf target-database should be moved out from the list edit, so that one such notification reports changes on one datastore only. 2.2. In the sys-config-change, the text on 'operation' says: A server SHOULD set this object to the NETCONF edit operation performed on the target database. Why is this a SHOULD? 2.2 The text about enum dropped says: "The session was terminated because the SSH session or TCP connection was unexpectedly closed." This should be transport-independent: "The session was terminated because the transport layer connection was unexpectedly closed." or similar. 2.2. The text about enum bad-hello says: "The client's message was bad or never arrived."; But if it never arrived, the "timeout" enum would be used, wouldn't it? 2.2. notification sys-confirmed-commit Add a reference statement, refer to 4741bis, section 8.4 2.2. enum "cancel" OLD: "The confirm-commit procedure has been canceled, due to the session being terminated."; NEW: "The confirm-commit procedure has been canceled, due to the session being terminated, or an explicit operation."; /martin From lhotka@cesnet.cz Sun Nov 7 23:23:13 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 482E33A6452 for ; Sun, 7 Nov 2010 23:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 0okbACgwgHX3 for ; Sun, 7 Nov 2010 23:23:12 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 838B228C0EE for ; Sun, 7 Nov 2010 23:22:38 -0800 (PST) Received: from [130.129.119.190] (dhcp-77be.meeting.ietf.org [130.129.119.190]) by office2.cesnet.cz (Postfix) with ESMTPSA id 914CA2CDE059 for ; Mon, 8 Nov 2010 08:22:55 +0100 (CET) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 08 Nov 2010 15:22:25 +0800 Message-ID: <1289200945.1621.12.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [Netconf] escaping EoM 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, 08 Nov 2010 07:23:13 -0000 Hi, Wes Hardaker probably found a counter-example against the EoM escaping method: ]]>]]>]]> This is because the middle "]]" is a common part of two chunks that are candidates for escaping. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 8 00:34: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 860AF3A6774 for ; Mon, 8 Nov 2010 00:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 5Qk9xgqCT1oe for ; Mon, 8 Nov 2010 00:34:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E6453A67D4 for ; Mon, 8 Nov 2010 00:34:12 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 72BB9616001; Mon, 8 Nov 2010 09:34:24 +0100 (CET) Date: Mon, 08 Nov 2010 09:34:24 +0100 (CET) Message-Id: <20101108.093424.118024926.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1289200945.1621.12.camel@nomad> References: <1289200945.1621.12.camel@nomad> 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] escaping EoM 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, 08 Nov 2010 08:34:15 -0000 Ladislav Lhotka wrote: > Hi, > > Wes Hardaker probably found a counter-example against the EoM escaping > method: > > ]]>]]>]]> > > This is because the middle "]]" is a common part of two chunks that are > candidates for escaping. I think this works, but the alg. description is not really correct. On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at the same time. When ]]>]]] is found, it is replaced with ]]>]], and scanning continues. So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, ]]>]]] is found and replaced with ]]>]], then scanning continues with >]]>, which is left untouched, resulting in ]]>]]>]]>, which we >started with. /martin From mbj@tail-f.com Mon Nov 8 00:45: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 6CBD83A6892 for ; Mon, 8 Nov 2010 00:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 I4x3BpPfkCwk for ; Mon, 8 Nov 2010 00:45:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A82E03A6778 for ; Mon, 8 Nov 2010 00:45:49 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EE537616001 for ; Mon, 8 Nov 2010 09:46:06 +0100 (CET) Date: Mon, 08 Nov 2010 09:46:05 +0100 (CET) Message-Id: <20101108.094605.145687871.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20101108.072529.22583674.mbj@tail-f.com> References: <20101108.072529.22583674.mbj@tail-f.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 Subject: Re: [Netconf] comments on 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: Mon, 08 Nov 2010 08:45:50 -0000 Martin Bjorklund wrote: > 2.2 > > The module is called "ietf-netconf-system-notifications", but the > document is called "System Notifications". This was discussed at > the meeting, so I guess it will change. A comment on this. At the meeting, it was suggested that the notifications etc will be renamed from sys-something to netconf-something, if I got it right. The reason was that the notifications are related to the NETCONF subsystem, rather than the system as a whole. But does this affect how sys-config-change is defined? The config data store can be modified by other means than over NETCONF. I hope that this notification, whatever is called, is generated also when the config is modified outside of NETCONF. /martin From j.schoenwaelder@jacobs-university.de Mon Nov 8 01:05: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 E8E2A3A68E2 for ; Mon, 8 Nov 2010 01:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+FGWeNr0TDw for ; Mon, 8 Nov 2010 01:05:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5DBC23A68C6 for ; Mon, 8 Nov 2010 01:05:12 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C47C8C0012; Mon, 8 Nov 2010 10:05:32 +0100 (CET) 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 XJl7XsIS2SXW; Mon, 8 Nov 2010 10:05:32 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3172CC0008; Mon, 8 Nov 2010 10:05:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 235A315988F4; Mon, 8 Nov 2010 10:05:32 +0100 (CET) Date: Mon, 8 Nov 2010 10:05:32 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101108090532.GA53296@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20101108.072529.22583674.mbj@tail-f.com> <20101108.094605.145687871.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101108.094605.145687871.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-ietf-netconf-system-notifications-01.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: Mon, 08 Nov 2010 09:05:14 -0000 On Mon, Nov 08, 2010 at 09:46:05AM +0100, Martin Bjorklund wrote: > But does this affect how sys-config-change is defined? The config > data store can be modified by other means than over NETCONF. I hope > that this notification, whatever is called, is generated also when the > config is modified outside of NETCONF. Do you mean "at the time it is modified outside of NETCONF" or "at the time NETCONF detects that it got modified". This might not be the same time on some systems. /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 Mon Nov 8 01:26: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 85D6628C0F2 for ; Mon, 8 Nov 2010 01:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 MtDrtfwLLW3a for ; Mon, 8 Nov 2010 01:26:26 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A58CA28C0F1 for ; Mon, 8 Nov 2010 01:26:26 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 714D2616002; Mon, 8 Nov 2010 10:26:46 +0100 (CET) Date: Mon, 08 Nov 2010 10:26:43 +0100 (CET) Message-Id: <20101108.102643.68573304.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101108090532.GA53296@elstar.local> References: <20101108.072529.22583674.mbj@tail-f.com> <20101108.094605.145687871.mbj@tail-f.com> <20101108090532.GA53296@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] comments on 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: Mon, 08 Nov 2010 09:26:27 -0000 Juergen Schoenwaelder wrote: > On Mon, Nov 08, 2010 at 09:46:05AM +0100, Martin Bjorklund wrote: > > > But does this affect how sys-config-change is defined? The config > > data store can be modified by other means than over NETCONF. I hope > > that this notification, whatever is called, is generated also when the > > config is modified outside of NETCONF. > > Do you mean "at the time it is modified outside of NETCONF" or "at the > time NETCONF detects that it got modified". This might not be the same > time on some systems. I don't think the current text talks about timing at all. And since the notifs are asynchronous, I don't think we can say anything about when this event is generated. I want to be able to use this event to avoid polling. So if I have a session open where I subscribe to the 'NETCONF' stream, I know that if I get this event, I need to check what just happened. If I don't get an event, I'm pretty sure nothing has happend (modulo timing issues). /martin From lhotka@cesnet.cz Mon Nov 8 01:57: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 241BF3A6959 for ; Mon, 8 Nov 2010 01:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 oIh-ACoSgE9m for ; Mon, 8 Nov 2010 01:57:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 0D95E3A6950 for ; Mon, 8 Nov 2010 01:57:36 -0800 (PST) Received: from [130.129.119.190] (dhcp-77be.meeting.ietf.org [130.129.119.190]) by office2.cesnet.cz (Postfix) with ESMTPSA id 180162CDE057; Mon, 8 Nov 2010 10:57:47 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20101108.093424.118024926.mbj@tail-f.com> References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 08 Nov 2010 17:57:17 +0800 Message-ID: <1289210237.1654.30.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 09:57:37 -0000 On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > Wes Hardaker probably found a counter-example against the EoM escaping > > method: > > > > ]]>]]>]]> > > > > This is because the middle "]]" is a common part of two chunks that are > > candidates for escaping. > > I think this works, but the alg. description is not really correct. > On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at > the same time. When ]]>]]] is found, it is replaced with ]]>]], and > scanning continues. > > So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, > ]]>]]] is found and replaced with ]]>]], then scanning continues with > >]]>, which is left untouched, resulting in ]]>]]>]]>, which we > >started with. I think the point of this method was to make sure the EoM marker doesn't appear in the NETCONF message body so that the receiving side can identify the frame limits a priori. This is not satisfied here. Lada > > > > /martin > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Nov 8 01:58:04 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 33B8E3A6959 for ; Mon, 8 Nov 2010 01:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 U51E4dcZnx22 for ; Mon, 8 Nov 2010 01:58:03 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4BFAD3A6950 for ; Mon, 8 Nov 2010 01:58:03 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F0A7D616002; Mon, 8 Nov 2010 10:58:22 +0100 (CET) Message-ID: <4CD7C9BE.6080308@tail-f.com> Date: Mon, 08 Nov 2010 10:58:22 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Martin Bjorklund References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> In-Reply-To: <20101108.093424.118024926.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 09:58:04 -0000 On 2010-11-08 09:34, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >> >> Wes Hardaker probably found a counter-example against the EoM escaping >> method: >> >> ]]>]]>]]> >> >> This is because the middle "]]" is a common part of two chunks that are >> candidates for escaping. > > I think this works, but the alg. description is not really correct. > On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at > the same time. Yeah, I guess that should be spelled out - you can't scan for ]]>]]> until you find it before you scan for ]]>]]] - but you don't want to do that anyway, since it would require buffering the whole PDU. > When ]]>]]] is found, it is replaced with ]]>]], and > scanning continues. Yes (i.e. it continues after the replacement). > So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, > ]]>]]] is found and replaced with ]]>]], then scanning continues with >> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we >> started with. Right. So perhaps a more elaborate description should be: 1 Transmission of PDU: a) Look at the "next" 5 input characters. b) If they are "]]>]]", replace with "]]>]]]", advance 5 positions in input and go to a). c) Otherwise, advance 1 position in input and go to a). d) At end of input, append "]]>]]>". 2. Reception of PDU: a) Look at the "next" 6 input characters. b) If they are "]]>]]>", EoM has been found - discard EoM and "deliver" PDU. c) If they are "]]>]]]", replace with "]]>]]", advance 6 positions in input and go to a). d) Otherwise, advance 1 position in input and go to a). (An actual implementation would presumably look at those 5/6 characters one-by-one, allowing for the "Otherwise" case to be selected as soon as any character in the first 4/5 doesn't match.) --Per From per@tail-f.com Mon Nov 8 02:15: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 715AE28C11D for ; Mon, 8 Nov 2010 02:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 WHU8tml-4OdV for ; Mon, 8 Nov 2010 02:15:44 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8B93E3A6980 for ; Mon, 8 Nov 2010 02:15:44 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 00249616001; Mon, 8 Nov 2010 11:16:04 +0100 (CET) Message-ID: <4CD7CDE4.3090703@tail-f.com> Date: Mon, 08 Nov 2010 11:16:04 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Ladislav Lhotka References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> In-Reply-To: <1289210237.1654.30.camel@nomad> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 10:15:45 -0000 On 2010-11-08 10:57, Ladislav Lhotka wrote: > On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> Wes Hardaker probably found a counter-example against the EoM escaping >>> method: >>> >>> ]]>]]>]]> >>> >>> This is because the middle "]]" is a common part of two chunks that are >>> candidates for escaping. >> I think this works, but the alg. description is not really correct. >> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at >> the same time. When ]]>]]] is found, it is replaced with ]]>]], and >> scanning continues. >> >> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, >> ]]>]]] is found and replaced with ]]>]], then scanning continues with >>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we >>> started with. > > I think the point of this method was to make sure the EoM marker doesn't > appear in the NETCONF message body so that the receiving side can > identify the frame limits a priori. This is not satisfied here. No, the (unstated) point of the method was only to provide a really transparent transport. An additional (unstated) requirement was to support streaming of the PDU. "Identifying the frame limits a priori" is obviously at odds with streaming - it wasn't considered. But perhaps the method could be "refined" to do "]]>" -> "]]>>" instead, at the cost of some "unnecessary" rewriting. --Per From lhotka@cesnet.cz Mon Nov 8 02:32:52 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 6010128C13A for ; Mon, 8 Nov 2010 02:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 A5q-FQj7Yxct for ; Mon, 8 Nov 2010 02:32:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 79F2F28C12E for ; Mon, 8 Nov 2010 02:32:51 -0800 (PST) Received: from [130.129.119.190] (dhcp-77be.meeting.ietf.org [130.129.119.190]) by office2.cesnet.cz (Postfix) with ESMTPSA id 1B20C2CDE05E; Mon, 8 Nov 2010 11:32:38 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <4CD7CDE4.3090703@tail-f.com> References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> <4CD7CDE4.3090703@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 08 Nov 2010 18:32:13 +0800 Message-ID: <1289212333.1654.45.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 10:32:52 -0000 On Po, 2010-11-08 at 11:16 +0100, Per Hedeland wrote: > On 2010-11-08 10:57, Ladislav Lhotka wrote: > > On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> Wes Hardaker probably found a counter-example against the EoM escaping > >>> method: > >>> > >>> ]]>]]>]]> > >>> > >>> This is because the middle "]]" is a common part of two chunks that are > >>> candidates for escaping. > >> I think this works, but the alg. description is not really correct. > >> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at > >> the same time. When ]]>]]] is found, it is replaced with ]]>]], and > >> scanning continues. > >> > >> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, > >> ]]>]]] is found and replaced with ]]>]], then scanning continues with > >>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we > >>> started with. > > > > I think the point of this method was to make sure the EoM marker doesn't > > appear in the NETCONF message body so that the receiving side can > > identify the frame limits a priori. This is not satisfied here. > > No, the (unstated) point of the method was only to provide a really > transparent transport. An additional (unstated) requirement was to > support streaming of the PDU. "Identifying the frame limits a priori" is What do you mean by "streaming the PDU"? If we don't care about layering, the most straightforward method on the receiver side would be to parse the XML stream properly right away - which has to be done in any case, sooner or later - and the EOM would then become a non-issue. Lada > obviously at odds with streaming - it wasn't considered. But perhaps the > method could be "refined" to do "]]>" -> "]]>>" instead, at the cost of > some "unnecessary" rewriting. > > --Per -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Nov 8 02:50: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 143163A69A2 for ; Mon, 8 Nov 2010 02:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 tf5GYm+wn0MV for ; Mon, 8 Nov 2010 02:50:45 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 559E928C0F1 for ; Mon, 8 Nov 2010 02:50:45 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BD3F5616001; Mon, 8 Nov 2010 11:51:05 +0100 (CET) Message-ID: <4CD7D619.2030509@tail-f.com> Date: Mon, 08 Nov 2010 11:51:05 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Ladislav Lhotka References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> <4CD7CDE4.3090703@tail-f.com> <1289212333.1654.45.camel@nomad> In-Reply-To: <1289212333.1654.45.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 10:50:47 -0000 On 2010-11-08 11:32, Ladislav Lhotka wrote: > On Po, 2010-11-08 at 11:16 +0100, Per Hedeland wrote: >> On 2010-11-08 10:57, Ladislav Lhotka wrote: >>> On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: >>>> Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> Wes Hardaker probably found a counter-example against the EoM escaping >>>>> method: >>>>> >>>>> ]]>]]>]]> >>>>> >>>>> This is because the middle "]]" is a common part of two chunks that are >>>>> candidates for escaping. >>>> I think this works, but the alg. description is not really correct. >>>> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at >>>> the same time. When ]]>]]] is found, it is replaced with ]]>]], and >>>> scanning continues. >>>> >>>> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, >>>> ]]>]]] is found and replaced with ]]>]], then scanning continues with >>>>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we >>>>> started with. >>> I think the point of this method was to make sure the EoM marker doesn't >>> appear in the NETCONF message body so that the receiving side can >>> identify the frame limits a priori. This is not satisfied here. >> No, the (unstated) point of the method was only to provide a really >> transparent transport. An additional (unstated) requirement was to >> support streaming of the PDU. "Identifying the frame limits a priori" is > > What do you mean by "streaming the PDU"? The sending side of the transport should be able to put bits on the wire without waiting for the complete PDU to arrive from the Messages layer. The receiving side of the transport should be able to deliver bits to the Messages layer without waiting for the complete PDU to arrive on the wire. s/PDU/Message/ I guess. > If we don't care about > layering, the most straightforward method on the receiver side would be > to parse the XML stream properly right away - which has to be done in > any case, sooner or later - and the EOM would then become a non-issue. That may be true - the context of the suggestion was that we did care about layering, and that the transport would be ignorant of XML. --Per From mehmet.ersue@nsn.com Mon Nov 8 04:11:04 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 C5C003A69D0 for ; Mon, 8 Nov 2010 04:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.001 X-Spam-Level: X-Spam-Status: No, score=-101.001 tagged_above=-999 required=5 tests=[AWL=1.598, 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 v7M-TIjRYJIu for ; Mon, 8 Nov 2010 04:10:55 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9729D28C0E8 for ; Mon, 8 Nov 2010 04:10:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oA8CBCPW024880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Nov 2010 13:11:12 +0100 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 oA8CBBaO032367; Mon, 8 Nov 2010 13:11:12 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 13:11:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 13:11:08 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64013075CF@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101108045827.GA52610@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] nacm module name Thread-Index: Act/AaC2Z7tRR8/KS7ubnbEJMrQ4mwAPF74g References: <20101108045827.GA52610@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 08 Nov 2010 12:11:11.0833 (UTC) FILETIME=[088CB490:01CB7F3E] Subject: Re: [Netconf] nacm module name 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, 08 Nov 2010 12:11:04 -0000 Agree. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Juergen Schoenwaelder > Sent: Monday, November 08, 2010 5:58 AM > To: netconf@ietf.org > Subject: [Netconf] nacm module name >=20 > Hi, >=20 > I suggest to rename 'ietf-nacm' to 'ietf-netconf-acm' - I think that > name better aligns with ietf-netconf-monitoring and > ietf-netconf-partial-lock and ietf-netconf. >=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 lhotka@cesnet.cz Mon Nov 8 07:09: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 4818C3A68B0 for ; Mon, 8 Nov 2010 07:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 Hd6ltyulqZXO for ; Mon, 8 Nov 2010 07:09:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 285ED3A68D8 for ; Mon, 8 Nov 2010 07:09:43 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 585F42CDE057; Mon, 8 Nov 2010 16:10:00 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <4CD7D619.2030509@tail-f.com> References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> <4CD7CDE4.3090703@tail-f.com> <1289212333.1654.45.camel@nomad> <4CD7D619.2030509@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 08 Nov 2010 23:09:54 +0800 Message-ID: <1289228994.1491.39.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 15:09:46 -0000 On Po, 2010-11-08 at 11:51 +0100, Per Hedeland wrote: > On 2010-11-08 11:32, Ladislav Lhotka wrote: > > On Po, 2010-11-08 at 11:16 +0100, Per Hedeland wrote: > >> On 2010-11-08 10:57, Ladislav Lhotka wrote: > >>> On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: > >>>> Ladislav Lhotka wrote: > >>>>> Hi, > >>>>> > >>>>> Wes Hardaker probably found a counter-example against the EoM escaping > >>>>> method: > >>>>> > >>>>> ]]>]]>]]> > >>>>> > >>>>> This is because the middle "]]" is a common part of two chunks that are > >>>>> candidates for escaping. > >>>> I think this works, but the alg. description is not really correct. > >>>> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at > >>>> the same time. When ]]>]]] is found, it is replaced with ]]>]], and > >>>> scanning continues. > >>>> > >>>> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, > >>>> ]]>]]] is found and replaced with ]]>]], then scanning continues with > >>>>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we > >>>>> started with. > >>> I think the point of this method was to make sure the EoM marker doesn't > >>> appear in the NETCONF message body so that the receiving side can > >>> identify the frame limits a priori. This is not satisfied here. > >> No, the (unstated) point of the method was only to provide a really > >> transparent transport. An additional (unstated) requirement was to > >> support streaming of the PDU. "Identifying the frame limits a priori" is > > > > What do you mean by "streaming the PDU"? > > The sending side of the transport should be able to put bits on the wire > without waiting for the complete PDU to arrive from the Messages layer. > The receiving side of the transport should be able to deliver bits to > the Messages layer without waiting for the complete PDU to arrive on the > wire. s/PDU/Message/ I guess. The multibyte EOM makes this complicated because the problematic sequences may be split between subsequent frames. For this particular purpose, the single-byte EOM that must not occur at all in the message is IMO much easier to deal with. Lada > > > If we don't care about > > layering, the most straightforward method on the receiver side would be > > to parse the XML stream properly right away - which has to be done in > > any case, sooner or later - and the EOM would then become a non-issue. > > That may be true - the context of the suggestion was that we did care > about layering, and that the transport would be ignorant of XML. > > --Per -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From per@tail-f.com Mon Nov 8 07:57: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 A73163A68FC for ; Mon, 8 Nov 2010 07:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 Fw2BX-iuVIl9 for ; Mon, 8 Nov 2010 07:57:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 959A83A68E2 for ; Mon, 8 Nov 2010 07:57:37 -0800 (PST) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AD174616001; Mon, 8 Nov 2010 16:57:57 +0100 (CET) Message-ID: <4CD81E04.4080509@tail-f.com> Date: Mon, 08 Nov 2010 16:57:56 +0100 From: Per Hedeland User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Ladislav Lhotka References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> <4CD7CDE4.3090703@tail-f.com> <1289212333.1654.45.camel@nomad> <4CD7D619.2030509@tail-f.com> <1289228994.1491.39.camel@nomad> In-Reply-To: <1289228994.1491.39.camel@nomad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 15:57:38 -0000 On 2010-11-08 16:09, Ladislav Lhotka wrote: > On Po, 2010-11-08 at 11:51 +0100, Per Hedeland wrote: >> On 2010-11-08 11:32, Ladislav Lhotka wrote: >>> On Po, 2010-11-08 at 11:16 +0100, Per Hedeland wrote: >>>> On 2010-11-08 10:57, Ladislav Lhotka wrote: >>>>> On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: >>>>>> Ladislav Lhotka wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Wes Hardaker probably found a counter-example against the EoM escaping >>>>>>> method: >>>>>>> >>>>>>> ]]>]]>]]> >>>>>>> >>>>>>> This is because the middle "]]" is a common part of two chunks that are >>>>>>> candidates for escaping. >>>>>> I think this works, but the alg. description is not really correct. >>>>>> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at >>>>>> the same time. When ]]>]]] is found, it is replaced with ]]>]], and >>>>>> scanning continues. >>>>>> >>>>>> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, >>>>>> ]]>]]] is found and replaced with ]]>]], then scanning continues with >>>>>>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we >>>>>>> started with. >>>>> I think the point of this method was to make sure the EoM marker doesn't >>>>> appear in the NETCONF message body so that the receiving side can >>>>> identify the frame limits a priori. This is not satisfied here. >>>> No, the (unstated) point of the method was only to provide a really >>>> transparent transport. An additional (unstated) requirement was to >>>> support streaming of the PDU. "Identifying the frame limits a priori" is >>> What do you mean by "streaming the PDU"? >> The sending side of the transport should be able to put bits on the wire >> without waiting for the complete PDU to arrive from the Messages layer. >> The receiving side of the transport should be able to deliver bits to >> the Messages layer without waiting for the complete PDU to arrive on the >> wire. s/PDU/Message/ I guess. > > The multibyte EOM makes this complicated because the problematic > sequences may be split between subsequent frames. Yes, somewhat - this is the case even without the escaping, of course. > For this particular > purpose, the single-byte EOM that must not occur at all in the message > is IMO much easier to deal with. *If* it can be guaranteed that the single-byte EOM never will occur in a message (and hence won't need escaping), yes - I think there was some mention of the possibility of unchecked user input including it. But anyway, my understanding is that the WG has decided to postpone the discussion/decision of any changes needed to the currently defined mechanism - it is probably not useful to keep debating the relative merits of different alternatives until there is an actual "target" for the discussion. --Per From lhotka@cesnet.cz Mon Nov 8 08:11: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 071F83A6943 for ; Mon, 8 Nov 2010 08:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 PrmUirx29Ybx for ; Mon, 8 Nov 2010 08:11:34 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 999393A67EE for ; Mon, 8 Nov 2010 08:11:22 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 78D3B2CDE057; Mon, 8 Nov 2010 17:11:39 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <4CD81E04.4080509@tail-f.com> References: <1289200945.1621.12.camel@nomad> <20101108.093424.118024926.mbj@tail-f.com> <1289210237.1654.30.camel@nomad> <4CD7CDE4.3090703@tail-f.com> <1289212333.1654.45.camel@nomad> <4CD7D619.2030509@tail-f.com> <1289228994.1491.39.camel@nomad> <4CD81E04.4080509@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 09 Nov 2010 00:11:32 +0800 Message-ID: <1289232692.1491.78.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 16:11:36 -0000 On Po, 2010-11-08 at 16:57 +0100, Per Hedeland wrote: > On 2010-11-08 16:09, Ladislav Lhotka wrote: > > On Po, 2010-11-08 at 11:51 +0100, Per Hedeland wrote: > >> On 2010-11-08 11:32, Ladislav Lhotka wrote: > >>> On Po, 2010-11-08 at 11:16 +0100, Per Hedeland wrote: > >>>> On 2010-11-08 10:57, Ladislav Lhotka wrote: > >>>>> On Po, 2010-11-08 at 09:34 +0100, Martin Bjorklund wrote: > >>>>>> Ladislav Lhotka wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Wes Hardaker probably found a counter-example against the EoM escaping > >>>>>>> method: > >>>>>>> > >>>>>>> ]]>]]>]]> > >>>>>>> > >>>>>>> This is because the middle "]]" is a common part of two chunks that are > >>>>>>> candidates for escaping. > >>>>>> I think this works, but the alg. description is not really correct. > >>>>>> On the receiving side, the code needs to scan for ]]>]]> and ]]>]]] at > >>>>>> the same time. When ]]>]]] is found, it is replaced with ]]>]], and > >>>>>> scanning continues. > >>>>>> > >>>>>> So ]]>]]>]]> is replaced with ]]>]]]>]]>. At the receiving side, > >>>>>> ]]>]]] is found and replaced with ]]>]], then scanning continues with > >>>>>>> ]]>, which is left untouched, resulting in ]]>]]>]]>, which we > >>>>>>> started with. > >>>>> I think the point of this method was to make sure the EoM marker doesn't > >>>>> appear in the NETCONF message body so that the receiving side can > >>>>> identify the frame limits a priori. This is not satisfied here. > >>>> No, the (unstated) point of the method was only to provide a really > >>>> transparent transport. An additional (unstated) requirement was to > >>>> support streaming of the PDU. "Identifying the frame limits a priori" is > >>> What do you mean by "streaming the PDU"? > >> The sending side of the transport should be able to put bits on the wire > >> without waiting for the complete PDU to arrive from the Messages layer. > >> The receiving side of the transport should be able to deliver bits to > >> the Messages layer without waiting for the complete PDU to arrive on the > >> wire. s/PDU/Message/ I guess. > > > > The multibyte EOM makes this complicated because the problematic > > sequences may be split between subsequent frames. > > Yes, somewhat - this is the case even without the escaping, of course. > > > For this particular > > purpose, the single-byte EOM that must not occur at all in the message > > is IMO much easier to deal with. > > *If* it can be guaranteed that the single-byte EOM never will occur in a > message (and hence won't need escaping), yes - I think there was some > mention of the possibility of unchecked user input including it. No escaping is needed at all, any message containing it will be rejected as not being well-formed. > > But anyway, my understanding is that the WG has decided to postpone the > discussion/decision of any changes needed to the currently defined > mechanism - it is probably not useful to keep debating the relative > merits of different alternatives until there is an actual "target" for > the discussion. Sure, but Wes had a good point with his example. Lada > > --Per -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Nov 8 08:13: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 4AEEB3A67EE for ; Mon, 8 Nov 2010 08:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fAgB4PE517Or for ; Mon, 8 Nov 2010 08:13:06 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id AB46A3A67F2 for ; Mon, 8 Nov 2010 08:13:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTNghpPp4St8/f+kTKKPgkcBO1NZ1o1Bi@postini.com; Mon, 08 Nov 2010 08:13:28 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 08:11:35 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oA8GBYU29348; Mon, 8 Nov 2010 08:11:34 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oA8FoL2Y025496; Mon, 8 Nov 2010 15:50:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011081550.oA8FoL2Y025496@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1289228994.1491.39.camel@nomad> Date: Mon, 8 Nov 2010 10:50:21 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 16:13:07 -0000 Ladislav Lhotka writes: >The multibyte EOM makes this complicated because the problematic >sequences may be split between subsequent frames. For this particular >purpose, the single-byte EOM that must not occur at all in the message >is IMO much easier to deal with. +1, with another appeal to find a better way before this protocol becomes widely deployed. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Nov 8 08: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 493053A6804 for ; Mon, 8 Nov 2010 08:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlfO16JNckb7 for ; Mon, 8 Nov 2010 08:24:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 97E0D3A67EE for ; Mon, 8 Nov 2010 08:24:33 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76BE4C001E; Mon, 8 Nov 2010 17:24:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iaVRtbwrN-Gy; Mon, 8 Nov 2010 17:24:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2233C0008; Mon, 8 Nov 2010 17:24:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 31FEF15995B7; Mon, 8 Nov 2010 17:24:53 +0100 (CET) Date: Mon, 8 Nov 2010 17:24:52 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20101108162452.GE54141@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , netconf@ietf.org References: <1289228994.1491.39.camel@nomad> <201011081550.oA8FoL2Y025496@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011081550.oA8FoL2Y025496@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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: Mon, 08 Nov 2010 16:24:35 -0000 On Mon, Nov 08, 2010 at 10:50:21AM -0500, Phil Shafer wrote: > Ladislav Lhotka writes: > >The multibyte EOM makes this complicated because the problematic > >sequences may be split between subsequent frames. For this particular > >purpose, the single-byte EOM that must not occur at all in the message > >is IMO much easier to deal with. > > +1, with another appeal to find a better way before this protocol > becomes widely deployed. And your proposal how to transition without breaking existing systems is? Or is the argument the number is not big yet, so we have a flag day? /js PS: If we ever fix this, we should consider adding a mechanism in which client and server exchange an ASCII CRLF terminated line with version information etc. before they start throwing XML documents at each other. This will enable us to actually change the version in the XML namespace at some point in time - currently that is not possible. SSH pretty much does it this way and it is a cool solution to versioning issues - greet each other at the most basic language before you engage into a more complex dialogue. -- 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 Mon Nov 8 08:37: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 5F7113A6957 for ; Mon, 8 Nov 2010 08:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 hAeA6QN4eifI for ; Mon, 8 Nov 2010 08:37:29 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 72A223A68ED for ; Mon, 8 Nov 2010 08:37:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTNgnXI0FP1zGw//VcaFxZtBfeQ/RrSoi@postini.com; Mon, 08 Nov 2010 08:37:51 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 08:37:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oA8GbjU43390; Mon, 8 Nov 2010 08:37:45 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oA8GGVbv026031; Mon, 8 Nov 2010 16:16:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011081616.oA8GGVbv026031@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20101108162452.GE54141@elstar.local> Date: Mon, 8 Nov 2010 11:16:31 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 16:37:31 -0000 Juergen Schoenwaelder writes: >And your proposal how to transition without breaking existing systems >is? Or is the argument the number is not big yet, so we have a flag >day? Create a new ssh subsystem named "netconf-eom" that uses the single byte 0x04 as the EOM, reachable over the existing NETCONF port. While this is not the real message framing that I proposed, Lada's idea of using a single non-XML byte is by far the more simple solution, allows the existing transport to operation in parallel, and allows the "]]>]]>" to be deprecated asap. The cost is opening a second connection if the server does not implement the new eom mechanism, and clients can cache this knowledge of what transport mapping each server implements to reduce this cost. Thanks, Phil From lhotka@cesnet.cz Mon Nov 8 08:46: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 BFDE33A67EE for ; Mon, 8 Nov 2010 08:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 EFhVqfcq8+UI for ; Mon, 8 Nov 2010 08:46:25 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 850C73A67CC for ; Mon, 8 Nov 2010 08:46:24 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 96AB72CDE05B; Mon, 8 Nov 2010 17:46:40 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201011081616.oA8GGVbv026031@idle.juniper.net> References: <201011081616.oA8GGVbv026031@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 09 Nov 2010 00:46:37 +0800 Message-ID: <1289234797.1491.96.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 16:46:26 -0000 On Po, 2010-11-08 at 11:16 -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >And your proposal how to transition without breaking existing systems > >is? Or is the argument the number is not big yet, so we have a flag > >day? > > Create a new ssh subsystem named "netconf-eom" that uses the single > byte 0x04 as the EOM, reachable over the existing NETCONF port. > > While this is not the real message framing that I proposed, Lada's > idea of using a single non-XML byte is by far the more simple > solution, allows the existing transport to operation in parallel, > and allows the "]]>]]>" to be deprecated asap. The cost is opening > a second connection if the server does not implement the new eom > mechanism, and clients can cache this knowledge of what transport > mapping each server implements to reduce this cost. Right, and it does fix a bug, so it is well within the mandate of 4742bis. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Mon Nov 8 08:53: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 250B73A696C for ; Mon, 8 Nov 2010 08:53:59 -0800 (PST) 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=[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 6nNBaNuVGr3u for ; Mon, 8 Nov 2010 08:53:58 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 34CDB28C0E4 for ; Mon, 8 Nov 2010 08:53:58 -0800 (PST) Received: (qmail 62713 invoked from network); 8 Nov 2010 16:54:11 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 08 Nov 2010 08:54:11 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 4H7oyOcVM1kshDKCQW41sKUI._64mlmfM0IbelsivBZu28g FB.c4P2DEhrJs3wo9_cxgAsubKicwWZpGVcg52YDgGqnCLpAPLUHIdmO2YZ. o52FgE5Q7c99k.krRVCk76aYuGo4Vjny2mnUrt_T4iRA5Kq9cbhc.vmMzoe0 JYEabnLzEDyHZbfBvbSQELXxR1Eh3nEmWz4uTorMoVkN.N1huY1Ffd390BHv VZBMMrnFgfV7tOSlZwxz8Aq6eOk6vsf7E.jYn6VgieOauh1iYh1Qo.QrewA9 geH6W4w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CD82B30.7060905@andybierman.com> Date: Mon, 08 Nov 2010 08:54:08 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: netconf@ietf.org References: <1289228994.1491.39.camel@nomad> <201011081550.oA8FoL2Y025496@idle.juniper.net> <20101108162452.GE54141@elstar.local> In-Reply-To: <20101108162452.GE54141@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 16:53:59 -0000 On 11/08/2010 08:24 AM, Juergen Schoenwaelder wrote: > On Mon, Nov 08, 2010 at 10:50:21AM -0500, Phil Shafer wrote: >> Ladislav Lhotka writes: >>> The multibyte EOM makes this complicated because the problematic >>> sequences may be split between subsequent frames. For this particular >>> purpose, the single-byte EOM that must not occur at all in the message >>> is IMO much easier to deal with. >> >> +1, with another appeal to find a better way before this protocol >> becomes widely deployed. > > And your proposal how to transition without breaking existing systems > is? Or is the argument the number is not big yet, so we have a flag > day? > > /js > > PS: If we ever fix this, we should consider adding a mechanism in > which client and server exchange an ASCII CRLF terminated line > with version information etc. before they start throwing XML > documents at each other. This will enable us to actually change > the version in the XML namespace at some point in time - currently > that is not possible. SSH pretty much does it this way and it is a > cool solution to versioning issues - greet each other at the most > basic language before you engage into a more complex dialogue. > I disagree. We have a exchange in 4741bis that determines if both peers agree to use base:1.1, base:1.0, or no agreement and the session is closed. There is no flag day if the new transport uses a different subsystem. There are other issues though. A new server is going to need to listen on the old and new subsystem. This is problematic in openssh: Port 830 Subsystem netconf /usr/sbin/netconf-subsystem Subsystem netconf-eom /usr/bin/netconf-eom-subsystem This sort of hack is needed so the netconf server will know which subsystem was actually requested by the client. Another concern: Is base:1.0 over netconf-eom allowed/required/optional? That is more complexity and more server variants than I want. By the time this is done there will be base:1.0, base:1.1, and base:2.0, plus 2 different subsystems. Will all combinations be supported? IMO, the operational problems created by EOM changes are almost as bad as the operational problems perceived to exist already with the ]]>]]> sequence. Andy From lhotka@cesnet.cz Mon Nov 8 09:12:40 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 9F25228C120 for ; Mon, 8 Nov 2010 09:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 IiLwzbiCpaWs for ; Mon, 8 Nov 2010 09:12:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 30CE33A69D4 for ; Mon, 8 Nov 2010 09:11:51 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3EA812CDE057; Mon, 8 Nov 2010 18:12:09 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4CD82B30.7060905@andybierman.com> References: <1289228994.1491.39.camel@nomad> <201011081550.oA8FoL2Y025496@idle.juniper.net> <20101108162452.GE54141@elstar.local> <4CD82B30.7060905@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 09 Nov 2010 01:12:04 +0800 Message-ID: <1289236324.1491.98.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 17:12:41 -0000 On Po, 2010-11-08 at 08:54 -0800, Andy Bierman wrote: > On 11/08/2010 08:24 AM, Juergen Schoenwaelder wrote: > > On Mon, Nov 08, 2010 at 10:50:21AM -0500, Phil Shafer wrote: > >> Ladislav Lhotka writes: > >>> The multibyte EOM makes this complicated because the problematic > >>> sequences may be split between subsequent frames. For this particular > >>> purpose, the single-byte EOM that must not occur at all in the message > >>> is IMO much easier to deal with. > >> > >> +1, with another appeal to find a better way before this protocol > >> becomes widely deployed. > > > > And your proposal how to transition without breaking existing systems > > is? Or is the argument the number is not big yet, so we have a flag > > day? > > > > /js > > > > PS: If we ever fix this, we should consider adding a mechanism in > > which client and server exchange an ASCII CRLF terminated line > > with version information etc. before they start throwing XML > > documents at each other. This will enable us to actually change > > the version in the XML namespace at some point in time - currently > > that is not possible. SSH pretty much does it this way and it is a > > cool solution to versioning issues - greet each other at the most > > basic language before you engage into a more complex dialogue. > > > > I disagree. > We have a exchange in 4741bis that determines if both peers agree > to use base:1.1, base:1.0, or no agreement and the session is closed. > > There is no flag day if the new transport uses a different subsystem. > > There are other issues though. > > A new server is going to need to listen on the old and new subsystem. > This is problematic in openssh: > > Port 830 > Subsystem netconf /usr/sbin/netconf-subsystem > Subsystem netconf-eom /usr/bin/netconf-eom-subsystem > > This sort of hack is needed so the netconf server will know which subsystem was > actually requested by the client. > > Another concern: Is base:1.0 over netconf-eom allowed/required/optional? > That is more complexity and more server variants than I want. > By the time this is done there will be base:1.0, base:1.1, and base:2.0, > plus 2 different subsystems. Will all combinations be supported? > > IMO, the operational problems created by EOM changes are almost as bad as the > operational problems perceived to exist already with the ]]>]]> sequence. This will be true only till the first exploit. In contrast, the new transport means controlled damage. Lada > > > Andy > > > _______________________________________________ > 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 Mon Nov 8 09:50: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 CC3FB3A67F2 for ; Mon, 8 Nov 2010 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0279IeI5Gvb for ; Mon, 8 Nov 2010 09:50:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A49C53A680F for ; Mon, 8 Nov 2010 09:50:30 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FE60C0027; Mon, 8 Nov 2010 18:50:52 +0100 (CET) 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 EfBK2vxcCqh2; Mon, 8 Nov 2010 18:50:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EC0EC0008; Mon, 8 Nov 2010 18:50:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B71D1159991E; Mon, 8 Nov 2010 18:50:50 +0100 (CET) Date: Mon, 8 Nov 2010 18:50:50 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20101108175050.GA54516@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , netconf@ietf.org References: <20101108162452.GE54141@elstar.local> <201011081616.oA8GGVbv026031@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011081616.oA8GGVbv026031@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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: Mon, 08 Nov 2010 17:50:32 -0000 On Mon, Nov 08, 2010 at 11:16:31AM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >And your proposal how to transition without breaking existing systems > >is? Or is the argument the number is not big yet, so we have a flag > >day? > > Create a new ssh subsystem named "netconf-eom" that uses the single > byte 0x04 as the EOM, reachable over the existing NETCONF port. > > While this is not the real message framing that I proposed, Lada's > idea of using a single non-XML byte is by far the more simple > solution, allows the existing transport to operation in parallel, > and allows the "]]>]]>" to be deprecated asap. The cost is opening > a second connection if the server does not implement the new eom > mechanism, and clients can cache this knowledge of what transport > mapping each server implements to reduce this cost. Late evening idea: What does RFC4741 say concerning empty messages? Would it work to send ]]>]]> or even ]]>]]>]]>]]> at the very beginning of a session, that is before the , as an indicator that a new framing mechanism is supported? Would current 4741bis implementations simply skip over this? If so, we could perhaps avoid introducing a new subsystem. /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 Mon Nov 8 10:03:48 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 8274A3A680F for ; Mon, 8 Nov 2010 10:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 IsijMvUlA-Hc for ; Mon, 8 Nov 2010 10:03:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B90313A67FB for ; Mon, 8 Nov 2010 10:03:47 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B254616001; Mon, 8 Nov 2010 19:04:08 +0100 (CET) Date: Mon, 08 Nov 2010 19:04:07 +0100 (CET) Message-Id: <20101108.190407.171805815.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201011081616.oA8GGVbv026031@idle.juniper.net> References: <20101108162452.GE54141@elstar.local> <201011081616.oA8GGVbv026031@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] escaping EoM 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, 08 Nov 2010 18:03:48 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: > >And your proposal how to transition without breaking existing systems > >is? Or is the argument the number is not big yet, so we have a flag > >day? > > Create a new ssh subsystem named "netconf-eom" that uses the single > byte 0x04 as the EOM, reachable over the existing NETCONF port. > > While this is not the real message framing that I proposed, Lada's > idea of using a single non-XML byte is by far the more simple > solution, Yes it is the simplest idea. Note though that 0x04 is legal in XML 1.1, so if we ever want to support XML 1.1, this will break. /martin From mbj@tail-f.com Mon Nov 8 10:23: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 4329F3A6933 for ; Mon, 8 Nov 2010 10:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 lCwOMO0Pcvhc for ; Mon, 8 Nov 2010 10:23:40 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2C52E3A6848 for ; Mon, 8 Nov 2010 10:23:40 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 60703616001; Mon, 8 Nov 2010 19:24:01 +0100 (CET) Date: Mon, 08 Nov 2010 19:23:58 +0100 (CET) Message-Id: <20101108.192358.35158134.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101108175050.GA54516@elstar.local> References: <20101108162452.GE54141@elstar.local> <201011081616.oA8GGVbv026031@idle.juniper.net> <20101108175050.GA54516@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] escaping EoM 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, 08 Nov 2010 18:23:41 -0000 Juergen Schoenwaelder wrote: > Late evening idea: What does RFC4741 say concerning empty messages? It says that messages are XML documents, and xml documents cannot be empty: $ touch foo $ xmllint foo foo:1: parser error : Document is empty ^ foo:1: parser error : Start tag expected, '<' not found ^ > Would it work to send ]]>]]> or even ]]>]]>]]>]]> at the very > beginning of a session, that is before the , as an indicator > that a new framing mechanism is supported? Would current 4741bis > implementations simply skip over this? Nope, sorry. /martin From mbj@tail-f.com Mon Nov 8 13:13: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 6C4CD3A68C5 for ; Mon, 8 Nov 2010 13:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 34LU3sj1wVq4 for ; Mon, 8 Nov 2010 13:13:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9EB013A68B1 for ; Mon, 8 Nov 2010 13:13:41 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B8757616001; Mon, 8 Nov 2010 22:14:01 +0100 (CET) Date: Mon, 08 Nov 2010 22:14:00 +0100 (CET) Message-Id: <20101108.221400.267768345.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <20101108.190407.171805815.mbj@tail-f.com> References: <20101108162452.GE54141@elstar.local> <201011081616.oA8GGVbv026031@idle.juniper.net> <20101108.190407.171805815.mbj@tail-f.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 21:13:42 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >And your proposal how to transition without breaking existing systems > > >is? Or is the argument the number is not big yet, so we have a flag > > >day? > > > > Create a new ssh subsystem named "netconf-eom" that uses the single > > byte 0x04 as the EOM, reachable over the existing NETCONF port. > > > > While this is not the real message framing that I proposed, Lada's > > idea of using a single non-XML byte is by far the more simple > > solution, > > Yes it is the simplest idea. Note though that 0x04 is legal in XML > 1.1, so if we ever want to support XML 1.1, this will break. Correcting myself: 0x04 is allowed, but not unescaped; only as a character reference. So 0x04 should be ok. Sorry about the noise. /martin From biermana@Brocade.com Mon Nov 8 13:37: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 AFEF13A68D5 for ; Mon, 8 Nov 2010 13:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 Dqg3M3pyH4xs for ; Mon, 8 Nov 2010 13:37:26 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 3F57D3A67E5 for ; Mon, 8 Nov 2010 13:37:26 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oA8LaNxE006864; Mon, 8 Nov 2010 13:37:48 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id ser3y01pm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 08 Nov 2010 13:37:48 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 13:38:18 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 8 Nov 2010 13:37:46 -0800 From: Andy Bierman To: Martin Bjorklund , "phil@juniper.net" Date: Mon, 8 Nov 2010 13:37:44 -0800 Thread-Topic: [Netconf] escaping EoM Thread-Index: Act/b1uBgoiIDE3+S32o3c8AgmrC+wAHUhSA Message-ID: References: <20101108162452.GE54141@elstar.local> <201011081616.oA8GGVbv026031@idle.juniper.net> <20101108.190407.171805815.mbj@tail-f.com> In-Reply-To: <20101108.190407.171805815.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-08_11:2010-11-08, 2010-11-08, 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-1011080122 Cc: "netconf@ietf.org" Subject: Re: [Netconf] escaping EoM 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, 08 Nov 2010 21:37:30 -0000 Hi Martin, Illegal in XML 1.1? Then this is not a lasting solution, is it? Being tied to a someday-obsolete version of XML is not an option. What if libxml2 stops supporting XML 1.0 in the future? Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Monday, November 08, 2010 10:04 AM To: phil@juniper.net Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM Phil Shafer wrote: > Juergen Schoenwaelder writes: > >And your proposal how to transition without breaking existing systems > >is? Or is the argument the number is not big yet, so we have a flag > >day? >=20 > Create a new ssh subsystem named "netconf-eom" that uses the single > byte 0x04 as the EOM, reachable over the existing NETCONF port. >=20 > While this is not the real message framing that I proposed, Lada's > idea of using a single non-XML byte is by far the more simple > solution, Yes it is the simplest idea. Note though that 0x04 is legal in XML 1.1, so if we ever want to support XML 1.1, this will break. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Mon Nov 8 16:20: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 85CE63A68BC for ; Mon, 8 Nov 2010 16:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.995 X-Spam-Level: X-Spam-Status: No, score=-102.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ficNdnUSDqkg for ; Mon, 8 Nov 2010 16:20:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 56DD73A6860 for ; Mon, 8 Nov 2010 16:20:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D71AC000E for ; Tue, 9 Nov 2010 01:20:26 +0100 (CET) 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 TT-aPTBLx6ZB; Tue, 9 Nov 2010 01:20:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 648DDC000C; Tue, 9 Nov 2010 01:20:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2C5A1599F94; Tue, 9 Nov 2010 01:20:24 +0100 (CET) Date: Tue, 9 Nov 2010 01:20:24 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20101109002022.GB55071@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 00:20:05 -0000 Hi, Bert mentioned today that we should look into XML access control work and see if/how this applies to NETCONF. One often cited XML access control piece of work is XACML defined by OASIS [1]. There has been a paper on how to use XACML for NETCONF [2]. There has also been some academic work where they decided against XACML [3]. Of course, the NETCONF ACM applies to the NETCONF configuration database and to operations invoked by NETCONF; the ACM does not apply to the XML serialization used on the wire. NETCONF is not an XML database - it is a protocol that just happens to use XML to encode messages. /js [1] http://www.oasis-open.org/committees/xacml/ [2] http://eprints.sics.se/2905/01/report.pdf [3] http://dx.doi.org/10.1109/TNSM.2006.4798304 -- 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 Mon Nov 8 17:53: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 3E1423A68FF for ; Mon, 8 Nov 2010 17:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 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 m0DwNQJ9mo34 for ; Mon, 8 Nov 2010 17:53:14 -0800 (PST) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 0C9A13A68FA for ; Mon, 8 Nov 2010 17:53:13 -0800 (PST) Received: (qmail 51845 invoked from network); 9 Nov 2010 01:53:32 -0000 Received: from [130.129.115.111] (ietf@130.129.115.111 with plain) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 08 Nov 2010 17:53:31 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 0cl5Q9kVM1mdFLVvUesdEEioybxTxLHhjDWZS2E_HpNiG9R g7o7IKn4S6prnb2eQncvvgI3vm.hAlExFdFnh7n.PzcwbHaCqa7d1Phr8rlC TGYptTpGXFMezvnACn9QeAduVEQ1pM16GY.PbNnp2OI8O9k57aBVHzWeyeOo gISPu2LjqPsuWZmiQU_4SUR6oNqKp4_EwANrFW37Rl67kNM9BQKoMdeW3.Xs 0Cd.kcYGX69njJlaSxzqAxTnHq7h29BKl4IQk9OKI6pT4fhYKT5sQ4jmfeda kUJL9muU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CD8A99A.608@andybierman.com> Date: Mon, 08 Nov 2010 17:53:30 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: netconf@ietf.org References: <20101109002022.GB55071@elstar.local> In-Reply-To: <20101109002022.GB55071@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 01:53:15 -0000 On 11/08/2010 04:20 PM, Juergen Schoenwaelder wrote: > Hi, > > Bert mentioned today that we should look into XML access control work > and see if/how this applies to NETCONF. One often cited XML access > control piece of work is XACML defined by OASIS [1]. There has been > a paper on how to use XACML for NETCONF [2]. There has also been > some academic work where they decided against XACML [3]. > Thanks for finding this. I have not read [2] completely, but my initial reaction is that the configuration of access control rules is way too complicated. My main goal is to provide a solution that covers all aspects of NETCONF server behavior that is as easy as possible to configure. Pilot error due to excessive complexity is a real concern, especially for security configuration. > Of course, the NETCONF ACM applies to the NETCONF configuration > database and to operations invoked by NETCONF; the ACM does not apply > to the XML serialization used on the wire. NETCONF is not an XML > database - it is a protocol that just happens to use XML to encode > messages. agreed > > /js Andy > > [1] http://www.oasis-open.org/committees/xacml/ > [2] http://eprints.sics.se/2905/01/report.pdf > [3] http://dx.doi.org/10.1109/TNSM.2006.4798304 > From mehmet.ersue@nsn.com Mon Nov 8 18:17: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 6DB5628C274 for ; Mon, 8 Nov 2010 18:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.321 X-Spam-Level: X-Spam-Status: No, score=-101.321 tagged_above=-999 required=5 tests=[AWL=1.278, 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 FXMEpoEa1BHY for ; Mon, 8 Nov 2010 18:17:00 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8B7EC28C1DA for ; Mon, 8 Nov 2010 18:16:21 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oA92Gep4001562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Nov 2010 03:16:40 +0100 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 oA92Ge7h002831; Tue, 9 Nov 2010 03:16:40 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 03:16:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 03:16:37 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401307A06@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] escaping EoM Thread-Index: Act/b1uBgoiIDE3+S32o3c8AgmrC+wAHUhSAAAm5r0A= References: <20101108162452.GE54141@elstar.local><201011081616.oA8GGVbv026031@idle.juniper.net><20101108.190407.171805815.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Martin Bjorklund" , , "ext Per Hedeland" , "Ladislav Lhotka" X-OriginalArrivalTime: 09 Nov 2010 02:16:40.0097 (UTC) FILETIME=[24F38110:01CB7FB4] Cc: netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 09 Nov 2010 02:17:01 -0000 Folks, please consider that the current discussion on EOM handling is not for 1.0. So, we may think a bit broader than the 1.0 borders. We can use the discussion result for a 2.0 though there is no plan or charter for this work yet. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Andy Bierman > Sent: Monday, November 08, 2010 10:38 PM > To: Martin Bjorklund; phil@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] escaping EoM >=20 > Hi Martin, >=20 > Illegal in XML 1.1? > Then this is not a lasting solution, is it? > Being tied to a someday-obsolete version of XML is not an option. > What if libxml2 stops supporting XML 1.0 in the future? >=20 >=20 > Andy >=20 >=20 >=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Monday, November 08, 2010 10:04 AM > To: phil@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] escaping EoM >=20 > Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >And your proposal how to transition without breaking existing > systems > > >is? Or is the argument the number is not big yet, so we have a flag > > >day? > > > > Create a new ssh subsystem named "netconf-eom" that uses the single > > byte 0x04 as the EOM, reachable over the existing NETCONF port. > > > > While this is not the real message framing that I proposed, Lada's > > idea of using a single non-XML byte is by far the more simple > > solution, >=20 > Yes it is the simplest idea. Note though that 0x04 is legal in XML > 1.1, so if we ever want to support XML 1.1, this will break. >=20 >=20 > /martin > _______________________________________________ > 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 bertietf@bwijnen.net Mon Nov 8 19:12: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 D5B2C3A6A2E for ; Mon, 8 Nov 2010 19:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 hMzEs+utZaPi for ; Mon, 8 Nov 2010 19:12:53 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id F1DC23A6A60 for ; Mon, 8 Nov 2010 19:12:37 -0800 (PST) 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 1PFedi-00060o-8l for netconf@ietf.org; Tue, 09 Nov 2010 04:13:00 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-60fe.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PFedh-0007H1-QX for netconf@ietf.org; Tue, 09 Nov 2010 04:12:54 +0100 Message-ID: <4CD8BC33.3020700@bwijnen.net> Date: Tue, 09 Nov 2010 11:12:51 +0800 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: netconf@ietf.org References: <20101109002022.GB55071@elstar.local> In-Reply-To: <20101109002022.GB55071@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46cac1d36f6ecbffe75b081c7eb081aed X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46cac1d36f6ecbffe75b081c7eb081aed Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 03:12:54 -0000 Thanks for finding these. I'll check them out, or at least take a peak at them Bert On 11/9/10 8:20 AM, Juergen Schoenwaelder wrote: > Hi, > > Bert mentioned today that we should look into XML access control work > and see if/how this applies to NETCONF. One often cited XML access > control piece of work is XACML defined by OASIS [1]. There has been > a paper on how to use XACML for NETCONF [2]. There has also been > some academic work where they decided against XACML [3]. > > Of course, the NETCONF ACM applies to the NETCONF configuration > database and to operations invoked by NETCONF; the ACM does not apply > to the XML serialization used on the wire. NETCONF is not an XML > database - it is a protocol that just happens to use XML to encode > messages. > > /js > > [1] http://www.oasis-open.org/committees/xacml/ > [2] http://eprints.sics.se/2905/01/report.pdf > [3] http://dx.doi.org/10.1109/TNSM.2006.4798304 > From lhotka@cesnet.cz Mon Nov 8 19:32: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 C60AB28C2BE for ; Mon, 8 Nov 2010 19:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 adUrx7abXg53 for ; Mon, 8 Nov 2010 19:32:03 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 93C1A28C247 for ; Mon, 8 Nov 2010 19:32:02 -0800 (PST) Received: from [130.129.55.66] (dhcp-3742.meeting.ietf.org [130.129.55.66]) by office2.cesnet.cz (Postfix) with ESMTPSA id 621B62CDE05E for ; Tue, 9 Nov 2010 04:32:23 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <20101109002022.GB55071@elstar.local> References: <20101109002022.GB55071@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 09 Nov 2010 11:32:16 +0800 Message-ID: <1289273536.2429.42.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 03:32:03 -0000 On Út, 2010-11-09 at 01:20 +0100, Juergen Schoenwaelder wrote: > Hi, > > Bert mentioned today that we should look into XML access control work > and see if/how this applies to NETCONF. One often cited XML access > control piece of work is XACML defined by OASIS [1]. There has been > a paper on how to use XACML for NETCONF [2]. There has also been > some academic work where they decided against XACML [3]. > > Of course, the NETCONF ACM applies to the NETCONF configuration > database and to operations invoked by NETCONF; the ACM does not apply > to the XML serialization used on the wire. NETCONF is not an XML > database - it is a protocol that just happens to use XML to encode > messages. XML is not just the serialized form. I assume the NETCONF database has to be modelled (at least conceptually) as XML infoset because we use XPath to query it etc. This is not to say that XACML is of any use. On the other hand, access control models of other hierarchical databases such as LDAP could be considered. Lada > > /js > > [1] http://www.oasis-open.org/committees/xacml/ > [2] http://eprints.sics.se/2905/01/report.pdf > [3] http://dx.doi.org/10.1109/TNSM.2006.4798304 > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Nov 8 19:36: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 5AAA028C311 for ; Mon, 8 Nov 2010 19:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 C90VyZ2vsVaD for ; Mon, 8 Nov 2010 19:36:18 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 24DC028C30E for ; Mon, 8 Nov 2010 19:35:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTNjBlsfFi0P6Z8FT4+rooq5RVZ1zSFqo@postini.com; Mon, 08 Nov 2010 19:36:33 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 19:32:28 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oA93WQU89897; Mon, 8 Nov 2010 19:32:27 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oA93BCQv036067; Tue, 9 Nov 2010 03:11:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011090311.oA93BCQv036067@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401307A06@DEMUEXC006.nsn-intra.net> Date: Mon, 8 Nov 2010 22:11:12 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: ext Andy Bierman , netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 09 Nov 2010 03:36:20 -0000 "Ersue, Mehmet (NSN - DE/Munich)" writes: >please consider that the current discussion on EOM handling is not for >1.0. >So, we may think a bit broader than the 1.0 borders. >We can use the discussion result for a 2.0 though there is no plan or >charter for this work yet. Why is this not for 1.1 (aka -bis)? Thanks, Phil From ietf@andybierman.com Mon Nov 8 20:23: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 78DB33A6924 for ; Mon, 8 Nov 2010 20:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, 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 LMewy+wldVYk for ; Mon, 8 Nov 2010 20:23:49 -0800 (PST) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by core3.amsl.com (Postfix) with SMTP id F37F03A6862 for ; Mon, 8 Nov 2010 20:23:48 -0800 (PST) Received: from [98.139.91.67] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 04:24:09 -0000 Received: from [98.139.91.21] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 04:24:09 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 09 Nov 2010 04:24:09 -0000 X-Yahoo-Newman-Id: 194897.94524.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 89934 invoked from network); 9 Nov 2010 04:24:09 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 08 Nov 2010 20:24:08 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Q1qRr9AVM1lx7WT8Lp90tlB6cRCMhWXXvpEQfhvT7Eqr4zU afLDLGn0cNIYCM6gI86sBaTzjRxfJVMKWoFB1B.Dxe34NOeTLEsBQbiL19CF BgBFR96Xgubk02rvKWvbc_J3isFsOy_3m6gcExjDNOndA30KmsljK81Vi7sH OjvkrwYOSOxThnB9apyT6K41Sjp32k8UQEAuPe3gymRLgPA_iYQwk6cJ23C5 4uX3YeeHRJAObqdKaU6mVUczpvRQxvIvpsdlr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CD8CCE6.2060601@andybierman.com> Date: Mon, 08 Nov 2010 20:24:06 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Ladislav Lhotka References: <20101109002022.GB55071@elstar.local> <1289273536.2429.42.camel@nomad> In-Reply-To: <1289273536.2429.42.camel@nomad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 04:23:50 -0000 On 11/08/2010 07:32 PM, Ladislav Lhotka wrote: > On Út, 2010-11-09 at 01:20 +0100, Juergen Schoenwaelder wrote: >> Hi, >> >> Bert mentioned today that we should look into XML access control work >> and see if/how this applies to NETCONF. One often cited XML access >> control piece of work is XACML defined by OASIS [1]. There has been >> a paper on how to use XACML for NETCONF [2]. There has also been >> some academic work where they decided against XACML [3]. >> >> Of course, the NETCONF ACM applies to the NETCONF configuration >> database and to operations invoked by NETCONF; the ACM does not apply >> to the XML serialization used on the wire. NETCONF is not an XML >> database - it is a protocol that just happens to use XML to encode >> messages. > > XML is not just the serialized form. I assume the NETCONF database has > to be modelled (at least conceptually) as XML infoset because we use > XPath to query it etc. > ll There are corner cases where a NETCONF server may not support all XPath expressions the same way, as documented in the YANG Usage Guidelines. > This is not to say that XACML is of any use. On the other hand, access > control models of other hierarchical databases such as LDAP could be > considered. We are using XPath to specify the data rules. We have optimizations that address specific NETCONF operational requirements. The easy part is specifying an ACL. The hard part is specifying the procedures a server must follow so that the same ACL on 2 different servers produces the same NETCONF protocol behavior. > > Lada Andy From Internet-Drafts@ietf.org Mon Nov 8 20:30: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 89DB13A6358; Mon, 8 Nov 2010 20:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 STvYnUXFlkPn; Mon, 8 Nov 2010 20:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1613A677C; Mon, 8 Nov 2010 20:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109043002.24035.76538.idtracker@localhost> Date: Mon, 08 Nov 2010 20:30:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.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: Tue, 09 Nov 2010 04:30: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 : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-13.txt Pages : 32 Date : 2010-11-08 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08202851.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Mon Nov 8 21:51: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 D6BBC3A68DA for ; Mon, 8 Nov 2010 21:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.686 X-Spam-Level: X-Spam-Status: No, score=-101.686 tagged_above=-999 required=5 tests=[AWL=0.913, 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 Wzk7Cq3gh+pN for ; Mon, 8 Nov 2010 21:51:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 284BA3A67DA for ; Mon, 8 Nov 2010 21:51:01 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oA95pKA1025413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Nov 2010 06:51:20 +0100 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 oA95pH9Y009288; Tue, 9 Nov 2010 06:51:18 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 06:51:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 06:51:06 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401307A25@DEMUEXC006.nsn-intra.net> In-Reply-To: <201011090311.oA93BCQv036067@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] escaping EoM Thread-Index: Act/v0+UMbGZ8aqiSfOffeteKIbyJgAEisHA References: <80A0822C5E9A4440A5117C2F4CD36A6401307A06@DEMUEXC006.nsn-intra.net> <201011090311.oA93BCQv036067@idle.juniper.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Phil Shafer" X-OriginalArrivalTime: 09 Nov 2010 05:51:10.0171 (UTC) FILETIME=[1C1CF2B0:01CB7FD2] Cc: ext Andy Bierman , netconf@ietf.org Subject: Re: [Netconf] escaping EoM 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, 09 Nov 2010 05:51:05 -0000 An appropriate solution produces a version incompatible with 1.0=20 and needs to be addressed by more than one -bis (4741, 4742). So, this is effectively 2.0. Cheers, Mehmet > -----Original Message----- > From: ext Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, November 09, 2010 4:11 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: ext Andy Bierman; Martin Bjorklund; ext Per Hedeland; Ladislav > Lhotka; netconf@ietf.org > Subject: Re: [Netconf] escaping EoM >=20 > "Ersue, Mehmet (NSN - DE/Munich)" writes: > >please consider that the current discussion on EOM handling is not for > >1.0. > >So, we may think a bit broader than the 1.0 borders. > >We can use the discussion result for a 2.0 though there is no plan or > >charter for this work yet. >=20 > Why is this not for 1.1 (aka -bis)? >=20 > Thanks, > Phil From bertietf@bwijnen.net Mon Nov 8 23:48: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 4A98228C0E8 for ; Mon, 8 Nov 2010 23:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 NKWbcMDQhWI8 for ; Mon, 8 Nov 2010 23:48:58 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 2BBC328C0E2 for ; Mon, 8 Nov 2010 23:48:44 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PFiws-0007nI-Sy for netconf@ietf.org; Tue, 09 Nov 2010 08:49:05 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-60fe.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PFiwr-0007ZI-Vd for netconf@ietf.org; Tue, 09 Nov 2010 08:48:58 +0100 Message-ID: <4CD8FCE7.70200@bwijnen.net> Date: Tue, 09 Nov 2010 15:48:55 +0800 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: netconf Content-Type: multipart/mixed; boundary="------------010803060600010706000004" X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd456a4f97c33fb5ee5f5b19aeb920302c4 X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd456a4f97c33fb5ee5f5b19aeb920302c4 Subject: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.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: Tue, 09 Nov 2010 07:48:59 -0000 This is a multi-part message in MIME format. --------------010803060600010706000004 Content-Type: multipart/alternative; boundary="------------050501040304000609040006" --------------050501040304000609040006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Netcon WG participants, This revision is the result of IETF LC and IESG review. While I am checking with the IESG if this revision indeed addresses all their concerns, pls take a look and speak up if you see anything weird. Do not re-open old issues that we have already decided on. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt Date: Mon, 08 Nov 2010 20:30:02 -0800 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-13.txt Pages : 32 Date : 2010-11-08 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-13.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. --------------050501040304000609040006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Netcon WG participants,

This revision is the result of IETF LC and IESG review.
While I am checking with the IESG if this revision indeed
addresses all their concerns, pls take a look and speak
up if you see anything weird.

Do not re-open old issues that we have already decided on.

Bert and Mehmet

-------- Original Message --------
Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt
Date: Mon, 08 Nov 2010 20:30:02 -0800
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
CC: netconf@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.


	Title           : With-defaults capability for NETCONF
	Author(s)       : A. Bierman, B. Lengyel
	Filename        : draft-ietf-netconf-with-defaults-13.txt
	Pages           : 32
	Date            : 2010-11-08

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-13.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.
--------------050501040304000609040006-- --------------010803060600010706000004 Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netconf-with-defaults-13.txt" Content-Type: text/plain Content-ID: <2010-11-08202851.I-D@ietf.org> --------------010803060600010706000004 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --------------010803060600010706000004-- From lhotka@cesnet.cz Tue Nov 9 00:03: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 1264D3A680C for ; Tue, 9 Nov 2010 00:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 AhyJSaf4iFfy for ; Tue, 9 Nov 2010 00:03:04 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id E5C463A63C9 for ; Tue, 9 Nov 2010 00:03:03 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0D8042CDE05B; Tue, 9 Nov 2010 09:03:23 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4CD8CCE6.2060601@andybierman.com> References: <20101109002022.GB55071@elstar.local> <1289273536.2429.42.camel@nomad> <4CD8CCE6.2060601@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 09 Nov 2010 16:03:15 +0800 Message-ID: <1289289795.1500.21.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 08:03:05 -0000 On Po, 2010-11-08 at 20:24 -0800, Andy Bierman wrote: > On 11/08/2010 07:32 PM, Ladislav Lhotka wrote: > > On Út, 2010-11-09 at 01:20 +0100, Juergen Schoenwaelder wrote: > >> Hi, > >> > >> Bert mentioned today that we should look into XML access control work > >> and see if/how this applies to NETCONF. One often cited XML access > >> control piece of work is XACML defined by OASIS [1]. There has been > >> a paper on how to use XACML for NETCONF [2]. There has also been > >> some academic work where they decided against XACML [3]. > >> > >> Of course, the NETCONF ACM applies to the NETCONF configuration > >> database and to operations invoked by NETCONF; the ACM does not apply > >> to the XML serialization used on the wire. NETCONF is not an XML > >> database - it is a protocol that just happens to use XML to encode > >> messages. > > > > XML is not just the serialized form. I assume the NETCONF database has > > to be modelled (at least conceptually) as XML infoset because we use > > XPath to query it etc. > > ll > > There are corner cases where a NETCONF server may not support all XPath > expressions the same way, as documented in the YANG Usage Guidelines. My point is that a NETCONF database in fact looks and behaves pretty much like XML and the mapping to serialized XML is straightforward, so I think "NETCONF is not XML" in not a valid reason for rejecting XACML (though I don't advocate it because I haven't read the spec). > > > This is not to say that XACML is of any use. On the other hand, access > > control models of other hierarchical databases such as LDAP could be > > considered. > > > We are using XPath to specify the data rules. > We have optimizations that address specific NETCONF operational requirements. > > The easy part is specifying an ACL. > The hard part is specifying the procedures a server must follow > so that the same ACL on 2 different servers produces the same NETCONF > protocol behavior. Right, and I reckon LDAP servers must have implemented solutions to some of these problems. Lada > > > > > > Lada > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Tue Nov 9 00:33:04 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 7E9CD3A689E for ; Tue, 9 Nov 2010 00:33:04 -0800 (PST) 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 RoiVu9ITr6Tl for ; Tue, 9 Nov 2010 00:33:00 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id D5DAD3A6818 for ; Tue, 9 Nov 2010 00:32:59 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oA98XMgt015734 for ; Tue, 9 Nov 2010 03:33:23 -0500 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [222.128.202.2] ([222.128.202.2:25044] helo=[10.40.72.159]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 86/32-32126-05709DC4; Tue, 09 Nov 2010 03:33:22 -0500 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" Message-ID: <86.32.32126.05709DC4@cm-omr7> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 09 Nov 2010 16:33:35 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1289291615796" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?xml_access_control_vs=2E_netconf_access_contr?= =?utf-8?q?ol?= 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, 09 Nov 2010 08:33:04 -0000 ------=_Part_1_1289291615796 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJTU8gZ2VuZXJpYyByZXF1aXJlbWVudHMgYXJlIG5vdCB1c2VmdWwuICBUaGUgTERBUCBz b2x1dGlvbiBpcyBzcGVjaWZpYyB0byB0aGF0IHR5cGUgb2Ygc2VydmVyLgoKV2hhdCBzcGVjaWZp YyBuZXRjb25mIHByb2JsZW1zIGRvZXMgdGhlIGxkYXAgc29sdXRpb24gYWRkcmVzcz8gRG9lcyBp dCBwcm92aWRlIGEgQ1JVRFggb3BlcmF0aW9uIG1vZGVsIGxpa2Ugd2UgbmVlZD8gIERvZXMgaXQg aW50ZWdyYXRlIHdpdGggcmFkaXVzPyBXaGF0IHNwZWNpZmljIHJlcXVpcmVtZW50cyBhcmUgbWV0 IHdoaWNoIG5ldGNvbmYgaXMgcmVpbnZlbnRpbmc/CgpBbmR5CgoKLS0tLS0gUmVwbHkgbWVzc2Fn ZSAtLS0tLQpGcm9tOiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQGNlc25ldC5jej4KRGF0ZTog VHVlLCBOb3YgOSwgMjAxMCAxNjowMwpTdWJqZWN0OiBbTmV0Y29uZl0geG1sIGFjY2VzcyBjb250 cm9sIHZzLiBuZXRjb25mIGFjY2VzcyBjb250cm9sClRvOiAiQW5keSBCaWVybWFuIiA8aWV0ZkBh bmR5Ymllcm1hbi5jb20+CkNjOiA8bmV0Y29uZkBpZXRmLm9yZz4KCgpPbiBQbywgMjAxMC0xMS0w OCBhdCAyMDoyNCAtMDgwMCwgQW5keSBCaWVybWFuIHdyb3RlOgo+IE9uIDExLzA4LzIwMTAgMDc6 MzIgUE0sIExhZGlzbGF2IExob3RrYSB3cm90ZToKPiA+IE9uIMOadCwgMjAxMC0xMS0wOSBhdCAw MToyMCArMDEwMCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOgo+ID4+IEhpLAo+ID4+Cj4g Pj4gQmVydCBtZW50aW9uZWQgdG9kYXkgdGhhdCB3ZSBzaG91bGQgbG9vayBpbnRvIFhNTCBhY2Nl c3MgY29udHJvbCB3b3JrCj4gPj4gYW5kIHNlZSBpZi9ob3cgdGhpcyBhcHBsaWVzIHRvIE5FVENP TkYuIE9uZSBvZnRlbiBjaXRlZCBYTUwgYWNjZXNzCj4gPj4gY29udHJvbCBwaWVjZSBvZiB3b3Jr IGlzIFhBQ01MIGRlZmluZWQgYnkgT0FTSVMgWzFdLiBUaGVyZSBoYXMgYmVlbgo+ID4+IGEgcGFw ZXIgb24gaG93IHRvIHVzZSBYQUNNTCBmb3IgTkVUQ09ORiBbMl0uIFRoZXJlIGhhcyBhbHNvIGJl ZW4KPiA+PiBzb21lIGFjYWRlbWljIHdvcmsgd2hlcmUgdGhleSBkZWNpZGVkIGFnYWluc3QgWEFD TUwgWzNdLgo+ID4+Cj4gPj4gT2YgY291cnNlLCB0aGUgTkVUQ09ORiBBQ00gYXBwbGllcyB0byB0 aGUgTkVUQ09ORiBjb25maWd1cmF0aW9uCj4gPj4gZGF0YWJhc2UgYW5kIHRvIG9wZXJhdGlvbnMg aW52b2tlZCBieSBORVRDT05GOyB0aGUgQUNNIGRvZXMgbm90IGFwcGx5Cj4gPj4gdG8gdGhlIFhN TCBzZXJpYWxpemF0aW9uIHVzZWQgb24gdGhlIHdpcmUuIE5FVENPTkYgaXMgbm90IGFuIFhNTAo+ ID4+IGRhdGFiYXNlIC0gaXQgaXMgYSBwcm90b2NvbCB0aGF0IGp1c3QgaGFwcGVucyB0byB1c2Ug WE1MIHRvIGVuY29kZQo+ID4+IG1lc3NhZ2VzLgo+ID4KPiA+IFhNTCBpcyBub3QganVzdCB0aGUg c2VyaWFsaXplZCBmb3JtLiBJIGFzc3VtZSB0aGUgTkVUQ09ORiBkYXRhYmFzZSBoYXMKPiA+IHRv IGJlIG1vZGVsbGVkIChhdCBsZWFzdCBjb25jZXB0dWFsbHkpIGFzIFhNTCBpbmZvc2V0IGJlY2F1 c2Ugd2UgdXNlCj4gPiBYUGF0aCB0byBxdWVyeSBpdCBldGMuCj4gPiBsbAo+IAo+IFRoZXJlIGFy ZSBjb3JuZXIgY2FzZXMgd2hlcmUgYSBORVRDT05GIHNlcnZlciBtYXkgbm90IHN1cHBvcnQgYWxs IFhQYXRoCj4gZXhwcmVzc2lvbnMgdGhlIHNhbWUgd2F5LCBhcyBkb2N1bWVudGVkIGluIHRoZSBZ QU5HIFVzYWdlIEd1aWRlbGluZXMuCgpNeSBwb2ludCBpcyB0aGF0IGEgTkVUQ09ORiBkYXRhYmFz ZSBpbiBmYWN0IGxvb2tzIGFuZCBiZWhhdmVzIHByZXR0eQptdWNoIGxpa2UgWE1MIGFuZCB0aGUg bWFwcGluZyB0byBzZXJpYWxpemVkIFhNTCBpcyBzdHJhaWdodGZvcndhcmQsIHNvIEkKdGhpbmsg Ik5FVENPTkYgaXMgbm90IFhNTCIgaW4gbm90IGEgdmFsaWQgcmVhc29uIGZvciByZWplY3Rpbmcg WEFDTUwKKHRob3VnaCBJIGRvbid0IGFkdm9jYXRlIGl0IGJlY2F1c2UgSSBoYXZlbid0IHJlYWQg dGhlIHNwZWMpLgoKPiAKPiA+IFRoaXMgaXMgbm90IHRvIHNheSB0aGF0IFhBQ01MIGlzIG9mIGFu eSB1c2UuIE9uIHRoZSBvdGhlciBoYW5kLCBhY2Nlc3MKPiA+IGNvbnRyb2wgbW9kZWxzIG9mIG90 aGVyIGhpZXJhcmNoaWNhbCBkYXRhYmFzZXMgc3VjaCBhcyBMREFQIGNvdWxkIGJlCj4gPiBjb25z aWRlcmVkLgo+IAo+IAo+IFdlIGFyZSB1c2luZyBYUGF0aCB0byBzcGVjaWZ5IHRoZSBkYXRhIHJ1 bGVzLgo+IFdlIGhhdmUgb3B0aW1pemF0aW9ucyB0aGF0IGFkZHJlc3Mgc3BlY2lmaWMgTkVUQ09O RiBvcGVyYXRpb25hbCByZXF1aXJlbWVudHMuCj4gCj4gVGhlIGVhc3kgcGFydCBpcyBzcGVjaWZ5 aW5nIGFuIEFDTC4KPiBUaGUgaGFyZCBwYXJ0IGlzIHNwZWNpZnlpbmcgdGhlIHByb2NlZHVyZXMg YSBzZXJ2ZXIgbXVzdCBmb2xsb3cKPiBzbyB0aGF0IHRoZSBzYW1lIEFDTCBvbiAyIGRpZmZlcmVu dCBzZXJ2ZXJzIHByb2R1Y2VzIHRoZSBzYW1lIE5FVENPTkYKPiBwcm90b2NvbCBiZWhhdmlvci4K ClJpZ2h0LCBhbmQgSSByZWNrb24gTERBUCBzZXJ2ZXJzIG11c3QgaGF2ZSBpbXBsZW1lbnRlZCBz b2x1dGlvbnMgdG8gc29tZQpvZiB0aGVzZSBwcm9ibGVtcy4KCkxhZGEKCj4gCj4gCj4gPgo+ID4g TGFkYQo+IAo+IEFuZHkKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBF NzRFOEMwQwoKCg== ------=_Part_1_1289291615796 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5JTU8gZ2VuZXJpYyByZXF1aXJlbWVudHMgYXJlIG5vdCB1c2VmdWwuICZuYnNw O1RoZSBMREFQIHNvbHV0aW9uIGlzIHNwZWNpZmljIHRvIHRoYXQgdHlwZSBvZiBzZXJ2ZXIuPGJy Pjxicj5XaGF0IHNwZWNpZmljIG5ldGNvbmYgcHJvYmxlbXMgZG9lcyB0aGUgbGRhcCBzb2x1dGlv biBhZGRyZXNzPyBEb2VzIGl0IHByb3ZpZGUgYSBDUlVEWCBvcGVyYXRpb24gbW9kZWwgbGlrZSB3 ZSBuZWVkPyAmbmJzcDtEb2VzIGl0IGludGVncmF0ZSB3aXRoIHJhZGl1cz8gV2hhdCBzcGVjaWZp YyByZXF1aXJlbWVudHMgYXJlIG1ldCB3aGljaCBuZXRjb25mIGlzIHJlaW52ZW50aW5nPzxicj48 YnI+QW5keTxicj48YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1 b3Q7TGFkaXNsYXYgTGhvdGthJnF1b3Q7ICZsdDtsaG90a2FAY2VzbmV0LmN6Jmd0Ozxicj5EYXRl OiBUdWUsIE5vdiA5LCAyMDEwIDE2OjAzPGJyPlN1YmplY3Q6IFtOZXRjb25mXSB4bWwgYWNjZXNz IGNvbnRyb2wgdnMuIG5ldGNvbmYgYWNjZXNzIGNvbnRyb2w8YnI+VG86ICZxdW90O0FuZHkgQmll cm1hbiZxdW90OyAmbHQ7aWV0ZkBhbmR5Ymllcm1hbi5jb20mZ3Q7PGJyPkNjOiAmbHQ7bmV0Y29u ZkBpZXRmLm9yZyZndDs8YnI+PGJyPjxicj5PbiBQbywgMjAxMC0xMS0wOCBhdCAyMDoyNCAtMDgw MCwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4mZ3Q7IE9uIDExLzA4LzIwMTAgMDc6MzIgUE0sIExh ZGlzbGF2IExob3RrYSB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IE9uIMOadCwgMjAxMC0xMS0wOSBhdCAw MToyMCArMDEwMCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOjxicj4mZ3Q7ICZndDsmZ3Q7 IEhpLDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgQmVydCBtZW50aW9uZWQgdG9k YXkgdGhhdCB3ZSBzaG91bGQgbG9vayBpbnRvIFhNTCBhY2Nlc3MgY29udHJvbCB3b3JrPGJyPiZn dDsgJmd0OyZndDsgYW5kIHNlZSBpZi9ob3cgdGhpcyBhcHBsaWVzIHRvIE5FVENPTkYuIE9uZSBv ZnRlbiBjaXRlZCBYTUwgYWNjZXNzPGJyPiZndDsgJmd0OyZndDsgY29udHJvbCBwaWVjZSBvZiB3 b3JrIGlzIFhBQ01MIGRlZmluZWQgYnkgT0FTSVMgWzFdLiBUaGVyZSBoYXMgYmVlbjxicj4mZ3Q7 ICZndDsmZ3Q7IGEgcGFwZXIgb24gaG93IHRvIHVzZSBYQUNNTCBmb3IgTkVUQ09ORiBbMl0uIFRo ZXJlIGhhcyBhbHNvIGJlZW48YnI+Jmd0OyAmZ3Q7Jmd0OyBzb21lIGFjYWRlbWljIHdvcmsgd2hl cmUgdGhleSBkZWNpZGVkIGFnYWluc3QgWEFDTUwgWzNdLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsgT2YgY291cnNlLCB0aGUgTkVUQ09ORiBBQ00gYXBwbGllcyB0byB0aGUgTkVU Q09ORiBjb25maWd1cmF0aW9uPGJyPiZndDsgJmd0OyZndDsgZGF0YWJhc2UgYW5kIHRvIG9wZXJh dGlvbnMgaW52b2tlZCBieSBORVRDT05GOyB0aGUgQUNNIGRvZXMgbm90IGFwcGx5PGJyPiZndDsg Jmd0OyZndDsgdG8gdGhlIFhNTCBzZXJpYWxpemF0aW9uIHVzZWQgb24gdGhlIHdpcmUuIE5FVENP TkYgaXMgbm90IGFuIFhNTDxicj4mZ3Q7ICZndDsmZ3Q7IGRhdGFiYXNlIC0gaXQgaXMgYSBwcm90 b2NvbCB0aGF0IGp1c3QgaGFwcGVucyB0byB1c2UgWE1MIHRvIGVuY29kZTxicj4mZ3Q7ICZndDsm Z3Q7IG1lc3NhZ2VzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFhNTCBpcyBub3QganVzdCB0 aGUgc2VyaWFsaXplZCBmb3JtLiBJIGFzc3VtZSB0aGUgTkVUQ09ORiBkYXRhYmFzZSBoYXM8YnI+ Jmd0OyAmZ3Q7IHRvIGJlIG1vZGVsbGVkIChhdCBsZWFzdCBjb25jZXB0dWFsbHkpIGFzIFhNTCBp bmZvc2V0IGJlY2F1c2Ugd2UgdXNlPGJyPiZndDsgJmd0OyBYUGF0aCB0byBxdWVyeSBpdCBldGMu PGJyPiZndDsgJmd0OyBsbDxicj4mZ3Q7IDxicj4mZ3Q7IFRoZXJlIGFyZSBjb3JuZXIgY2FzZXMg d2hlcmUgYSBORVRDT05GIHNlcnZlciBtYXkgbm90IHN1cHBvcnQgYWxsIFhQYXRoPGJyPiZndDsg ZXhwcmVzc2lvbnMgdGhlIHNhbWUgd2F5LCBhcyBkb2N1bWVudGVkIGluIHRoZSBZQU5HIFVzYWdl IEd1aWRlbGluZXMuPGJyPjxicj5NeSBwb2ludCBpcyB0aGF0IGEgTkVUQ09ORiBkYXRhYmFzZSBp biBmYWN0IGxvb2tzIGFuZCBiZWhhdmVzIHByZXR0eTxicj5tdWNoIGxpa2UgWE1MIGFuZCB0aGUg bWFwcGluZyB0byBzZXJpYWxpemVkIFhNTCBpcyBzdHJhaWdodGZvcndhcmQsIHNvIEk8YnI+dGhp bmsgJnF1b3Q7TkVUQ09ORiBpcyBub3QgWE1MJnF1b3Q7IGluIG5vdCBhIHZhbGlkIHJlYXNvbiBm b3IgcmVqZWN0aW5nIFhBQ01MPGJyPih0aG91Z2ggSSBkb24mIzM5O3QgYWR2b2NhdGUgaXQgYmVj YXVzZSBJIGhhdmVuJiMzOTt0IHJlYWQgdGhlIHNwZWMpLjxicj48YnI+Jmd0OyA8YnI+Jmd0OyAm Z3Q7IFRoaXMgaXMgbm90IHRvIHNheSB0aGF0IFhBQ01MIGlzIG9mIGFueSB1c2UuIE9uIHRoZSBv dGhlciBoYW5kLCBhY2Nlc3M8YnI+Jmd0OyAmZ3Q7IGNvbnRyb2wgbW9kZWxzIG9mIG90aGVyIGhp ZXJhcmNoaWNhbCBkYXRhYmFzZXMgc3VjaCBhcyBMREFQIGNvdWxkIGJlPGJyPiZndDsgJmd0OyBj b25zaWRlcmVkLjxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IFdlIGFyZSB1c2luZyBYUGF0aCB0 byBzcGVjaWZ5IHRoZSBkYXRhIHJ1bGVzLjxicj4mZ3Q7IFdlIGhhdmUgb3B0aW1pemF0aW9ucyB0 aGF0IGFkZHJlc3Mgc3BlY2lmaWMgTkVUQ09ORiBvcGVyYXRpb25hbCByZXF1aXJlbWVudHMuPGJy PiZndDsgPGJyPiZndDsgVGhlIGVhc3kgcGFydCBpcyBzcGVjaWZ5aW5nIGFuIEFDTC48YnI+Jmd0 OyBUaGUgaGFyZCBwYXJ0IGlzIHNwZWNpZnlpbmcgdGhlIHByb2NlZHVyZXMgYSBzZXJ2ZXIgbXVz dCBmb2xsb3c8YnI+Jmd0OyBzbyB0aGF0IHRoZSBzYW1lIEFDTCBvbiAyIGRpZmZlcmVudCBzZXJ2 ZXJzIHByb2R1Y2VzIHRoZSBzYW1lIE5FVENPTkY8YnI+Jmd0OyBwcm90b2NvbCBiZWhhdmlvci48 YnI+PGJyPlJpZ2h0LCBhbmQgSSByZWNrb24gTERBUCBzZXJ2ZXJzIG11c3QgaGF2ZSBpbXBsZW1l bnRlZCBzb2x1dGlvbnMgdG8gc29tZTxicj5vZiB0aGVzZSBwcm9ibGVtcy48YnI+PGJyPkxhZGE8 YnI+PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgTGFkYTxicj4m Z3Q7IDxicj4mZ3Q7IEFuZHk8YnI+PGJyPi0tIDxicj5MYWRpc2xhdiBMaG90a2EsIENFU05FVDxi cj5QR1AgS2V5IElEOiBFNzRFOEMwQzxicj48YnI+PGJyPjxicj48YnI+ ------=_Part_1_1289291615796-- From balazs.lengyel@ericsson.com Tue Nov 9 03:07: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 6D6393A6767 for ; Tue, 9 Nov 2010 03:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 EIeCWf5dl7eN for ; Tue, 9 Nov 2010 03:07:30 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 344873A6878 for ; Tue, 9 Nov 2010 03:07:29 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-6e-4cd92b89bce3 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 57.9B.04955.98B29DC4; Tue, 9 Nov 2010 12:07:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Nov 2010 12:07:53 +0100 Received: from [159.107.164.144] ([159.107.164.144]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Nov 2010 12:07:52 +0100 Message-ID: <4CD92B88.1090609@ericsson.com> Date: Tue, 09 Nov 2010 11:07:52 +0000 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ladislav Lhotka References: <20101109002022.GB55071@elstar.local> <1289273536.2429.42.camel@nomad> <4CD8CCE6.2060601@andybierman.com> <1289289795.1500.21.camel@nomad> In-Reply-To: <1289289795.1500.21.camel@nomad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2010 11:07:52.0833 (UTC) FILETIME=[5A950F10:01CB7FFE] X-Brightmail-Tracker: AAAAAA== Cc: "netconf@ietf.org" Subject: Re: [Netconf] xml access control vs. netconf access control 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, 09 Nov 2010 11:07:31 -0000 On 11/09/10 08:03, Ladislav Lhotka wrote: > >>> XML is not just the serialized form. I assume the NETCONF database has >>> to be modelled (at least conceptually) as XML infoset because we use >>> XPath to query it etc. >>> ll >> There are corner cases where a NETCONF server may not support all XPath >> expressions the same way, as documented in the YANG Usage Guidelines. > My point is that a NETCONF database in fact looks and behaves pretty > much like XML and the mapping to serialized XML is straightforward, so I > think "NETCONF is not XML" in not a valid reason for rejecting XACML > (though I don't advocate it because I haven't read the spec) In addition NETCONF/YANG also has user defined RPCs. Could be a tricky part of ACL especially if you don't want to define an ACL rule for each RPC. IMHO getting the operator to use ACL is an even bigger task then defining the ACL methodology (see VACM in SNMP). So simplicity is the king. Balazs From j.schoenwaelder@jacobs-university.de Tue Nov 9 19:07:44 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 877D528C0D9 for ; Tue, 9 Nov 2010 19:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fOK-jDnuivz for ; Tue, 9 Nov 2010 19:07:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8B86E28C0E7 for ; Tue, 9 Nov 2010 19:07:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F22B1C0019 for ; Wed, 10 Nov 2010 04:07:56 +0100 (CET) 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 gKIvmyjyyMMo; Wed, 10 Nov 2010 04:07:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53383C000B; Wed, 10 Nov 2010 04:07:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4D28D159C9CA; Wed, 10 Nov 2010 04:07:56 +0100 (CET) Date: Wed, 10 Nov 2010 04:07:56 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20101110030756.GC58773@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 03:07:44 -0000 Hi, I am trying to find a solution that allows to fix the unfortunate EOM marker without requiring a new SSH subsystem. Would the following work: a) We allocate a new EOM marker (e.g. 0x04) we believe is better than what we have now. b) NETCONF client and server exchange hello messages in the traditional way, using the ]]>]]> EOM marker. c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, this is taken as the signal to switch from the ]]>]]> EOM marker to the new EOM marker (e.g. 0x04). Since the hello exchange does not carry any user supplied data, the usage of the traditional EOM marker during the hello exchange should not be a big deal. Would something like this work? /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 Tue Nov 9 20:03: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 D7E5A3A684F for ; Tue, 9 Nov 2010 20:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 7yYz47SjQoTh for ; Tue, 9 Nov 2010 20:03:26 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A089B3A67AB for ; Tue, 9 Nov 2010 20:03:25 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 519F72CDE058 for ; Wed, 10 Nov 2010 05:03:47 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <20101110030756.GC58773@elstar.local> References: <20101110030756.GC58773@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 10 Nov 2010 12:03:42 +0800 Message-ID: <1289361822.1437.6.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 04:03:26 -0000 On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > Hi, > > I am trying to find a solution that allows to fix the unfortunate EOM > marker without requiring a new SSH subsystem. Would the following > work: > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > what we have now. > > b) NETCONF client and server exchange hello messages in the > traditional way, using the ]]>]]> EOM marker. > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > this is taken as the signal to switch from the ]]>]]> EOM marker to > the new EOM marker (e.g. 0x04). How about using the old EoM for hello but include a processing instruction *before* the tag, e.g. This could be handled entirely within the transport layer. > > Since the hello exchange does not carry any user supplied data, the > usage of the traditional EOM marker during the hello exchange should > not be a big deal. Agreed. Lada > > Would something like this work? > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Nov 9 20:12: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 1F30E3A688B for ; Tue, 9 Nov 2010 20:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.067 X-Spam-Level: X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1okx6ajBo4eA for ; Tue, 9 Nov 2010 20:12:16 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7CDB23A6880 for ; Tue, 9 Nov 2010 20:12:16 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 120FFC0019; Wed, 10 Nov 2010 05:12:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JzXN3JtwS-Tm; Wed, 10 Nov 2010 05:12:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50ADAC000B; Wed, 10 Nov 2010 05:12:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45058159CCFA; Wed, 10 Nov 2010 05:12:41 +0100 (CET) Date: Wed, 10 Nov 2010 05:12:41 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101110041241.GA59172@elstar.local> Mail-Followup-To: Ladislav Lhotka , netconf@ietf.org References: <20101110030756.GC58773@elstar.local> <1289361822.1437.6.camel@nomad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1289361822.1437.6.camel@nomad> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 04:12:19 -0000 On Wed, Nov 10, 2010 at 12:03:42PM +0800, Ladislav Lhotka wrote: > On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > I am trying to find a solution that allows to fix the unfortunate EOM > > marker without requiring a new SSH subsystem. Would the following > > work: > > > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > > what we have now. > > > > b) NETCONF client and server exchange hello messages in the > > traditional way, using the ]]>]]> EOM marker. > > > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > > this is taken as the signal to switch from the ]]>]]> EOM marker to > > the new EOM marker (e.g. 0x04). > > How about using the old EoM for hello but include a processing > instruction *before* the tag, e.g. > > > This could be handled entirely within the transport layer. >From a purist's architectural point of view, both options require either the transport to peak into the message or the message layer to tell the transport to upgrade to 1.1 framing. In implementations, this might be rather simple to do. Since NETCONF 1.1. code already pays attention to the base:1.1 capability, not introducing another magic processing instruction might actually be simpler. At the end, I do not care much - I am just trying to see whether it is possible to find a solution that allows to transition to a better EOM marker without requiring a new subsystem. /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 Tue Nov 9 20:33: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 5F3923A6835 for ; Tue, 9 Nov 2010 20:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.749, 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 7Z0U8WdeMKPK for ; Tue, 9 Nov 2010 20:33:08 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id 8B0023A67FD for ; Tue, 9 Nov 2010 20:33:07 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAA4XXxM007564 for ; Tue, 9 Nov 2010 23:33:33 -0500 Authentication-Results: cm-omr3 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [130.129.116.237] ([130.129.116.237:54777] helo=[130.129.116.237]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 2E/DC-19358-B902ADC4; Tue, 09 Nov 2010 23:33:33 -0500 To: "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , netconf@ietf.org Message-ID: <2E.DC.19358.B902ADC4@cm-omr3> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 10 Nov 2010 12:33:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1289363625952" Subject: Re: [Netconf] =?utf-8?q?ssh_EOM_and_netconf_1=2E1?= 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, 10 Nov 2010 04:33:10 -0000 ------=_Part_1_1289363625952 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBXZWQgYXNrZWQgd2hhdCBwcm9ibGVtIHdlIGFyZSBzb2x2aW5nIGhlcmUuICBJIHdv dWxkIGxpa2UgdG8ga25vdyBhcyB3ZWxsLgoKVXNpbmcgdGhlIG9sZCBmcmFtaW5nIGF0IGFsbCBt ZWFucyBhIGhhY2tlciBjYW4gc3RpbGwgZmlndXJlIG91dCBob3cgdG8gaW5qZWN0IHJwY3MgaW50 byB0aGUgbWVzc2FnZSBzdHJlYW0gdXNpbmcgbGVnYWwgWE1MLgoKVXNpbmcgYSBtYWdpYyBQSSBp cyBhIGNvbXBsaWNhdGVkIGhhY2suICBOb3Qgc3VyZSB3aHkgaXQgaGVscHMuCgpBIGNsaWVudCB3 b3VsZCBoYXZlIHRvIHdhaXQgdW50aWwgdGhlIHNlcnZlciBoZWxsbyB3YXMgcHJvY2Vzc2VkIGJl Zm9yZSBzZW5kaW5nIHRoZSBmaXJzdCBycGMgdG8gdXNlIHRoZSBjb3JyZWN0IGZyYW1pbmcuICAK CldlZCBpcyByaWdodC4gIE1peGluZyBmcmFtaW5nIGFuZCBkYXRhIGRvZXNuJ3Qgd29yay4gCgpB bmR5CgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiSnVlcmdlbiBTY2hvZW53YWVs ZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPgpEYXRlOiBXZWQsIE5v diAxMCwgMjAxMCAxMTowNwpTdWJqZWN0OiBbTmV0Y29uZl0gc3NoIEVPTSBhbmQgbmV0Y29uZiAx LjEKVG86IDxuZXRjb25mQGlldGYub3JnPgoKSGksCgpJIGFtIHRyeWluZyB0byBmaW5kIGEgc29s dXRpb24gdGhhdCBhbGxvd3MgdG8gZml4IHRoZSB1bmZvcnR1bmF0ZSBFT00KbWFya2VyIHdpdGhv dXQgcmVxdWlyaW5nIGEgbmV3IFNTSCBzdWJzeXN0ZW0uIFdvdWxkIHRoZSBmb2xsb3dpbmcKd29y azoKCmEpIFdlIGFsbG9jYXRlIGEgbmV3IEVPTSBtYXJrZXIgKGUuZy4gMHgwNCkgd2UgYmVsaWV2 ZSBpcyBiZXR0ZXIgdGhhbgogICB3aGF0IHdlIGhhdmUgbm93LgoKYikgTkVUQ09ORiBjbGllbnQg YW5kIHNlcnZlciBleGNoYW5nZSBoZWxsbyBtZXNzYWdlcyBpbiB0aGUKICAgdHJhZGl0aW9uYWwg d2F5LCB1c2luZyB0aGUgXV0+XV0+IEVPTSBtYXJrZXIuCgpjKSBJZiBhIHBlZXIgYW5ub3VuY2Vz IHRoZSBjYXBhYmlsaXR5IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmJhc2U6MS4xLAogICB0aGlz IGlzIHRha2VuIGFzIHRoZSBzaWduYWwgdG8gc3dpdGNoIGZyb20gdGhlIF1dPl1dPiBFT00gbWFy a2VyIHRvCiAgIHRoZSBuZXcgRU9NIG1hcmtlciAoZS5nLiAweDA0KS4KClNpbmNlIHRoZSBoZWxs byBleGNoYW5nZSBkb2VzIG5vdCBjYXJyeSBhbnkgdXNlciBzdXBwbGllZCBkYXRhLCB0aGUKdXNh Z2Ugb2YgdGhlIHRyYWRpdGlvbmFsIEVPTSBtYXJrZXIgZHVyaW5nIHRoZSBoZWxsbyBleGNoYW5n ZSBzaG91bGQKbm90IGJlIGEgYmlnIGRlYWwuCgpXb3VsZCBzb21ldGhpbmcgbGlrZSB0aGlzIHdv cms/CgovanMKCi0tIApKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSApQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1 cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg ICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0 Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYKCg== ------=_Part_1_1289363625952 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBXZWQgYXNrZWQgd2hhdCBwcm9ibGVtIHdlIGFyZSBzb2x2aW5nIGhlcmUuICZuYnNw O0kgd291bGQgbGlrZSB0byBrbm93IGFzIHdlbGwuPGJyPjxicj5Vc2luZyB0aGUgb2xkIGZyYW1p bmcgYXQgYWxsIG1lYW5zIGEgaGFja2VyIGNhbiBzdGlsbCBmaWd1cmUgb3V0IGhvdyB0byBpbmpl Y3QgcnBjcyBpbnRvIHRoZSBtZXNzYWdlIHN0cmVhbSB1c2luZyBsZWdhbCBYTUwuPGJyPjxicj5V c2luZyBhIG1hZ2ljIFBJIGlzIGEgY29tcGxpY2F0ZWQgaGFjay4gJm5ic3A7Tm90IHN1cmUgd2h5 IGl0IGhlbHBzLjxicj48YnI+QSBjbGllbnQgd291bGQgaGF2ZSB0byB3YWl0IHVudGlsIHRoZSBz ZXJ2ZXIgaGVsbG8gd2FzIHByb2Nlc3NlZCBiZWZvcmUgc2VuZGluZyB0aGUgZmlyc3QgcnBjIHRv IHVzZSB0aGUgY29ycmVjdCBmcmFtaW5nLiAmbmJzcDs8YnI+PGJyPldlZCBpcyByaWdodC4gJm5i c3A7TWl4aW5nIGZyYW1pbmcgYW5kIGRhdGEgZG9lc24mIzM5O3Qgd29yay4gPGJyPjxicj5BbmR5 PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtKdWVy Z2VuIFNjaG9lbndhZWxkZXImcXVvdDsgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZSZndDs8YnI+RGF0ZTogV2VkLCBOb3YgMTAsIDIwMTAgMTE6MDc8YnI+U3ViamVjdDog W05ldGNvbmZdIHNzaCBFT00gYW5kIG5ldGNvbmYgMS4xPGJyPlRvOiAmbHQ7bmV0Y29uZkBpZXRm Lm9yZyZndDs8YnI+PGJyPkhpLDxicj48YnI+SSBhbSB0cnlpbmcgdG8gZmluZCBhIHNvbHV0aW9u IHRoYXQgYWxsb3dzIHRvIGZpeCB0aGUgdW5mb3J0dW5hdGUgRU9NPGJyPm1hcmtlciB3aXRob3V0 IHJlcXVpcmluZyBhIG5ldyBTU0ggc3Vic3lzdGVtLiBXb3VsZCB0aGUgZm9sbG93aW5nPGJyPndv cms6PGJyPjxicj5hKSBXZSBhbGxvY2F0ZSBhIG5ldyBFT00gbWFya2VyIChlLmcuIDB4MDQpIHdl IGJlbGlldmUgaXMgYmV0dGVyIHRoYW48YnI+ICZuYnNwOyB3aGF0IHdlIGhhdmUgbm93Ljxicj48 YnI+YikgTkVUQ09ORiBjbGllbnQgYW5kIHNlcnZlciBleGNoYW5nZSBoZWxsbyBtZXNzYWdlcyBp biB0aGU8YnI+ICZuYnNwOyB0cmFkaXRpb25hbCB3YXksIHVzaW5nIHRoZSBdXSZndDtdXSZndDsg RU9NIG1hcmtlci48YnI+PGJyPmMpIElmIGEgcGVlciBhbm5vdW5jZXMgdGhlIGNhcGFiaWxpdHkg dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6YmFzZToxLjEsPGJyPiAmbmJzcDsgdGhpcyBpcyB0YWtl biBhcyB0aGUgc2lnbmFsIHRvIHN3aXRjaCBmcm9tIHRoZSBdXSZndDtdXSZndDsgRU9NIG1hcmtl ciB0bzxicj4gJm5ic3A7IHRoZSBuZXcgRU9NIG1hcmtlciAoZS5nLiAweDA0KS48YnI+PGJyPlNp bmNlIHRoZSBoZWxsbyBleGNoYW5nZSBkb2VzIG5vdCBjYXJyeSBhbnkgdXNlciBzdXBwbGllZCBk YXRhLCB0aGU8YnI+dXNhZ2Ugb2YgdGhlIHRyYWRpdGlvbmFsIEVPTSBtYXJrZXIgZHVyaW5nIHRo ZSBoZWxsbyBleGNoYW5nZSBzaG91bGQ8YnI+bm90IGJlIGEgYmlnIGRlYWwuPGJyPjxicj5Xb3Vs ZCBzb21ldGhpbmcgbGlrZSB0aGlzIHdvcms/PGJyPjxicj4vanM8YnI+PGJyPi0tIDxicj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2Vy bWFueTxicj5GYXg6ICZuYnNwOyArNDkgNDIxIDIwMCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iPmh0 dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+TmV0Y29uZiBtYWlsaW5nIGxpc3Q8 YnI+TmV0Y29uZkBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZjwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_1_1289363625952-- From j.schoenwaelder@jacobs-university.de Tue Nov 9 20:52: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 662C83A67D3 for ; Tue, 9 Nov 2010 20:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0TB096xIvl1 for ; Tue, 9 Nov 2010 20:52:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B710F3A67B5 for ; Tue, 9 Nov 2010 20:51:58 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F05AC0019; Wed, 10 Nov 2010 05:52:24 +0100 (CET) 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 6H7CReQhz5EV; Wed, 10 Nov 2010 05:52:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B28DDC000B; Wed, 10 Nov 2010 05:52:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 47983159CE69; Wed, 10 Nov 2010 05:52:22 +0100 (CET) Date: Wed, 10 Nov 2010 05:52:22 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101110045222.GA59331@elstar.local> Mail-Followup-To: Andy Bierman , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E.DC.19358.B902ADC4@cm-omr3> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 04:52:03 -0000 On Wed, Nov 10, 2010 at 12:33:45PM +0800, Andy Bierman wrote: > Using the old framing at all means a hacker can still figure out how > to inject rpcs into the message stream using legal XML. It is hard to inject something into the . We won't fix the existing 1.0 transport, we can however fix the 1.1 transport. > A client would have to wait until the server hello was processed > before sending the first rpc to use the correct framing. Yep. Big deal? Isn't it a good thing to wait until you know the receiver will understand what you are saying. Isn't that why we have the in the first place? > Wed is right. Mixing framing and data doesn't work. I don't understand. You can look at this like the message layering figuring out the peer is 1.1 and telling the transport to switch to 1.1 framing. If you take this viewpoint, there is no mixing of framing and data. /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 Nov 9 20:54: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 C9BAD3A67FE for ; Tue, 9 Nov 2010 20:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 wKxvwoGrqZFK for ; Tue, 9 Nov 2010 20:54:02 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 5A9DE3A67D3 for ; Tue, 9 Nov 2010 20:54:02 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAA4kd2m029298; Tue, 9 Nov 2010 20:54:11 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id sfhjn040m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Nov 2010 20:54:11 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 20:54:39 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 9 Nov 2010 20:54:09 -0800 From: Andy Bierman To: Andy Bierman , Juergen Schoenwaelder , "netconf@ietf.org" Date: Tue, 9 Nov 2010 20:54:06 -0800 Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAkHNF56hU0ZRHQrGIyJL44a9p/wAApg0w Message-ID: References: <2E.DC.19358.B902ADC4@cm-omr3> In-Reply-To: <2E.DC.19358.B902ADC4@cm-omr3> 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_B11AB91666F22D498EEC66410EB3D3C4F412BED0D9HQ1EXCH01corp_" 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-11-10_02:2010-11-10, 2010-11-09, 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-1011090225 Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 04:54:04 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F412BED0D9HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29wcyDigJMgSSBtZWFudCBXZXMsIG5vdCBXZWQg4oCTIG15IEFuZHJvaWQgcGhvbmUgY2hhbmdl ZCB0aGUgc3BlbGxpbmcuDQpUaG91Z2h0IEkgY2F1Z2h0IGFsbCB0aG9zZSwgYnV0IEkgZ3Vlc3Mg bm90LiAgTmVlZCB0byBkaXNhYmxlIHRoYXQgYnJva2VuIGZlYXR1cmUuDQoNCg0KQW5keQ0KDQoN CkZyb206IG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMDksIDIwMTAgODozNCBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgbmV0Y29uZkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBzc2ggRU9NIGFuZCBuZXRjb25mIDEuMQ0K DQpJIHRoaW5rIFdlZCBhc2tlZCB3aGF0IHByb2JsZW0gd2UgYXJlIHNvbHZpbmcgaGVyZS4gIEkg d291bGQgbGlrZSB0byBrbm93IGFzIHdlbGwuDQoNClVzaW5nIHRoZSBvbGQgZnJhbWluZyBhdCBh bGwgbWVhbnMgYSBoYWNrZXIgY2FuIHN0aWxsIGZpZ3VyZSBvdXQgaG93IHRvIGluamVjdCBycGNz IGludG8gdGhlIG1lc3NhZ2Ugc3RyZWFtIHVzaW5nIGxlZ2FsIFhNTC4NCg0KVXNpbmcgYSBtYWdp YyBQSSBpcyBhIGNvbXBsaWNhdGVkIGhhY2suICBOb3Qgc3VyZSB3aHkgaXQgaGVscHMuDQoNCkEg Y2xpZW50IHdvdWxkIGhhdmUgdG8gd2FpdCB1bnRpbCB0aGUgc2VydmVyIGhlbGxvIHdhcyBwcm9j ZXNzZWQgYmVmb3JlIHNlbmRpbmcgdGhlIGZpcnN0IHJwYyB0byB1c2UgdGhlIGNvcnJlY3QgZnJh bWluZy4NCg0KV2VkIGlzIHJpZ2h0LiAgTWl4aW5nIGZyYW1pbmcgYW5kIGRhdGEgZG9lc24ndCB3 b3JrLg0KDQpBbmR5DQoNCg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQ0KRnJvbTogIkp1ZXJn ZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4N CkRhdGU6IFdlZCwgTm92IDEwLCAyMDEwIDExOjA3DQpTdWJqZWN0OiBbTmV0Y29uZl0gc3NoIEVP TSBhbmQgbmV0Y29uZiAxLjENClRvOiA8bmV0Y29uZkBpZXRmLm9yZz4NCg0KSGksDQoNCkkgYW0g dHJ5aW5nIHRvIGZpbmQgYSBzb2x1dGlvbiB0aGF0IGFsbG93cyB0byBmaXggdGhlIHVuZm9ydHVu YXRlIEVPTQ0KbWFya2VyIHdpdGhvdXQgcmVxdWlyaW5nIGEgbmV3IFNTSCBzdWJzeXN0ZW0uIFdv dWxkIHRoZSBmb2xsb3dpbmcNCndvcms6DQoNCmEpIFdlIGFsbG9jYXRlIGEgbmV3IEVPTSBtYXJr ZXIgKGUuZy4gMHgwNCkgd2UgYmVsaWV2ZSBpcyBiZXR0ZXIgdGhhbg0KICB3aGF0IHdlIGhhdmUg bm93Lg0KDQpiKSBORVRDT05GIGNsaWVudCBhbmQgc2VydmVyIGV4Y2hhbmdlIGhlbGxvIG1lc3Nh Z2VzIGluIHRoZQ0KICB0cmFkaXRpb25hbCB3YXksIHVzaW5nIHRoZSBdXT5dXT4gRU9NIG1hcmtl ci4NCg0KYykgSWYgYSBwZWVyIGFubm91bmNlcyB0aGUgY2FwYWJpbGl0eSB1cm46aWV0ZjpwYXJh bXM6bmV0Y29uZjpiYXNlOjEuMSwNCiAgdGhpcyBpcyB0YWtlbiBhcyB0aGUgc2lnbmFsIHRvIHN3 aXRjaCBmcm9tIHRoZSBdXT5dXT4gRU9NIG1hcmtlciB0bw0KICB0aGUgbmV3IEVPTSBtYXJrZXIg KGUuZy4gMHgwNCkuDQoNClNpbmNlIHRoZSBoZWxsbyBleGNoYW5nZSBkb2VzIG5vdCBjYXJyeSBh bnkgdXNlciBzdXBwbGllZCBkYXRhLCB0aGUNCnVzYWdlIG9mIHRoZSB0cmFkaXRpb25hbCBFT00g bWFya2VyIGR1cmluZyB0aGUgaGVsbG8gZXhjaGFuZ2Ugc2hvdWxkDQpub3QgYmUgYSBiaWcgZGVh bC4NCg0KV291bGQgc29tZXRoaW5nIGxpa2UgdGhpcyB3b3JrPw0KDQovanMNCg0KLS0NCkp1ZXJn ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI DQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJy ZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQoNCg== --_000_B11AB91666F22D498EEC66410EB3D3C4F412BED0D9HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPk9vcHMg 4oCTIEkgbWVhbnQgV2VzLCBub3QgV2VkIOKAkyBteSBBbmRyb2lkIHBob25lIGNoYW5nZWQgdGhl DQpzcGVsbGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+VGhvdWdodCBJIGNhdWdodCBhbGwgdGhvc2UsIGJ1dCBJ IGd1ZXNzIG5vdC7CoCBOZWVkIHRvIGRpc2FibGUNCnRoYXQgYnJva2VuIGZlYXR1cmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QW5keTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4NCm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5DQpC aWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDA5LCAyMDEwIDg6MzQg UE08YnI+DQo8Yj5Ubzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgbmV0Y29uZkBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHNzaCBFT00gYW5kIG5ldGNvbmYg MS4xPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz5JIHRoaW5rIFdlZCBhc2tlZCB3aGF0IHByb2JsZW0NCndlIGFyZSBz b2x2aW5nIGhlcmUuICZuYnNwO0kgd291bGQgbGlrZSB0byBrbm93IGFzIHdlbGwuPGJyPg0KPGJy Pg0KVXNpbmcgdGhlIG9sZCBmcmFtaW5nIGF0IGFsbCBtZWFucyBhIGhhY2tlciBjYW4gc3RpbGwg ZmlndXJlIG91dCBob3cgdG8gaW5qZWN0DQpycGNzIGludG8gdGhlIG1lc3NhZ2Ugc3RyZWFtIHVz aW5nIGxlZ2FsIFhNTC48YnI+DQo8YnI+DQpVc2luZyBhIG1hZ2ljIFBJIGlzIGEgY29tcGxpY2F0 ZWQgaGFjay4gJm5ic3A7Tm90IHN1cmUgd2h5IGl0IGhlbHBzLjxicj4NCjxicj4NCkEgY2xpZW50 IHdvdWxkIGhhdmUgdG8gd2FpdCB1bnRpbCB0aGUgc2VydmVyIGhlbGxvIHdhcyBwcm9jZXNzZWQg YmVmb3JlIHNlbmRpbmcNCnRoZSBmaXJzdCBycGMgdG8gdXNlIHRoZSBjb3JyZWN0IGZyYW1pbmcu ICZuYnNwOzxicj4NCjxicj4NCldlZCBpcyByaWdodC4gJm5ic3A7TWl4aW5nIGZyYW1pbmcgYW5k IGRhdGEgZG9lc24ndCB3b3JrLiA8YnI+DQo8YnI+DQpBbmR5PGJyPg0KPGJyPg0KPGJyPg0KLS0t LS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4NCkZyb206ICZxdW90O0p1ZXJnZW4gU2Nob2Vud2Fl bGRlciZxdW90Ow0KJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8 YnI+DQpEYXRlOiBXZWQsIE5vdiAxMCwgMjAxMCAxMTowNzxicj4NClN1YmplY3Q6IFtOZXRjb25m XSBzc2ggRU9NIGFuZCBuZXRjb25mIDEuMTxicj4NClRvOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZn dDs8YnI+DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQpJIGFtIHRyeWluZyB0byBmaW5kIGEgc29sdXRp b24gdGhhdCBhbGxvd3MgdG8gZml4IHRoZSB1bmZvcnR1bmF0ZSBFT008YnI+DQptYXJrZXIgd2l0 aG91dCByZXF1aXJpbmcgYSBuZXcgU1NIIHN1YnN5c3RlbS4gV291bGQgdGhlIGZvbGxvd2luZzxi cj4NCndvcms6PGJyPg0KPGJyPg0KYSkgV2UgYWxsb2NhdGUgYSBuZXcgRU9NIG1hcmtlciAoZS5n LiAweDA0KSB3ZSBiZWxpZXZlIGlzIGJldHRlciB0aGFuPGJyPg0KJm5ic3A7IHdoYXQgd2UgaGF2 ZSBub3cuPGJyPg0KPGJyPg0KYikgTkVUQ09ORiBjbGllbnQgYW5kIHNlcnZlciBleGNoYW5nZSBo ZWxsbyBtZXNzYWdlcyBpbiB0aGU8YnI+DQombmJzcDsgdHJhZGl0aW9uYWwgd2F5LCB1c2luZyB0 aGUgXV0mZ3Q7XV0mZ3Q7IEVPTSBtYXJrZXIuPGJyPg0KPGJyPg0KYykgSWYgYSBwZWVyIGFubm91 bmNlcyB0aGUgY2FwYWJpbGl0eSB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpiYXNlOjEuMSw8YnI+ DQombmJzcDsgdGhpcyBpcyB0YWtlbiBhcyB0aGUgc2lnbmFsIHRvIHN3aXRjaCBmcm9tIHRoZSBd XSZndDtdXSZndDsgRU9NIG1hcmtlcg0KdG88YnI+DQombmJzcDsgdGhlIG5ldyBFT00gbWFya2Vy IChlLmcuIDB4MDQpLjxicj4NCjxicj4NClNpbmNlIHRoZSBoZWxsbyBleGNoYW5nZSBkb2VzIG5v dCBjYXJyeSBhbnkgdXNlciBzdXBwbGllZCBkYXRhLCB0aGU8YnI+DQp1c2FnZSBvZiB0aGUgdHJh ZGl0aW9uYWwgRU9NIG1hcmtlciBkdXJpbmcgdGhlIGhlbGxvIGV4Y2hhbmdlIHNob3VsZDxicj4N Cm5vdCBiZSBhIGJpZyBkZWFsLjxicj4NCjxicj4NCldvdWxkIHNvbWV0aGluZyBsaWtlIHRoaXMg d29yaz88YnI+DQo8YnI+DQovanM8YnI+DQo8YnI+DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0 eQ0KQnJlbWVuIGdHbWJIPGJyPg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsIDI4NzU5DQpCcmVtZW4sIEdlcm1hbnk8YnI+ DQpGYXg6ICZuYnNwOyArNDkgNDIxIDIwMCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7PGENCmhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxi cj4NCk5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_B11AB91666F22D498EEC66410EB3D3C4F412BED0D9HQ1EXCH01corp_-- From biermana@Brocade.com Tue Nov 9 21:01: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 863483A67A4 for ; Tue, 9 Nov 2010 21:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UZl7m6oKXDHg for ; Tue, 9 Nov 2010 21:01:52 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id C607C3A6778 for ; Tue, 9 Nov 2010 21:01:52 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAA4uWvU015196; Tue, 9 Nov 2010 21:02:18 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id sfhjn0458-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Nov 2010 21:02:18 -0800 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; Tue, 9 Nov 2010 21:07:18 -0800 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, 9 Nov 2010 21:02:15 -0800 From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman Date: Tue, 9 Nov 2010 21:02:13 -0800 Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAkydlagTaPysfSpizcVQDU5yAQwAAIm1g Message-ID: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> In-Reply-To: <20101110045222.GA59331@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-11-10_02:2010-11-10, 2010-11-09, 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-1011090226 Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 05:01:54 -0000 I do not agree we have a problem that needs to be solved in 1.1. In theory, data injection can still happen after the , so the allege= d data injection problem is not solved. Switching framing during the session seems complicated and prone to bugs and interoperability problems. A client can certainly send a on before knowing the capabilities. NETCONF allows the client to send as many messages in a row as it wants. I do not want to break this feature. We already agreed to punt this to 2.0. That is the WG consensus. I see no reason to change that decision. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Tuesday, November 09, 2010 8:52 PM To: Andy Bierman Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 On Wed, Nov 10, 2010 at 12:33:45PM +0800, Andy Bierman wrote: =20 > Using the old framing at all means a hacker can still figure out how > to inject rpcs into the message stream using legal XML. It is hard to inject something into the . We won't fix the existing 1.0 transport, we can however fix the 1.1 transport. =20 > A client would have to wait until the server hello was processed > before sending the first rpc to use the correct framing. Yep. Big deal? Isn't it a good thing to wait until you know the receiver will understand what you are saying. Isn't that why we have the in the first place? > Wed is right. Mixing framing and data doesn't work.=20 I don't understand. You can look at this like the message layering figuring out the peer is 1.1 and telling the transport to switch to 1.1 framing. If you take this viewpoint, there is no mixing of framing and data. /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 lhotka@cesnet.cz Tue Nov 9 21:25:52 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 450163A67DF for ; Tue, 9 Nov 2010 21:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=-0.518, 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 3NnbBo9HP0fX for ; Tue, 9 Nov 2010 21:25:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 556983A67D6 for ; Tue, 9 Nov 2010 21:25:51 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 83D122CDE058; Wed, 10 Nov 2010 06:25:44 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101110041241.GA59172@elstar.local> References: <20101110030756.GC58773@elstar.local> <1289361822.1437.6.camel@nomad> <20101110041241.GA59172@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 10 Nov 2010 13:25:35 +0800 Message-ID: <1289366735.1437.23.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 05:25:52 -0000 On St, 2010-11-10 at 05:12 +0100, Juergen Schoenwaelder wrote: > On Wed, Nov 10, 2010 at 12:03:42PM +0800, Ladislav Lhotka wrote: > > On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > > > Hi, > > > > > > I am trying to find a solution that allows to fix the unfortunate EOM > > > marker without requiring a new SSH subsystem. Would the following > > > work: > > > > > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > > > what we have now. > > > > > > b) NETCONF client and server exchange hello messages in the > > > traditional way, using the ]]>]]> EOM marker. > > > > > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > > > this is taken as the signal to switch from the ]]>]]> EOM marker to > > > the new EOM marker (e.g. 0x04). > > > > How about using the old EoM for hello but include a processing > > instruction *before* the tag, e.g. > > > > > > This could be handled entirely within the transport layer. > > From a purist's architectural point of view, both options require > either the transport to peak into the message or the message layer to > tell the transport to upgrade to 1.1 framing. In implementations, this > might be rather simple to do. Since NETCONF 1.1. code already pays > attention to the base:1.1 capability, not introducing another magic > processing instruction might actually be simpler. For the message layer this action would be specific only for one type of transport. I'd prefer not to contaminate the message layer with this hack and confine the solution to the subsystem which caused the problem. But yes, both are feasible. Lada > > At the end, I do not care much - I am just trying to see whether it is > possible to find a solution that allows to transition to a better EOM > marker without requiring a new subsystem. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Nov 9 21:30: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 005EE3A67FE for ; Tue, 9 Nov 2010 21:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnC38AtSA72L for ; Tue, 9 Nov 2010 21:30:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E79373A680A for ; Tue, 9 Nov 2010 21:29:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2147C0019; Wed, 10 Nov 2010 06:30:25 +0100 (CET) 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 iWzC3J+LdLyN; Wed, 10 Nov 2010 06:30:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02544C000B; Wed, 10 Nov 2010 06:30:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 75C61159CF59; Wed, 10 Nov 2010 06:30:24 +0100 (CET) Date: Wed, 10 Nov 2010 06:30:24 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101110053024.GA59500@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , "netconf@ietf.org" References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@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] ssh EOM and netconf 1.1 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, 10 Nov 2010 05:30:06 -0000 On Tue, Nov 09, 2010 at 09:02:13PM -0800, Andy Bierman wrote: > I do not agree we have a problem that needs to be solved in 1.1. > In theory, data injection can still happen after the , so the alleged > data injection problem is not solved. > > Switching framing during the session seems complicated and prone to > bugs and interoperability problems. I do not see why. > A client can certainly send a on before > knowing the capabilities. NETCONF allows the client to send as > many messages in a row as it wants. I do not want to break > this feature. The 1.1 transport can still accept ]]>]]> framing for corner cases like this one. The point is to move to a more robust framing without much hassle such as new subsystems. > We already agreed to punt this to 2.0. That is the WG consensus. I > see no reason to change that decision. I like to understand whether there is a _technical_ problem with this proposal. Any? /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 Tue Nov 9 21:34: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 350CC3A67A3 for ; Tue, 9 Nov 2010 21:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 qTPQtTNUxhC4 for ; Tue, 9 Nov 2010 21:34:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 758AA3A67D0 for ; Tue, 9 Nov 2010 21:34:27 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7A3332CDE058; Wed, 10 Nov 2010 06:34:46 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 10 Nov 2010 13:34:41 +0800 Message-ID: <1289367281.1437.31.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 05:34:42 -0000 On Út, 2010-11-09 at 21:02 -0800, Andy Bierman wrote: > I do not agree we have a problem that needs to be solved in 1.1. > In theory, data injection can still happen after the , so the alleged > data injection problem is not solved. I'd say this approach removes 99 % of the security risk so it is IMO a very good thing. Lada > > Switching framing during the session seems complicated and prone to > bugs and interoperability problems. > > A client can certainly send a on before > knowing the capabilities. NETCONF allows the client to send as > many messages in a row as it wants. I do not want to break > this feature. > > We already agreed to punt this to 2.0. > That is the WG consensus. I see no reason to change that decision. > > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, November 09, 2010 8:52 PM > To: Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 > > On Wed, Nov 10, 2010 at 12:33:45PM +0800, Andy Bierman wrote: > > > Using the old framing at all means a hacker can still figure out how > > to inject rpcs into the message stream using legal XML. > > It is hard to inject something into the . We won't fix the > existing 1.0 transport, we can however fix the 1.1 transport. > > > A client would have to wait until the server hello was processed > > before sending the first rpc to use the correct framing. > > Yep. Big deal? Isn't it a good thing to wait until you know the > receiver will understand what you are saying. Isn't that why we have > the in the first place? > > > Wed is right. Mixing framing and data doesn't work. > > I don't understand. You can look at this like the message layering > figuring out the peer is 1.1 and telling the transport to switch to > 1.1 framing. If you take this viewpoint, there is no mixing of framing > and data. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Tue Nov 9 22:52: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 6A4BD3A69AB for ; Tue, 9 Nov 2010 22:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 WNQv3fT93l9O for ; Tue, 9 Nov 2010 22:52:22 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 48FB33A699D for ; Tue, 9 Nov 2010 22:52:22 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAA6oUvg006206; Tue, 9 Nov 2010 22:52:48 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id sff2s09cv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Nov 2010 22:52:47 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 22:53:17 -0800 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, 9 Nov 2010 22:52:47 -0800 From: Andy Bierman To: Juergen Schoenwaelder Date: Tue, 9 Nov 2010 22:52:45 -0800 Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAmGHT1SiDef4MR4Wu2JijmjyikQAChVOQ Message-ID: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> In-Reply-To: <20101110053024.GA59500@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-11-10_03:2010-11-10, 2010-11-09, 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-1011090238 Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 06:52:23 -0000 What technical problem does this solution address? It still relies on ]]>]]>. That seems broken to me. The solution should not rely on ]]>]]> whatsoever. Is the problem to be solved: a) operators want to use the value ]]>]]> in NETCONF content so a different EOM is needed b) protect against data injection attacks c) allow a raw SSH terminal session to be used for NETCONF IMO, (a) is of no interest at all. The binary data type can be used to address this problem. =20 Only a real framing solution addresses (b). We would force a session to terminate at the first hint of a data injection attack if we cared about solving (b), but we are not doing that. None of the solutions addresses (c). Marshall Rose used to force WGs to 1) define the problem to be solved 2) get the WG to agree there is a problem to be solved 3) discuss solutions Without (1) and (2) done, we are wasting time on (3). Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, November 09, 2010 9:30 PM To: Andy Bierman Cc: Andy Bierman; netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 On Tue, Nov 09, 2010 at 09:02:13PM -0800, Andy Bierman wrote: > I do not agree we have a problem that needs to be solved in 1.1. > In theory, data injection can still happen after the , so the alle= ged > data injection problem is not solved. >=20 > Switching framing during the session seems complicated and prone to > bugs and interoperability problems. I do not see why. > A client can certainly send a on before > knowing the capabilities. NETCONF allows the client to send as > many messages in a row as it wants. I do not want to break > this feature. The 1.1 transport can still accept ]]>]]> framing for corner cases like this one. The point is to move to a more robust framing without much hassle such as new subsystems. > We already agreed to punt this to 2.0. That is the WG consensus. I > see no reason to change that decision. I like to understand whether there is a _technical_ problem with this proposal. Any? /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 mehmet.ersue@nsn.com Tue Nov 9 22:57: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 E3FCF3A68B5 for ; Tue, 9 Nov 2010 22:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 C7KEL8OmDSiP for ; Tue, 9 Nov 2010 22:57:32 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2A5B33A69AC for ; Tue, 9 Nov 2010 22:57:32 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAA6vscj020177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 07:57:54 +0100 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 oAA6vpuf024981; Wed, 10 Nov 2010 07:57:54 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 07:57:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 07:57:42 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101110053024.GA59500@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAmGZHXicN/6XiS5ONEpYHww0jcAACVkRQ References: <2E.DC.19358.B902ADC4@cm-omr3><20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Andy Bierman" X-OriginalArrivalTime: 10 Nov 2010 06:57:45.0004 (UTC) FILETIME=[93A1D6C0:01CB80A4] Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 06:57:37 -0000 Juergen, do I understand correctly that you suggest, the secure transport layer should interpret the NETCONF hello message and based on this should decide which EOM has to be used. The capability exchange is AFAIU to negotiate the NETCONF capabilities. Do you really want that SSH transport interprets XML content of a NETCONF message? Independently of the technical clearness I have a process-related concern. We had this discussion already many times and we all agreed to keep it as it is now in 4742bis document. As document shepherd I announced the discussion result and that I give the document now over to Dan requesting to start the publication process. In spite of everything I think there might be still room to do changes now or during IETF LC. However, I would agree with such a change only if there are no objections in the workgroup. Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Juergen Schoenwaelder > Sent: Wednesday, November 10, 2010 6:30 AM > To: Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 >=20 > On Tue, Nov 09, 2010 at 09:02:13PM -0800, Andy Bierman wrote: > > I do not agree we have a problem that needs to be solved in 1.1. > > In theory, data injection can still happen after the , so the > alleged > > data injection problem is not solved. > > > > Switching framing during the session seems complicated and prone to > > bugs and interoperability problems. >=20 > I do not see why. >=20 > > A client can certainly send a on before > > knowing the capabilities. NETCONF allows the client to send as > > many messages in a row as it wants. I do not want to break > > this feature. >=20 > The 1.1 transport can still accept ]]>]]> framing for corner cases > like this one. The point is to move to a more robust framing without > much hassle such as new subsystems. >=20 > > We already agreed to punt this to 2.0. That is the WG consensus. I > > see no reason to change that decision. >=20 > I like to understand whether there is a _technical_ problem with this > proposal. Any? >=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 lhotka@cesnet.cz Tue Nov 9 23:34: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 D5ADE3A699D for ; Tue, 9 Nov 2010 23:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 OkNS9QwCl6Ca for ; Tue, 9 Nov 2010 23:34:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A1CDD3A6A18 for ; Tue, 9 Nov 2010 23:34:00 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id D0E0E2CDE058; Wed, 10 Nov 2010 08:34:23 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 10 Nov 2010 15:34:19 +0800 Message-ID: <1289374459.1437.62.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 07:34:01 -0000 On Út, 2010-11-09 at 22:52 -0800, Andy Bierman wrote: > What technical problem does this solution address? > It still relies on ]]>]]>. That seems broken to me. > The solution should not rely on ]]>]]> whatsoever. > > Is the problem to be solved: > a) operators want to use the value ]]>]]> in NETCONF content > so a different EOM is needed No. > b) protect against data injection attacks Yes, but also against simple DoS attacks based on forcing the devices to close the session abruptly. If this happens simultaneously to several dozen routers, it could mean a serious disruption. > c) allow a raw SSH terminal session to be used for NETCONF I don't get how this ability is affected by the proposed change. > > > IMO, (a) is of no interest at all. The binary data type can be > used to address this problem. > > Only a real framing solution addresses (b). We would force a session Real framing would be the best but I understand it is now out of question. I prefer to fix the hole now with an imperfect but compatible patch. Lada > to terminate at the first hint of a data injection attack if we cared > about solving (b), but we are not doing that. > > None of the solutions addresses (c). > > Marshall Rose used to force WGs to > 1) define the problem to be solved > 2) get the WG to agree there is a problem to be solved > 3) discuss solutions > > Without (1) and (2) done, we are wasting time on (3). > > > Andy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, November 09, 2010 9:30 PM > To: Andy Bierman > Cc: Andy Bierman; netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 > > On Tue, Nov 09, 2010 at 09:02:13PM -0800, Andy Bierman wrote: > > I do not agree we have a problem that needs to be solved in 1.1. > > In theory, data injection can still happen after the , so the alleged > > data injection problem is not solved. > > > > Switching framing during the session seems complicated and prone to > > bugs and interoperability problems. > > I do not see why. > > > A client can certainly send a on before > > knowing the capabilities. NETCONF allows the client to send as > > many messages in a row as it wants. I do not want to break > > this feature. > > The 1.1 transport can still accept ]]>]]> framing for corner cases > like this one. The point is to move to a more robust framing without > much hassle such as new subsystems. > > > We already agreed to punt this to 2.0. That is the WG consensus. I > > see no reason to change that decision. > > I like to understand whether there is a _technical_ problem with this > proposal. Any? > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 9 23:39: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 69D853A67F9 for ; Tue, 9 Nov 2010 23:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 inFJ9lml7jDR for ; Tue, 9 Nov 2010 23:39:36 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 949293A67C2 for ; Tue, 9 Nov 2010 23:39:36 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B4DF2616001; Wed, 10 Nov 2010 08:40:01 +0100 (CET) Date: Wed, 10 Nov 2010 08:40:01 +0100 (CET) Message-Id: <20101110.084001.227006124.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1289361822.1437.6.camel@nomad> References: <20101110030756.GC58773@elstar.local> <1289361822.1437.6.camel@nomad> 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] ssh EOM and netconf 1.1 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, 10 Nov 2010 07:39:37 -0000 Ladislav Lhotka wrote: > On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > I am trying to find a solution that allows to fix the unfortunate EOM > > marker without requiring a new SSH subsystem. Would the following > > work: > > > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > > what we have now. > > > > b) NETCONF client and server exchange hello messages in the > > traditional way, using the ]]>]]> EOM marker. > > > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > > this is taken as the signal to switch from the ]]>]]> EOM marker to > > the new EOM marker (e.g. 0x04). > > How about using the old EoM for hello but include a processing > instruction *before* the tag, e.g. > > > This could be handled entirely within the transport layer. I think this is a better solution. The idea is that in order to avoid the inter-layer communication we have "magic" data before the element that indicates that the new framing sequence is used. If this magic data is done in a way that old implementations just ignore it, we're safe. I was thinking about using XML comments, but a PI should work as well. Juergen said: js> From a purist's architectural point of view, both options require js> either the transport to peak into the message or the message layer js> tell the transport to upgrade to 1.1 framing. We already mix transport and message data in the same stream... but we don't want to put an XML parser in the transport layer, so we have to fix the format so it is easily found, e.g.: [xmldecl CRNL] '' CRNL data ']]>]]>' The peer would switch to the new EOM only if both peers use the same. /martin From biermana@Brocade.com Tue Nov 9 23:48: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 CEC973A6784 for ; Tue, 9 Nov 2010 23:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qvvc6IPo9aGf for ; Tue, 9 Nov 2010 23:48:31 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id BA06D3A67FA for ; Tue, 9 Nov 2010 23:48:31 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAA7kdml021666; Tue, 9 Nov 2010 23:48:55 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id sfhjn06yy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Nov 2010 23:48:55 -0800 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; Tue, 9 Nov 2010 23:53:56 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 9 Nov 2010 23:48:53 -0800 From: Andy Bierman To: Ladislav Lhotka Date: Tue, 9 Nov 2010 23:48:50 -0800 Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAqbmPGD68OfXYSa2xJuvUazCGEgAAN+5Q Message-ID: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <1289374459.1437.62.camel@nomad> In-Reply-To: <1289374459.1437.62.camel@nomad> 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-11-10_04:2010-11-10, 2010-11-10, 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-1011090253 Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 07:48:32 -0000 SGksDQoNCldlIGFyZSBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IGRhdGEgaW5qZWN0aW9uIGF0dGFj a3MgYXQgYWxsIHVubGVzcw0KdGhlcmUgaXMgcmVhbCBmcmFtaW5nLiAgU28gKGIpIGlzIG5vdCBz b2x2ZWQuDQoNClRoZXJlIGlzIG5vIERvUyBhdHRhY2sgcG9zc2libGUuDQpUaGUgc2Vzc2lvbiBz ZW5kaW5nIHRoZSAnZmFrZScgRU9NIGlzIHRoZSBvbmx5IG9uZSBhZmZlY3RlZC4NCkRyb3BwaW5n IHlvdXIgb3duIE5FVENPTkYgc2Vzc2lvbiBkb2VzIG5vdCBjYXVzZSB0aGUgZGV2aWNlIHRvIHN0 b3Agd29ya2luZy4NCg0KSU1PLCAoYikgaXMgdGhlIG9ubHkgcHJvYmxlbSB3b3J0aCBzb2x2aW5n IGhlcmUsIGFuZCBvbmx5DQpQaGlsJ3Mgc29sdXRpb24gZG9lcyB0aGF0LCB1c2luZyBhIG5ldyBu ZXRjb25mLWVvbSBzdWJzeXN0ZW0uDQoNCkFzIFdlcyBwb2ludGVkIG91dCwgaWYgdGhlIG9wZXJh dG9yIGNhbiBzb21laG93IGdldCAweDQgYWNjZXB0ZWQgaW50bw0KY29udGVudCBieSB0aGUgYnVn Z3kgY2xpZW50LCB0aGVuIHRoZSBzZXJ2ZXIgaXMgZ29pbmcgdG8gaW50ZXJwcmV0DQp0aGUgMHg0 IGFzIHRoZSBlbmQgb2YgYSBtZXNzYWdlLCBhbmQgYW55IGRhdGEgYWZ0ZXIgdGhhdCB3aWxsIGJl DQppbnRlcnByZXRlZCBhcyBhIG5ldyBtZXNzYWdlLg0KDQpJIHRoaW5rIHdlIHNob3VsZCBnZXQg YSBuZXcgc2VjdXJpdHkgYXJlYSBhZHZpc29yIGFuZCBsaXN0ZW4gdG8NCndoYXQgdGhhdCBwZXJz b24gaGFzIHRvIHNheSBhYm91dCBhZGRyZXNzaW5nIHRoaXMgc2VjdXJpdHkgcHJvYmxlbS4NClRo YXQgbWlnaHQgaGVscCBnZXQgdGhlIElFU0cgdG8gYXBwcm92ZSB0aGUgc29sdXRpb24gYXMgd2Vs bC4NCg0KSSBvYmplY3QgdG8gY2hhbmdpbmcgNDc0MmJpcyB0byBhZGRyZXNzIHRoaXMgcHJvYmxl bSwgZXNwZWNpYWxseSB3aGVuDQp0aGUgc29sdXRpb24gZG9lc24ndCBhY3R1YWxseSB3b3JrLg0K DQoNCkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0Y29uZi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTGFkaXNsYXYgTGhvdGthDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxMCAx MTozNCBQTQ0KVG86IEFuZHkgQmllcm1hbg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gc3NoIEVPTSBhbmQgbmV0Y29uZiAxLjENCg0KT24gw5p0LCAyMDEwLTEx LTA5IGF0IDIyOjUyIC0wODAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+IFdoYXQgdGVjaG5pY2Fs IHByb2JsZW0gZG9lcyB0aGlzIHNvbHV0aW9uIGFkZHJlc3M/DQo+IEl0IHN0aWxsIHJlbGllcyBv biBdXT5dXT4uICBUaGF0IHNlZW1zIGJyb2tlbiB0byBtZS4NCj4gVGhlIHNvbHV0aW9uIHNob3Vs ZCBub3QgcmVseSBvbiBdXT5dXT4gd2hhdHNvZXZlci4NCj4gDQo+IElzIHRoZSBwcm9ibGVtIHRv IGJlIHNvbHZlZDoNCj4gICBhKSBvcGVyYXRvcnMgd2FudCB0byB1c2UgdGhlIHZhbHVlIF1dPl1d PiBpbiBORVRDT05GIGNvbnRlbnQNCj4gICAgICBzbyBhIGRpZmZlcmVudCBFT00gaXMgbmVlZGVk DQoNCk5vLg0KDQo+ICAgYikgcHJvdGVjdCBhZ2FpbnN0IGRhdGEgaW5qZWN0aW9uIGF0dGFja3MN Cg0KWWVzLCBidXQgYWxzbyBhZ2FpbnN0IHNpbXBsZSBEb1MgYXR0YWNrcyBiYXNlZCBvbiBmb3Jj aW5nIHRoZSBkZXZpY2VzIHRvDQpjbG9zZSB0aGUgc2Vzc2lvbiBhYnJ1cHRseS4gSWYgdGhpcyBo YXBwZW5zIHNpbXVsdGFuZW91c2x5IHRvIHNldmVyYWwNCmRvemVuIHJvdXRlcnMsIGl0IGNvdWxk IG1lYW4gYSBzZXJpb3VzIGRpc3J1cHRpb24uDQoNCj4gICBjKSBhbGxvdyBhIHJhdyBTU0ggdGVy bWluYWwgc2Vzc2lvbiB0byBiZSB1c2VkIGZvciBORVRDT05GDQoNCkkgZG9uJ3QgZ2V0IGhvdyB0 aGlzIGFiaWxpdHkgaXMgYWZmZWN0ZWQgYnkgdGhlIHByb3Bvc2VkIGNoYW5nZS4NCg0KDQo+IA0K PiANCj4gSU1PLCAoYSkgaXMgb2Ygbm8gaW50ZXJlc3QgYXQgYWxsLiAgVGhlIGJpbmFyeSBkYXRh IHR5cGUgY2FuIGJlDQo+IHVzZWQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0uICANCj4gDQo+IE9u bHkgYSByZWFsIGZyYW1pbmcgc29sdXRpb24gYWRkcmVzc2VzIChiKS4gIFdlIHdvdWxkIGZvcmNl IGEgc2Vzc2lvbg0KDQpSZWFsIGZyYW1pbmcgd291bGQgYmUgdGhlIGJlc3QgYnV0IEkgdW5kZXJz dGFuZCBpdCBpcyBub3cgb3V0IG9mDQpxdWVzdGlvbi4gSSBwcmVmZXIgdG8gZml4IHRoZSBob2xl IG5vdyB3aXRoIGFuIGltcGVyZmVjdCBidXQgY29tcGF0aWJsZQ0KcGF0Y2guDQoNCkxhZGENCiAN Cj4gdG8gdGVybWluYXRlIGF0IHRoZSBmaXJzdCBoaW50IG9mIGEgZGF0YSBpbmplY3Rpb24gYXR0 YWNrIGlmIHdlIGNhcmVkDQo+IGFib3V0IHNvbHZpbmcgKGIpLCBidXQgd2UgYXJlIG5vdCBkb2lu ZyB0aGF0Lg0KPiANCj4gTm9uZSBvZiB0aGUgc29sdXRpb25zIGFkZHJlc3NlcyAoYykuDQo+IA0K PiBNYXJzaGFsbCBSb3NlIHVzZWQgdG8gZm9yY2UgV0dzIHRvDQo+ICAgMSkgZGVmaW5lIHRoZSBw cm9ibGVtIHRvIGJlIHNvbHZlZA0KPiAgIDIpIGdldCB0aGUgV0cgdG8gYWdyZWUgdGhlcmUgaXMg YSBwcm9ibGVtIHRvIGJlIHNvbHZlZA0KPiAgIDMpIGRpc2N1c3Mgc29sdXRpb25zDQo+IA0KPiBX aXRob3V0ICgxKSBhbmQgKDIpIGRvbmUsIHdlIGFyZSB3YXN0aW5nIHRpbWUgb24gKDMpLg0KPiAN Cj4gDQo+IEFuZHkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZV0gDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA5LCAyMDEwIDk6MzAgUE0NCj4g VG86IEFuZHkgQmllcm1hbg0KPiBDYzogQW5keSBCaWVybWFuOyBuZXRjb25mQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gc3NoIEVPTSBhbmQgbmV0Y29uZiAxLjENCj4gDQo+IE9u IFR1ZSwgTm92IDA5LCAyMDEwIGF0IDA5OjAyOjEzUE0gLTA4MDAsIEFuZHkgQmllcm1hbiB3cm90 ZToNCj4gPiBJIGRvIG5vdCBhZ3JlZSB3ZSBoYXZlIGEgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJl IHNvbHZlZCBpbiAxLjEuDQo+ID4gSW4gdGhlb3J5LCBkYXRhIGluamVjdGlvbiBjYW4gc3RpbGwg aGFwcGVuIGFmdGVyIHRoZSA8aGVsbG8+LCBzbyB0aGUgYWxsZWdlZA0KPiA+IGRhdGEgaW5qZWN0 aW9uIHByb2JsZW0gaXMgbm90IHNvbHZlZC4NCj4gPiANCj4gPiBTd2l0Y2hpbmcgZnJhbWluZyBk dXJpbmcgdGhlIHNlc3Npb24gc2VlbXMgY29tcGxpY2F0ZWQgYW5kIHByb25lIHRvDQo+ID4gYnVn cyBhbmQgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4NCj4gDQo+IEkgZG8gbm90IHNlZSB3aHku DQo+IA0KPiA+IEEgY2xpZW50IGNhbiBjZXJ0YWlubHkgc2VuZCBhIDxnZXQtY29uZmlnPiBvbiA8 cnVubmluZz4gYmVmb3JlDQo+ID4ga25vd2luZyB0aGUgY2FwYWJpbGl0aWVzLiAgTkVUQ09ORiBh bGxvd3MgdGhlIGNsaWVudCB0byBzZW5kIGFzDQo+ID4gbWFueSA8cnBjPiBtZXNzYWdlcyBpbiBh IHJvdyBhcyBpdCB3YW50cy4gIEkgZG8gbm90IHdhbnQgdG8gYnJlYWsNCj4gPiB0aGlzIGZlYXR1 cmUuDQo+IA0KPiBUaGUgMS4xIHRyYW5zcG9ydCBjYW4gc3RpbGwgYWNjZXB0IF1dPl1dPiBmcmFt aW5nIGZvciBjb3JuZXIgY2FzZXMNCj4gbGlrZSB0aGlzIG9uZS4gVGhlIHBvaW50IGlzIHRvIG1v dmUgdG8gYSBtb3JlIHJvYnVzdCBmcmFtaW5nIHdpdGhvdXQNCj4gbXVjaCBoYXNzbGUgc3VjaCBh cyBuZXcgc3Vic3lzdGVtcy4NCj4gDQo+ID4gV2UgYWxyZWFkeSBhZ3JlZWQgdG8gcHVudCB0aGlz IHRvIDIuMC4gIFRoYXQgaXMgdGhlIFdHIGNvbnNlbnN1cy4gIEkNCj4gPiBzZWUgbm8gcmVhc29u IHRvIGNoYW5nZSB0aGF0IGRlY2lzaW9uLg0KPiANCj4gSSBsaWtlIHRvIHVuZGVyc3RhbmQgd2hl dGhlciB0aGVyZSBpcyBhIF90ZWNobmljYWxfIHByb2JsZW0gd2l0aCB0aGlzDQo+IHByb3Bvc2Fs LiBBbnk/DQo+IA0KPiAvanMNCj4gDQoNCi0tIA0KTGFkaXNsYXYgTGhvdGthLCBDRVNORVQNClBH UCBLZXkgSUQ6IEU3NEU4QzBDDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From biermana@Brocade.com Tue Nov 9 23:57: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 B5A273A68D3 for ; Tue, 9 Nov 2010 23:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9Wsjf9HYZ4RL for ; Tue, 9 Nov 2010 23:57:11 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 9B4F33A6824 for ; Tue, 9 Nov 2010 23:57:11 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAA7pQeV030070; Tue, 9 Nov 2010 23:57:36 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id sfhjn0750-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Nov 2010 23:57:36 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 23:58:04 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 9 Nov 2010 23:57:35 -0800 From: Andy Bierman To: Martin Bjorklund , "lhotka@cesnet.cz" Date: Tue, 9 Nov 2010 23:57:33 -0800 Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAqn/LGvRv+/8ZTq+rMBOnMWEs2gAAY7qw Message-ID: References: <20101110030756.GC58773@elstar.local> <1289361822.1437.6.camel@nomad> <20101110.084001.227006124.mbj@tail-f.com> In-Reply-To: <20101110.084001.227006124.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-10_04:2010-11-10, 2010-11-10, 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-1011090254 Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 07:57:12 -0000 I don't like this solution at all. It forces the SSH layer code to start parsing the XML, in order to determine what EOM sequence to look for. It has to skip past the directive, skip past comments and any other PIs, and then parse the magic PI. What if the old EOM occurs before that is done? What if the new EOM occurs before that is done? The solution needs to let the SSH layer treat the NETCONF channel as a byte stream 100% of the time. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Tuesday, November 09, 2010 11:40 PM To: lhotka@cesnet.cz Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 Ladislav Lhotka wrote: > On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > > Hi, > >=20 > > I am trying to find a solution that allows to fix the unfortunate EOM > > marker without requiring a new SSH subsystem. Would the following > > work: > >=20 > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > > what we have now. > >=20 > > b) NETCONF client and server exchange hello messages in the > > traditional way, using the ]]>]]> EOM marker. > >=20 > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > > this is taken as the signal to switch from the ]]>]]> EOM marker to > > the new EOM marker (e.g. 0x04). >=20 > How about using the old EoM for hello but include a processing > instruction *before* the tag, e.g. > >=20 > This could be handled entirely within the transport layer. I think this is a better solution. The idea is that in order to avoid the inter-layer communication we have "magic" data before the element that indicates that the new framing sequence is used. If this magic data is done in a way that old implementations just ignore it, we're safe. I was thinking about using XML comments, but a PI should work as well. Juergen said: js> From a purist's architectural point of view, both options require js> either the transport to peak into the message or the message layer js> tell the transport to upgrade to 1.1 framing. We already mix transport and message data in the same stream... but we don't want to put an XML parser in the transport layer, so we have to fix the format so it is easily found, e.g.: [xmldecl CRNL] '' CRNL data ']]>]]>' The peer would switch to the new EOM only if both peers use the same. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Nov 10 00:00: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 094BB3A68D3 for ; Wed, 10 Nov 2010 00:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 ibIQba7DdB9a for ; Wed, 10 Nov 2010 00:00:06 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C3C6F3A6802 for ; Wed, 10 Nov 2010 00:00:05 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 85AFB616001; Wed, 10 Nov 2010 09:00:31 +0100 (CET) Date: Wed, 10 Nov 2010 09:00:29 +0100 (CET) Message-Id: <20101110.090029.159985882.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <1289374459.1437.62.camel@nomad> 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] ssh EOM and netconf 1.1 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, 10 Nov 2010 08:00:07 -0000 Andy Bierman wrote: > Hi, > > We are not protecting against data injection attacks at all unless > there is real framing. So (b) is not solved. [...] > IMO, (b) is the only problem worth solving here, and only > Phil's solution does that, using a new netconf-eom subsystem. I disagree. It protects against one form of injection, but there are others. Specifically, it protects against an injection of the EOM, followed by a new rpc. It does not protect against injection of carefullt constructed XML tags that modifies the current operation, as descibed in http://www.ietf.org/mail-archive/web/netconf/current/msg04078.html The only solution that works is that the client checks the input. /martin From mbj@tail-f.com Wed Nov 10 00:02: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 43E4F3A67A4 for ; Wed, 10 Nov 2010 00:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 fZ8V6V0syZLc for ; Wed, 10 Nov 2010 00:02:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4A53C3A68D3 for ; Wed, 10 Nov 2010 00:02:00 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 38CDC616001; Wed, 10 Nov 2010 09:02:26 +0100 (CET) Date: Wed, 10 Nov 2010 09:02:24 +0100 (CET) Message-Id: <20101110.090224.157718889.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <1289361822.1437.6.camel@nomad> <20101110.084001.227006124.mbj@tail-f.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 08:02:01 -0000 Andy Bierman wrote: > I don't like this solution at all. > It forces the SSH layer code to start parsing the XML, > in order to determine what EOM sequence to look for. > It has to skip past the directive, skip > past comments and any other PIs, and then parse the magic PI. > What if the old EOM occurs before that is done? > What if the new EOM occurs before that is done? Please read my text again. /martin > > The solution needs to let the SSH layer treat the NETCONF channel > as a byte stream 100% of the time. > > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Tuesday, November 09, 2010 11:40 PM > To: lhotka@cesnet.cz > Cc: netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 > > Ladislav Lhotka wrote: > > On St, 2010-11-10 at 04:07 +0100, Juergen Schoenwaelder wrote: > > > Hi, > > > > > > I am trying to find a solution that allows to fix the unfortunate EOM > > > marker without requiring a new SSH subsystem. Would the following > > > work: > > > > > > a) We allocate a new EOM marker (e.g. 0x04) we believe is better than > > > what we have now. > > > > > > b) NETCONF client and server exchange hello messages in the > > > traditional way, using the ]]>]]> EOM marker. > > > > > > c) If a peer announces the capability urn:ietf:params:netconf:base:1.1, > > > this is taken as the signal to switch from the ]]>]]> EOM marker to > > > the new EOM marker (e.g. 0x04). > > > > How about using the old EoM for hello but include a processing > > instruction *before* the tag, e.g. > > > > > > This could be handled entirely within the transport layer. > > I think this is a better solution. The idea is that in order to avoid > the inter-layer communication we have "magic" data before the > element that indicates that the new framing sequence is used. If this > magic data is done in a way that old implementations just ignore it, > we're safe. I was thinking about using XML comments, but a PI should > work as well. > > Juergen said: > > js> From a purist's architectural point of view, both options require > js> either the transport to peak into the message or the message layer > js> tell the transport to upgrade to 1.1 framing. > > We already mix transport and message data in the same stream... but we > don't want to put an XML parser in the transport layer, so we have to > fix the format so it is easily found, e.g.: > > [xmldecl CRNL] > '' CRNL > data > ']]>]]>' > > The peer would switch to the new EOM only if both peers use the same. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From lhotka@cesnet.cz Wed Nov 10 00:16: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 6E45D3A6A17 for ; Wed, 10 Nov 2010 00:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 V4I-9C54T6Rd for ; Wed, 10 Nov 2010 00:16:40 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 57B313A6A36 for ; Wed, 10 Nov 2010 00:16:39 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 42B6D2CDE05B; Wed, 10 Nov 2010 09:17:01 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <1289374459.1437.62.camel@nomad> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 10 Nov 2010 16:16:57 +0800 Message-ID: <1289377017.1437.80.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 08:16:41 -0000 On Út, 2010-11-09 at 23:48 -0800, Andy Bierman wrote: > Hi, > > We are not protecting against data injection attacks at all unless > there is real framing. So (b) is not solved. It makes them more difficult to do because a simple check with a non-validating parser (an existing library function) will catch 0x04, unlike the existing EoM. Note that injection attacks are possible with any framing (e.g. adding nodes to a config), but being able to terminate one message and inject an entire forged message is the most dangerous case. > > There is no DoS attack possible. > The session sending the 'fake' EOM is the only one affected. > Dropping your own NETCONF session does not cause the device to stop working. I can have a configuration script that opens many sessions and sends the same piece of (infected) config to many devices. Lada > > IMO, (b) is the only problem worth solving here, and only > Phil's solution does that, using a new netconf-eom subsystem. > > As Wes pointed out, if the operator can somehow get 0x4 accepted into > content by the buggy client, then the server is going to interpret > the 0x4 as the end of a message, and any data after that will be > interpreted as a new message. > > I think we should get a new security area advisor and listen to > what that person has to say about addressing this security problem. > That might help get the IESG to approve the solution as well. > > I object to changing 4742bis to address this problem, especially when > the solution doesn't actually work. > > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Tuesday, November 09, 2010 11:34 PM > To: Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 > > On Út, 2010-11-09 at 22:52 -0800, Andy Bierman wrote: > > What technical problem does this solution address? > > It still relies on ]]>]]>. That seems broken to me. > > The solution should not rely on ]]>]]> whatsoever. > > > > Is the problem to be solved: > > a) operators want to use the value ]]>]]> in NETCONF content > > so a different EOM is needed > > No. > > > b) protect against data injection attacks > > Yes, but also against simple DoS attacks based on forcing the devices to > close the session abruptly. If this happens simultaneously to several > dozen routers, it could mean a serious disruption. > > > c) allow a raw SSH terminal session to be used for NETCONF > > I don't get how this ability is affected by the proposed change. > > > > > > > > IMO, (a) is of no interest at all. The binary data type can be > > used to address this problem. > > > > Only a real framing solution addresses (b). We would force a session > > Real framing would be the best but I understand it is now out of > question. I prefer to fix the hole now with an imperfect but compatible > patch. > > Lada > > > to terminate at the first hint of a data injection attack if we cared > > about solving (b), but we are not doing that. > > > > None of the solutions addresses (c). > > > > Marshall Rose used to force WGs to > > 1) define the problem to be solved > > 2) get the WG to agree there is a problem to be solved > > 3) discuss solutions > > > > Without (1) and (2) done, we are wasting time on (3). > > > > > > Andy > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, November 09, 2010 9:30 PM > > To: Andy Bierman > > Cc: Andy Bierman; netconf@ietf.org > > Subject: Re: [Netconf] ssh EOM and netconf 1.1 > > > > On Tue, Nov 09, 2010 at 09:02:13PM -0800, Andy Bierman wrote: > > > I do not agree we have a problem that needs to be solved in 1.1. > > > In theory, data injection can still happen after the , so the alleged > > > data injection problem is not solved. > > > > > > Switching framing during the session seems complicated and prone to > > > bugs and interoperability problems. > > > > I do not see why. > > > > > A client can certainly send a on before > > > knowing the capabilities. NETCONF allows the client to send as > > > many messages in a row as it wants. I do not want to break > > > this feature. > > > > The 1.1 transport can still accept ]]>]]> framing for corner cases > > like this one. The point is to move to a more robust framing without > > much hassle such as new subsystems. > > > > > We already agreed to punt this to 2.0. That is the WG consensus. I > > > see no reason to change that decision. > > > > I like to understand whether there is a _technical_ problem with this > > proposal. Any? > > > > /js > > > > -- > 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 mehmet.ersue@nsn.com Wed Nov 10 02: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 732F93A6961 for ; Wed, 10 Nov 2010 02:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 TFyFYD4SmPr4 for ; Wed, 10 Nov 2010 02:45:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 759073A6962 for ; Wed, 10 Nov 2010 02:45:05 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAAAjS5C015679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 11:45:28 +0100 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 oAAAjNIN003019; Wed, 10 Nov 2010 11:45:27 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 11:45:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 11:45:19 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401346878@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short notes from the NETCONF Session on November 8, 2010 Thread-Index: AcuAxF4n4in1wInSSMq9NDz37Yqmng== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 10 Nov 2010 10:45:23.0712 (UTC) FILETIME=[60DB4800:01CB80C4] Cc: netconf@ietf.org Subject: [Netconf] Short notes from the NETCONF Session on November 8, 2010 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, 10 Nov 2010 10:45:07 -0000 Hi Dan, please find below a short summary of the NETCONF WG session on November 8, 2010, 1300-1500 at IETF 79 in Beijing, China: - We had approx. 73! participants in the 2 hour session for NETCONF WG. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. Chartered items: - NETCONF 4741bis has the status Publication Requested and is in AD review.=20 - NETCONF 4742bis has the status Publication Requested and is in AD review. - With-defaults capability for NETCONF had some DISCUSSes during IESG review and v13 has been submitted on November 9, 2010. We will remind the remaining three ADs to clear their DISCUSSes. - We had a detailed issue discussion on 'Network Configuration Protocol Access Control Model'. We decided to move authentication objects out of the document. - The content of the NETCONF System Notifications module has been discussed. A renaming has been proposed to avoid system as a term. AOB: - Lada summarized the proposals we have so far for an appropriate solution of the EOM handling issue. The discussion is related to v2.0 of NETCONF and its secure transport SSH. The WG came to the conclusion that the option with the EOM character 0x04 has some benefits. The discussion will continue. A longer summary with action items will be posted to the WG maillist soon. Bert & Mehmet From j.schoenwaelder@jacobs-university.de Wed Nov 10 03:13:18 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 E189628C0EC for ; Wed, 10 Nov 2010 03:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ1DtMmOCD7H for ; Wed, 10 Nov 2010 03:13:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47C4E3A6A90 for ; Wed, 10 Nov 2010 03:12:55 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5385C0019; Wed, 10 Nov 2010 12:13:16 +0100 (CET) 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 XSUL76uY6BLP; Wed, 10 Nov 2010 12:13:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28D0BC000B; Wed, 10 Nov 2010 12:13:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EE8EE159DB10; Wed, 10 Nov 2010 12:13:15 +0100 (CET) Date: Wed, 10 Nov 2010 12:13:15 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101110111315.GC60369@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Andy Bierman , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 11:13:20 -0000 On Wed, Nov 10, 2010 at 07:57:42AM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Juergen, > > do I understand correctly that you suggest, the secure transport layer > should interpret the NETCONF hello message and based on this should > decide which EOM has to be used. > The capability exchange is AFAIU to negotiate the NETCONF capabilities. > Do you really want that SSH transport interprets XML content of a > NETCONF message? Here is how I look at it: The NETCONF message layer tells the transport, after the has been processed, that the other end is running 1.1 and that the transport can use the new EOM marker which can't appear in valid XML content. The transport itself uses the traditional EOM until it gets notified by the message layer - the transport does not have to parse the XML nor does it have to understand capability announcements. > Independently of the technical clearness I have a process-related > concern. > We had this discussion already many times and we all agreed to keep it > as it is now in 4742bis document. > As document shepherd I announced the discussion result and that I give > the document now over to Dan requesting to start the publication > process. > > In spite of everything I think there might be still room to do changes > now or during IETF LC. > However, I would agree with such a change only if there are no > objections in the workgroup. I wanted to find out whether there is a technical solution that allows us to move away from the traditional EOM marker, which does not have the properties we assumed it has, without requiring a new subsystem or port number transports. I understand your procedural concern and as WG chair it is your job to have this concern. At this point in time however, I like to stay out of such a discussion - I am only interested to understand the solution space, trying to find a solutions that restores the originally assumed behaviour (an EOM marker that never appears in valid XML), which is backwards compatible, and which does not require a new subsystem or port number. /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 Nov 10 03:17: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 5BA933A6967 for ; Wed, 10 Nov 2010 03:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 GgX4Do+hMwaf for ; Wed, 10 Nov 2010 03:17:06 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5383F3A6A8C for ; Wed, 10 Nov 2010 03:17:05 -0800 (PST) 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 oAABHUXk009123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 12:17:30 +0100 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 oAABHRjv013033; Wed, 10 Nov 2010 12:17:30 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 12:17:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 12:17:26 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> In-Reply-To: <20101110111315.GC60369@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] ssh EOM and netconf 1.1 Thread-Index: AcuAyEmMUGGBzfu5Q0eJWycDoX+UWQAAG9TQ References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Nov 2010 11:17:29.0279 (UTC) FILETIME=[DC957CF0:01CB80C8] Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 11:17:08 -0000 Understood. Please elaborate "tells the transport". Cheers, Mehmet > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, November 10, 2010 12:13 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Andy Bierman; netconf@ietf.org > Subject: Re: [Netconf] ssh EOM and netconf 1.1 >=20 > On Wed, Nov 10, 2010 at 07:57:42AM +0100, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > Juergen, > > > > do I understand correctly that you suggest, the secure transport > layer > > should interpret the NETCONF hello message and based on this should > > decide which EOM has to be used. > > The capability exchange is AFAIU to negotiate the NETCONF > capabilities. > > Do you really want that SSH transport interprets XML content of a > > NETCONF message? >=20 > Here is how I look at it: >=20 > The NETCONF message layer tells the transport, after the has > been processed, that the other end is running 1.1 and that the > transport can use the new EOM marker which can't appear in valid XML > content. The transport itself uses the traditional EOM until it gets > notified by the message layer - the transport does not have to parse > the XML nor does it have to understand capability announcements. >=20 > > Independently of the technical clearness I have a process-related > > concern. > > We had this discussion already many times and we all agreed to keep > it > > as it is now in 4742bis document. > > As document shepherd I announced the discussion result and that I > give > > the document now over to Dan requesting to start the publication > > process. > > > > In spite of everything I think there might be still room to do > changes > > now or during IETF LC. > > However, I would agree with such a change only if there are no > > objections in the workgroup. >=20 > I wanted to find out whether there is a technical solution that allows > us to move away from the traditional EOM marker, which does not have > the properties we assumed it has, without requiring a new subsystem or > port number transports. >=20 > I understand your procedural concern and as WG chair it is your job to > have this concern. At this point in time however, I like to stay out > of such a discussion - I am only interested to understand the solution > space, trying to find a solutions that restores the originally assumed > behaviour (an EOM marker that never appears in valid XML), which is > backwards compatible, and which does not require a new subsystem or > port number. >=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 From j.schoenwaelder@jacobs-university.de Wed Nov 10 03:26:09 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 A162C3A6A93 for ; Wed, 10 Nov 2010 03:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.108 X-Spam-Level: X-Spam-Status: No, score=-103.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxsZb-ta8-q0 for ; Wed, 10 Nov 2010 03:26:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 92A753A6A26 for ; Wed, 10 Nov 2010 03:26:08 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ACAFC0019; Wed, 10 Nov 2010 12:26:35 +0100 (CET) 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 5hhYG+i14xof; Wed, 10 Nov 2010 12:26:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D1A1C000B; Wed, 10 Nov 2010 12:26:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DB725159DC68; Wed, 10 Nov 2010 12:26:33 +0100 (CET) Date: Wed, 10 Nov 2010 12:26:33 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20101110112633.GA60497@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 10 Nov 2010 11:26:09 -0000 On Wed, Nov 10, 2010 at 12:17:26PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Understood. Please elaborate "tells the transport". transport->switch_to(VERSION1_1); or fprintf(client, "%", (version == VERSION1_1) ? NEWEOM : EOLEOM); or .... This is obviously implementation specific - we do not have ASIs. I am sure an implementer will find a way how to implement this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Wed Nov 10 05:00: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 94D003A68CD for ; Wed, 10 Nov 2010 05:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 BjaIhIALILOT for ; Wed, 10 Nov 2010 05:00:28 -0800 (PST) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 23BD43A68DA for ; Wed, 10 Nov 2010 05:00:19 -0800 (PST) Received: from host86-154-167-163.range86-154.btcentralplus.com (HELO pc6) ([86.154.167.163]) by c2beaomr08.btconnect.com with SMTP id APH17842; Wed, 10 Nov 2010 13:00:45 +0000 (GMT) Message-ID: <00c501cb80ce$ab3b4e40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert \(IETF\) Wijnen" , "netconf" References: <4CD8FCE7.70200@bwijnen.net> Date: Wed, 10 Nov 2010 12:58:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CDA976C.00C4, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4CDA977D.0249,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.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, 10 Nov 2010 13:00:29 -0000 ----- Original Message ----- From: "Bert (IETF) Wijnen" To: "netconf" Sent: Tuesday, November 09, 2010 8:48 AM > Netcon WG participants, > > This revision is the result of IETF LC and IESG review. > While I am checking with the IESG if this revision indeed > addresses all their concerns, pls take a look and speak > up if you see anything weird. > > Do not re-open old issues that we have already decided on. Bert Trouble is, I do not know what issues we have decided on, and re-reading the archives leaves me none the wiser. There is an issue that I raised in August, that caused changes to be made, that were objected to, that caused changes to be unmade, at the end of which the I-D remains wrong (IMO). I am unclear if you regard this as a beaten-to-death issue not to be re-raised, but I expect Alfred will raise it as an erratum if it is not resolved now so here goes. s1.1 says " The following terms are defined in [RFC4741]: o client o datastore" RFC4741 does not have a definitions section; s5.1 defines a configuration datastore which is the term used extensively, along with target datastore, but 'datastore' per se is never defined. Perhaps we should reference 4741bis instead Tom Petch > Bert and Mehmet > > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > Date: Mon, 08 Nov 2010 20:30:02 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-13.txt > Pages : 32 > Date : 2010-11-08 > > 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-13.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 > From biermana@Brocade.com Wed Nov 10 07:12: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 61C7F3A694F for ; Wed, 10 Nov 2010 07:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 XGuH4xDQ5t-0 for ; Wed, 10 Nov 2010 07:12:20 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 419193A6851 for ; Wed, 10 Nov 2010 07:12:20 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAAF7cTL009534; Wed, 10 Nov 2010 07:12:44 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id sfvyh015e-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Nov 2010 07:12:43 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Nov 2010 07:13:12 -0800 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, 10 Nov 2010 07:12:43 -0800 From: Andy Bierman To: "t.petch" , "Bert (IETF) Wijnen" , netconf Date: Wed, 10 Nov 2010 07:12:41 -0800 Thread-Topic: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.txt Thread-Index: AcuA11OgWWBBmXuGTYqi77wIztiPuAAEgkYA Message-ID: References: <4CD8FCE7.70200@bwijnen.net> <00c501cb80ce$ab3b4e40$4001a8c0@gateway.2wire.net> In-Reply-To: <00c501cb80ce$ab3b4e40$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-10_05:2010-11-10, 2010-11-10, 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-1011100074 Subject: Re: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.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, 10 Nov 2010 15:12:21 -0000 RFC 4741 sec 5.1 defines a datastore. The section heading is not called 'Terminology', but the term is defined. What is your concern? Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of t.petch Sent: Wednesday, November 10, 2010 3:59 AM To: Bert (IETF) Wijnen; netconf Subject: Re: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.= txt ----- Original Message ----- From: "Bert (IETF) Wijnen" To: "netconf" Sent: Tuesday, November 09, 2010 8:48 AM > Netcon WG participants, > > This revision is the result of IETF LC and IESG review. > While I am checking with the IESG if this revision indeed > addresses all their concerns, pls take a look and speak > up if you see anything weird. > > Do not re-open old issues that we have already decided on. Bert Trouble is, I do not know what issues we have decided on, and re-reading th= e archives leaves me none the wiser. There is an issue that I raised in Augu= st, that caused changes to be made, that were objected to, that caused changes = to be unmade, at the end of which the I-D remains wrong (IMO). I am unclear if y= ou regard this as a beaten-to-death issue not to be re-raised, but I expect Al= fred will raise it as an erratum if it is not resolved now so here goes. s1.1 says " The following terms are defined in [RFC4741]: o client o datastore" RFC4741 does not have a definitions section; s5.1 defines a configuration datastore which is the term used extensively, along with target datastore, = but 'datastore' per se is never defined. Perhaps we should reference 4741bis instead Tom Petch > Bert and Mehmet > > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > Date: Mon, 08 Nov 2010 20:30:02 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of t= he IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-13.txt > Pages : 32 > Date : 2010-11-08 > > 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-13.t= xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ---------------------------------------------------------------------------= ----- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietfc@btconnect.com Wed Nov 10 10:48: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 2F3F23A68BA for ; Wed, 10 Nov 2010 10:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_15=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 iTT65loTXQ2L for ; Wed, 10 Nov 2010 10:48:34 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 61F413A6853 for ; Wed, 10 Nov 2010 10:48:32 -0800 (PST) Received: from host86-154-167-163.range86-154.btcentralplus.com (HELO pc6) ([86.154.167.163]) by c2beaomr10.btconnect.com with SMTP id API22843; Wed, 10 Nov 2010 18:48:56 +0000 (GMT) Message-ID: <00ff01cb80ff$4f3ffb00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Andy Bierman" , "Bert \(IETF\) Wijnen" , "netconf" References: <4CD8FCE7.70200@bwijnen.net> <00c501cb80ce$ab3b4e40$4001a8c0@gateway.2wire.net> Date: Wed, 10 Nov 2010 18:46:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CDAE90A.024C, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4CDAE918.026E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.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, 10 Nov 2010 18:48:35 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" ; "Bert (IETF) Wijnen" ; "netconf" Sent: Wednesday, November 10, 2010 4:12 PM Subject: RE: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt RFC 4741 sec 5.1 defines a datastore. The section heading is not called 'Terminology', but the term is defined. What is your concern? It defines a configuration datastore, which, as has been discussed before, is not the only kind of datastore, so the definition of datastore is a superset of the definition given in RFC4741 for configuration datastore. As I said, there is a definition of datastore unqualified in 4741bis so I think the reference should be change to that. Tom Petch Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of t.petch Sent: Wednesday, November 10, 2010 3:59 AM To: Bert (IETF) Wijnen; netconf Subject: Re: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.txt ----- Original Message ----- From: "Bert (IETF) Wijnen" To: "netconf" Sent: Tuesday, November 09, 2010 8:48 AM > Netcon WG participants, > > This revision is the result of IETF LC and IESG review. > While I am checking with the IESG if this revision indeed > addresses all their concerns, pls take a look and speak > up if you see anything weird. > > Do not re-open old issues that we have already decided on. Bert Trouble is, I do not know what issues we have decided on, and re-reading the archives leaves me none the wiser. There is an issue that I raised in August, that caused changes to be made, that were objected to, that caused changes to be unmade, at the end of which the I-D remains wrong (IMO). I am unclear if you regard this as a beaten-to-death issue not to be re-raised, but I expect Alfred will raise it as an erratum if it is not resolved now so here goes. s1.1 says " The following terms are defined in [RFC4741]: o client o datastore" RFC4741 does not have a definitions section; s5.1 defines a configuration datastore which is the term used extensively, along with target datastore, but 'datastore' per se is never defined. Perhaps we should reference 4741bis instead Tom Petch > Bert and Mehmet > > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > Date: Mon, 08 Nov 2010 20:30:02 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-13.txt > Pages : 32 > Date : 2010-11-08 > > 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-13.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -------------------------------------------------------------------------------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietf@andybierman.com Wed Nov 10 16:09: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 164143A6811 for ; Wed, 10 Nov 2010 16:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 9lYt2mjIiWUR for ; Wed, 10 Nov 2010 16:09:25 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by core3.amsl.com (Postfix) with ESMTP id 054AB3A67EF for ; Wed, 10 Nov 2010 16:09:24 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAB09q3e006723 for ; Wed, 10 Nov 2010 19:09:52 -0500 Authentication-Results: cm-omr5 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [130.129.69.253] ([130.129.69.253:54489] helo=[130.129.69.253]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CC/3C-28193-E443BDC4; Wed, 10 Nov 2010 19:09:52 -0500 To: "=?utf-8?B?dC5wZXRjaA==?=" , "=?utf-8?B?QW5keSBCaWVybWFu?=" , "=?utf-8?B?QmVydCBcKElFVEZcKSBXaWpuZW4=?=" , "netconf" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Thu, 11 Nov 2010 08:10:03 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1289434203968" Subject: Re: [Netconf] =?utf-8?q?Fwd=3A_I-DAction=3Adraft-ietf-netconf-with-de?= =?utf-8?q?faults-13=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: Thu, 11 Nov 2010 00:09:27 -0000 ------=_Part_0_1289434203968 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T2suLi4gSSB3aWxsIGNoYW5nZSB0aGUgcmVmZXJlbmNlIHRvIDQ3NDFiaXMuCgpBbmR5CgoKLS0t LS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5j b20+CkRhdGU6IFRodSwgTm92IDExLCAyMDEwIDAxOjQ2ClN1YmplY3Q6IFtOZXRjb25mXSBGd2Q6 IEktREFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMy50eHQKVG86ICJB bmR5IEJpZXJtYW4iIDxiaWVybWFuYUBCcm9jYWRlLmNvbT4sICJCZXJ0IFwoSUVURlwpIFdpam5l biIgPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PiwgIm5ldGNvbmYiIDxuZXRjb25mQGlldGYub3JnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiAiQW5keSBCaWVybWFuIiA8Ymllcm1h bmFAQnJvY2FkZS5jb20+ClRvOiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+OyAiQmVy dCAoSUVURikgV2lqbmVuIgo8YmVydGlldGZAYndpam5lbi5uZXQ+OyAibmV0Y29uZiIgPG5ldGNv bmZAaWV0Zi5vcmc+ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTAsIDIwMTAgNDoxMiBQTQpT dWJqZWN0OiBSRTogW05ldGNvbmZdIEZ3ZDogSS1EQWN0aW9uOmRyYWZ0LWlldGYtbmV0Y29uZi13 aXRoLWRlZmF1bHRzLTEzLnR4dAoKClJGQyA0NzQxIHNlYyA1LjEgZGVmaW5lcyBhIGRhdGFzdG9y ZS4KVGhlIHNlY3Rpb24gaGVhZGluZyBpcyBub3QgY2FsbGVkICdUZXJtaW5vbG9neScsIGJ1dCB0 aGUgdGVybSBpcyBkZWZpbmVkLgpXaGF0IGlzIHlvdXIgY29uY2Vybj8KCkl0IGRlZmluZXMgYSBj b25maWd1cmF0aW9uIGRhdGFzdG9yZSwgd2hpY2gsIGFzIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZv cmUsIGlzCm5vdCB0aGUgb25seSBraW5kIG9mIGRhdGFzdG9yZSwgc28gdGhlIGRlZmluaXRpb24g b2YgZGF0YXN0b3JlIGlzIGEgc3VwZXJzZXQgb2YKdGhlIGRlZmluaXRpb24gZ2l2ZW4gaW4gUkZD NDc0MSBmb3IgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuICBBcyBJIHNhaWQsIHRoZXJlCmlzIGEg ZGVmaW5pdGlvbiBvZiBkYXRhc3RvcmUgdW5xdWFsaWZpZWQgaW4gNDc0MWJpcyBzbyBJIHRoaW5r IHRoZSByZWZlcmVuY2UKc2hvdWxkIGJlIGNoYW5nZSB0byB0aGF0LgoKVG9tIFBldGNoCgpBbmR5 CgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogbmV0Y29uZi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKdC5wZXRj aApTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEwLCAyMDEwIDM6NTkgQU0KVG86IEJlcnQgKElF VEYpIFdpam5lbjsgbmV0Y29uZgpTdWJqZWN0OiBSZTogW05ldGNvbmZdIEZ3ZDogSS1EIEFjdGlv bjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMy50eHQKCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0KRnJvbTogIkJlcnQgKElFVEYpIFdpam5lbiIgPGJlcnRpZXRmQGJ3aWpu ZW4ubmV0PgpUbzogIm5ldGNvbmYiIDxuZXRjb25mQGlldGYub3JnPgpTZW50OiBUdWVzZGF5LCBO b3ZlbWJlciAwOSwgMjAxMCA4OjQ4IEFNCgo+IE5ldGNvbiBXRyBwYXJ0aWNpcGFudHMsCj4KPiBU aGlzIHJldmlzaW9uIGlzIHRoZSByZXN1bHQgb2YgSUVURiBMQyBhbmQgSUVTRyByZXZpZXcuCj4g V2hpbGUgSSBhbSBjaGVja2luZyB3aXRoIHRoZSBJRVNHIGlmIHRoaXMgcmV2aXNpb24gaW5kZWVk Cj4gYWRkcmVzc2VzIGFsbCB0aGVpciBjb25jZXJucywgcGxzIHRha2UgYSBsb29rIGFuZCBzcGVh awo+IHVwIGlmIHlvdSBzZWUgYW55dGhpbmcgd2VpcmQuCj4KPiBEbyBub3QgcmUtb3BlbiBvbGQg aXNzdWVzIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlY2lkZWQgb24uCgpCZXJ0CgpUcm91YmxlIGlz LCBJIGRvIG5vdCBrbm93IHdoYXQgaXNzdWVzIHdlIGhhdmUgZGVjaWRlZCBvbiwgYW5kIHJlLXJl YWRpbmcgdGhlCmFyY2hpdmVzIGxlYXZlcyBtZSBub25lIHRoZSB3aXNlci4gIFRoZXJlIGlzIGFu IGlzc3VlIHRoYXQgSSByYWlzZWQgaW4gQXVndXN0LAp0aGF0IGNhdXNlZCBjaGFuZ2VzIHRvIGJl IG1hZGUsIHRoYXQgd2VyZSBvYmplY3RlZCB0bywgdGhhdCBjYXVzZWQgY2hhbmdlcyB0byBiZQp1 bm1hZGUsIGF0IHRoZSBlbmQgb2Ygd2hpY2ggdGhlIEktRCByZW1haW5zIHdyb25nIChJTU8pLiAg SSBhbSB1bmNsZWFyIGlmIHlvdQpyZWdhcmQgdGhpcyBhcyBhIGJlYXRlbi10by1kZWF0aCBpc3N1 ZSBub3QgdG8gYmUgcmUtcmFpc2VkLCBidXQgSSBleHBlY3QgQWxmcmVkCndpbGwKcmFpc2UgaXQg YXMgYW4gZXJyYXR1bSBpZiBpdCBpcyBub3QgcmVzb2x2ZWQgbm93IHNvIGhlcmUgZ29lcy4KCnMx LjEgc2F5cwoiICAgVGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgZGVmaW5lZCBpbiBbUkZDNDc0MV06 CiAgIG8gIGNsaWVudAogICBvICBkYXRhc3RvcmUiCgpSRkM0NzQxIGRvZXMgbm90IGhhdmUgYSBk ZWZpbml0aW9ucyBzZWN0aW9uOyBzNS4xIGRlZmluZXMgYSBjb25maWd1cmF0aW9uCmRhdGFzdG9y ZSB3aGljaCBpcyB0aGUgdGVybSB1c2VkIGV4dGVuc2l2ZWx5LCBhbG9uZyB3aXRoIHRhcmdldCBk YXRhc3RvcmUsIGJ1dAonZGF0YXN0b3JlJyBwZXIgc2UgaXMgbmV2ZXIgZGVmaW5lZC4KClBlcmhh cHMgd2Ugc2hvdWxkIHJlZmVyZW5jZSA0NzQxYmlzIGluc3RlYWQKClRvbSBQZXRjaAoKPiBCZXJ0 IGFuZCBNZWhtZXQKPgo+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPiBTdWJq ZWN0OiBbTmV0Y29uZl0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0 cy0xMy50eHQKPiBEYXRlOiBNb24sIDA4IE5vdiAyMDEwIDIwOjMwOjAyIC0wODAwCj4gRnJvbTog SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZwo+IEND OiBuZXRjb25mQGlldGYub3JnCj4KPgo+Cj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzCmRpcmVjdG9yaWVzLgo+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBXb3JraW5n IEdyb3VwIG9mIHRoZQpJRVRGLgo+Cj4KPiBUaXRsZSAgICAgICAgICAgOiBXaXRoLWRlZmF1bHRz IGNhcGFiaWxpdHkgZm9yIE5FVENPTkYKPiBBdXRob3IocykgICAgICAgOiBBLiBCaWVybWFuLCBC LiBMZW5neWVsCj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVm YXVsdHMtMTMudHh0Cj4gUGFnZXMgICAgICAgICAgIDogMzIKPiBEYXRlICAgICAgICAgICAgOiAy MDEwLTExLTA4Cj4KPiBUaGUgTkVUQ09ORiBwcm90b2NvbCBkZWZpbmVzIHdheXMgdG8gcmVhZCBh bmQgZWRpdCBjb25maWd1cmF0aW9uIGRhdGEKPiBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIuICBJbiBz b21lIGNhc2VzLCBwYXJ0IG9mIHRoaXMgZGF0YSBtYXkgbm90IGJlCj4gc2V0IGJ5IHRoZSBORVRD T05GIGNsaWVudCwgYnV0IHJhdGhlciBhIGRlZmF1bHQgdmFsdWUga25vd24gdG8gdGhlCj4gc2Vy dmVyIGlzIHVzZWQgaW5zdGVhZC4gIEluIG1hbnkgc2l0dWF0aW9ucyB0aGUgTkVUQ09ORiBjbGll bnQgaGFzIGEKPiBwcmlvcmkga25vd2xlZGdlIGFib3V0IGRlZmF1bHQgZGF0YSwgc28gdGhlIE5F VENPTkYgc2VydmVyIGRvZXMgbm90Cj4gbmVlZCB0byBzYXZlIGl0IGluIGEgTkVUQ09ORiBjb25m aWd1cmF0aW9uIGRhdGFzdG9yZSBvciBzZW5kIGl0IHRvCj4gdGhlIGNsaWVudCBpbiBhIHJldHJp ZXZhbCBvcGVyYXRpb24gcmVwbHkuICBJbiBvdGhlciBzaXR1YXRpb25zIHRoZQo+IE5FVENPTkYg Y2xpZW50IHdpbGwgbmVlZCB0aGlzIGRhdGEgZnJvbSB0aGUgc2VydmVyLiAgTm90IGFsbCBzZXJ2 ZXIKPiBpbXBsZW1lbnRhdGlvbnMgdHJlYXQgdGhpcyBkZWZhdWx0IGRhdGEgdGhlIHNhbWUgd2F5 LiAgVGhpcyBkb2N1bWVudAo+IGRlZmluZXMgYSBjYXBhYmlsaXR5LWJhc2VkIGV4dGVuc2lvbiB0 byB0aGUgTkVUQ09ORiBwcm90b2NvbCB0aGF0Cj4gYWxsb3dzIHRoZSBORVRDT05GIGNsaWVudCB0 byBpZGVudGlmeSBob3cgZGVmYXVsdHMgYXJlIHByb2Nlc3NlZCBieQo+IHRoZSBzZXJ2ZXIsIGFu ZCBhbHNvIGRlZmluZXMgbmV3IG1lY2hhbmlzbXMgZm9yIGNsaWVudCBjb250cm9sIG9mCj4gc2Vy dmVyIHByb2Nlc3Npbmcgb2YgZGVmYXVsdCBkYXRhLgo+Cj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJu ZXQtRHJhZnQgaXM6Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTMudHh0Cj4KPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6Cj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8KPgo+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxl IGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXIKPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0 aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQo+IEludGVybmV0LURyYWZ0 Lgo+Cj4KPgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgoKPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE5ldGNvbmYgbWFpbGluZyBsaXN0Cj4gTmV0 Y29uZkBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpO ZXRjb25mIG1haWxpbmcgbGlzdApOZXRjb25mQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCg== ------=_Part_0_1289434203968 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T2suLi4gSSB3aWxsIGNoYW5nZSB0aGUgcmVmZXJlbmNlIHRvIDQ3NDFiaXMuPGJyPjxicj5BbmR5 PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDt0LnBl dGNoJnF1b3Q7ICZsdDtpZXRmY0BidGNvbm5lY3QuY29tJmd0Ozxicj5EYXRlOiBUaHUsIE5vdiAx MSwgMjAxMCAwMTo0Njxicj5TdWJqZWN0OiBbTmV0Y29uZl0gRndkOiBJLURBY3Rpb246ZHJhZnQt aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTMudHh0PGJyPlRvOiAmcXVvdDtBbmR5IEJpZXJt YW4mcXVvdDsgJmx0O2JpZXJtYW5hQEJyb2NhZGUuY29tJmd0OywgJnF1b3Q7QmVydCBcKElFVEZc KSBXaWpuZW4mcXVvdDsgJmx0O2JlcnRpZXRmQGJ3aWpuZW4ubmV0Jmd0OywgJnF1b3Q7bmV0Y29u ZiZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+PGJyPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDtiaWVybWFu YUBCcm9jYWRlLmNvbSZndDs8YnI+VG86ICZxdW90O3QucGV0Y2gmcXVvdDsgJmx0O2lldGZjQGJ0 Y29ubmVjdC5jb20mZ3Q7OyAmcXVvdDtCZXJ0IChJRVRGKSBXaWpuZW4mcXVvdDs8YnI+Jmx0O2Jl cnRpZXRmQGJ3aWpuZW4ubmV0Jmd0OzsgJnF1b3Q7bmV0Y29uZiZxdW90OyAmbHQ7bmV0Y29uZkBp ZXRmLm9yZyZndDs8YnI+U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMCwgMjAxMCA0OjEyIFBN PGJyPlN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gRndkOiBJLURBY3Rpb246ZHJhZnQtaWV0Zi1uZXRj b25mLXdpdGgtZGVmYXVsdHMtMTMudHh0PGJyPjxicj48YnI+UkZDIDQ3NDEgc2VjIDUuMSBkZWZp bmVzIGEgZGF0YXN0b3JlLjxicj5UaGUgc2VjdGlvbiBoZWFkaW5nIGlzIG5vdCBjYWxsZWQgJiMz OTtUZXJtaW5vbG9neSYjMzk7LCBidXQgdGhlIHRlcm0gaXMgZGVmaW5lZC48YnI+V2hhdCBpcyB5 b3VyIGNvbmNlcm4/PGJyPjxicj5JdCBkZWZpbmVzIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUs IHdoaWNoLCBhcyBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLCBpczxicj5ub3QgdGhlIG9ubHkg a2luZCBvZiBkYXRhc3RvcmUsIHNvIHRoZSBkZWZpbml0aW9uIG9mIGRhdGFzdG9yZSBpcyBhIHN1 cGVyc2V0IG9mPGJyPnRoZSBkZWZpbml0aW9uIGdpdmVuIGluIFJGQzQ3NDEgZm9yIGNvbmZpZ3Vy YXRpb24gZGF0YXN0b3JlLiAmbmJzcDtBcyBJIHNhaWQsIHRoZXJlPGJyPmlzIGEgZGVmaW5pdGlv biBvZiBkYXRhc3RvcmUgdW5xdWFsaWZpZWQgaW4gNDc0MWJpcyBzbyBJIHRoaW5rIHRoZSByZWZl cmVuY2U8YnI+c2hvdWxkIGJlIGNoYW5nZSB0byB0aGF0Ljxicj48YnI+VG9tIFBldGNoPGJyPjxi cj5BbmR5PGJyPjxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogbmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Y8YnI+dC5wZXRjaDxicj5TZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEwLCAy MDEwIDM6NTkgQU08YnI+VG86IEJlcnQgKElFVEYpIFdpam5lbjsgbmV0Y29uZjxicj5TdWJqZWN0 OiBSZTogW05ldGNvbmZdIEZ3ZDogSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1k ZWZhdWx0cy0xMy50eHQ8YnI+PGJyPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+RnJv bTogJnF1b3Q7QmVydCAoSUVURikgV2lqbmVuJnF1b3Q7ICZsdDtiZXJ0aWV0ZkBid2lqbmVuLm5l dCZndDs8YnI+VG86ICZxdW90O25ldGNvbmYmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7 PGJyPlNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA5LCAyMDEwIDg6NDggQU08YnI+PGJyPiZndDsg TmV0Y29uIFdHIHBhcnRpY2lwYW50cyw8YnI+Jmd0Ozxicj4mZ3Q7IFRoaXMgcmV2aXNpb24gaXMg dGhlIHJlc3VsdCBvZiBJRVRGIExDIGFuZCBJRVNHIHJldmlldy48YnI+Jmd0OyBXaGlsZSBJIGFt IGNoZWNraW5nIHdpdGggdGhlIElFU0cgaWYgdGhpcyByZXZpc2lvbiBpbmRlZWQ8YnI+Jmd0OyBh ZGRyZXNzZXMgYWxsIHRoZWlyIGNvbmNlcm5zLCBwbHMgdGFrZSBhIGxvb2sgYW5kIHNwZWFrPGJy PiZndDsgdXAgaWYgeW91IHNlZSBhbnl0aGluZyB3ZWlyZC48YnI+Jmd0Ozxicj4mZ3Q7IERvIG5v dCByZS1vcGVuIG9sZCBpc3N1ZXMgdGhhdCB3ZSBoYXZlIGFscmVhZHkgZGVjaWRlZCBvbi48YnI+ PGJyPkJlcnQ8YnI+PGJyPlRyb3VibGUgaXMsIEkgZG8gbm90IGtub3cgd2hhdCBpc3N1ZXMgd2Ug aGF2ZSBkZWNpZGVkIG9uLCBhbmQgcmUtcmVhZGluZyB0aGU8YnI+YXJjaGl2ZXMgbGVhdmVzIG1l IG5vbmUgdGhlIHdpc2VyLiAmbmJzcDtUaGVyZSBpcyBhbiBpc3N1ZSB0aGF0IEkgcmFpc2VkIGlu IEF1Z3VzdCw8YnI+dGhhdCBjYXVzZWQgY2hhbmdlcyB0byBiZSBtYWRlLCB0aGF0IHdlcmUgb2Jq ZWN0ZWQgdG8sIHRoYXQgY2F1c2VkIGNoYW5nZXMgdG8gYmU8YnI+dW5tYWRlLCBhdCB0aGUgZW5k IG9mIHdoaWNoIHRoZSBJLUQgcmVtYWlucyB3cm9uZyAoSU1PKS4gJm5ic3A7SSBhbSB1bmNsZWFy IGlmIHlvdTxicj5yZWdhcmQgdGhpcyBhcyBhIGJlYXRlbi10by1kZWF0aCBpc3N1ZSBub3QgdG8g YmUgcmUtcmFpc2VkLCBidXQgSSBleHBlY3QgQWxmcmVkPGJyPndpbGw8YnI+cmFpc2UgaXQgYXMg YW4gZXJyYXR1bSBpZiBpdCBpcyBub3QgcmVzb2x2ZWQgbm93IHNvIGhlcmUgZ29lcy48YnI+PGJy PnMxLjEgc2F5czxicj4mcXVvdDsgJm5ic3A7IFRoZSBmb2xsb3dpbmcgdGVybXMgYXJlIGRlZmlu ZWQgaW4gW1JGQzQ3NDFdOjxicj4gJm5ic3A7IG8gJm5ic3A7Y2xpZW50PGJyPiAmbmJzcDsgbyAm bmJzcDtkYXRhc3RvcmUmcXVvdDs8YnI+PGJyPlJGQzQ3NDEgZG9lcyBub3QgaGF2ZSBhIGRlZmlu aXRpb25zIHNlY3Rpb247IHM1LjEgZGVmaW5lcyBhIGNvbmZpZ3VyYXRpb248YnI+ZGF0YXN0b3Jl IHdoaWNoIGlzIHRoZSB0ZXJtIHVzZWQgZXh0ZW5zaXZlbHksIGFsb25nIHdpdGggdGFyZ2V0IGRh dGFzdG9yZSwgYnV0PGJyPiYjMzk7ZGF0YXN0b3JlJiMzOTsgcGVyIHNlIGlzIG5ldmVyIGRlZmlu ZWQuPGJyPjxicj5QZXJoYXBzIHdlIHNob3VsZCByZWZlcmVuY2UgNDc0MWJpcyBpbnN0ZWFkPGJy Pjxicj5Ub20gUGV0Y2g8YnI+PGJyPiZndDsgQmVydCBhbmQgTWVobWV0PGJyPiZndDs8YnI+Jmd0 OyAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPiZndDsgU3ViamVjdDogW05l dGNvbmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTMudHh0 PGJyPiZndDsgRGF0ZTogTW9uLCAwOCBOb3YgMjAxMCAyMDozMDowMiAtMDgwMDxicj4mZ3Q7IEZy b206IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZzxicj4mZ3Q7IFRvOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmc8YnI+Jmd0OyBDQzogbmV0Y29uZkBpZXRmLm9yZzxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0czxicj5kaXJlY3Rvcmllcy48YnI+Jmd0OyBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCBv ZiB0aGU8YnI+SUVURi48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgVGl0bGUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFdpdGgtZGVmYXVsdHMgY2FwYWJpbGl0eSBmb3IgTkVU Q09ORjxicj4mZ3Q7IEF1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEEuIEJpZXJtYW4s IEIuIExlbmd5ZWw8YnI+Jmd0OyBGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IGRyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTEzLnR4dDxicj4mZ3Q7IFBhZ2VzICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAzMjxicj4mZ3Q7IERhdGUgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTAtMTEtMDg8YnI+Jmd0Ozxi cj4mZ3Q7IFRoZSBORVRDT05GIHByb3RvY29sIGRlZmluZXMgd2F5cyB0byByZWFkIGFuZCBlZGl0 IGNvbmZpZ3VyYXRpb24gZGF0YTxicj4mZ3Q7IGZyb20gYSBORVRDT05GIHNlcnZlci4gJm5ic3A7 SW4gc29tZSBjYXNlcywgcGFydCBvZiB0aGlzIGRhdGEgbWF5IG5vdCBiZTxicj4mZ3Q7IHNldCBi eSB0aGUgTkVUQ09ORiBjbGllbnQsIGJ1dCByYXRoZXIgYSBkZWZhdWx0IHZhbHVlIGtub3duIHRv IHRoZTxicj4mZ3Q7IHNlcnZlciBpcyB1c2VkIGluc3RlYWQuICZuYnNwO0luIG1hbnkgc2l0dWF0 aW9ucyB0aGUgTkVUQ09ORiBjbGllbnQgaGFzIGE8YnI+Jmd0OyBwcmlvcmkga25vd2xlZGdlIGFi b3V0IGRlZmF1bHQgZGF0YSwgc28gdGhlIE5FVENPTkYgc2VydmVyIGRvZXMgbm90PGJyPiZndDsg bmVlZCB0byBzYXZlIGl0IGluIGEgTkVUQ09ORiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBvciBz ZW5kIGl0IHRvPGJyPiZndDsgdGhlIGNsaWVudCBpbiBhIHJldHJpZXZhbCBvcGVyYXRpb24gcmVw bHkuICZuYnNwO0luIG90aGVyIHNpdHVhdGlvbnMgdGhlPGJyPiZndDsgTkVUQ09ORiBjbGllbnQg d2lsbCBuZWVkIHRoaXMgZGF0YSBmcm9tIHRoZSBzZXJ2ZXIuICZuYnNwO05vdCBhbGwgc2VydmVy PGJyPiZndDsgaW1wbGVtZW50YXRpb25zIHRyZWF0IHRoaXMgZGVmYXVsdCBkYXRhIHRoZSBzYW1l IHdheS4gJm5ic3A7VGhpcyBkb2N1bWVudDxicj4mZ3Q7IGRlZmluZXMgYSBjYXBhYmlsaXR5LWJh c2VkIGV4dGVuc2lvbiB0byB0aGUgTkVUQ09ORiBwcm90b2NvbCB0aGF0PGJyPiZndDsgYWxsb3dz IHRoZSBORVRDT05GIGNsaWVudCB0byBpZGVudGlmeSBob3cgZGVmYXVsdHMgYXJlIHByb2Nlc3Nl ZCBieTxicj4mZ3Q7IHRoZSBzZXJ2ZXIsIGFuZCBhbHNvIGRlZmluZXMgbmV3IG1lY2hhbmlzbXMg Zm9yIGNsaWVudCBjb250cm9sIG9mPGJyPiZndDsgc2VydmVyIHByb2Nlc3Npbmcgb2YgZGVmYXVs dCBkYXRhLjxicj4mZ3Q7PGJyPiZndDsgQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6 PGJyPiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTMudHh0Ij5odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMy50eHQ8 L2E+PGJyPiZndDs8YnI+Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6PGJyPiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88YnI+Jmd0Ozxicj4mZ3Q7IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxl IGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXI8YnI+Jmd0OyBpbXBsZW1lbnRhdGlvbiB0byBh dXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZTxicj4mZ3Q7IElu dGVybmV0LURyYWZ0Ljxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj48YnI+PGJyPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPjxicj48YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPiZn dDsgTmV0Y29uZkBpZXRmLm9yZzxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mPC9hPjxicj4mZ3Q7PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5OZXRjb25mIG1haWxpbmcgbGlzdDxicj5OZXRj b25mQGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPC9hPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+TmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+TmV0Y29uZkBpZXRmLm9yZzxicj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+PGJyPjxicj48 YnI+ ------=_Part_0_1289434203968-- From ietf@andybierman.com Wed Nov 10 17:27: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 D4FCC3A68A2 for ; Wed, 10 Nov 2010 17:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 BesyxpDfSmIU for ; Wed, 10 Nov 2010 17:27:45 -0800 (PST) Received: from smtp103.sbc.mail.ac4.yahoo.com (smtp103.sbc.mail.ac4.yahoo.com [76.13.13.242]) by core3.amsl.com (Postfix) with SMTP id 739FE3A6897 for ; Wed, 10 Nov 2010 17:27:45 -0800 (PST) Received: (qmail 9836 invoked from network); 11 Nov 2010 01:28:08 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp103.sbc.mail.ac4.yahoo.com with SMTP; 10 Nov 2010 17:28:04 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: uuOBcI4VM1mnRMKKtr5q0Lafy61UKGH6fkIlnbQrIxAIg_T VcRSittYWPL3svMMznBT_9wZFM604EYoxiqYDFYvX941aZtAjKnzy1KPfGTy NNkj5v3vXXUPs0cPk8AV2II0LxdOpLRVwMmOHU7gwG50j2NvmHMGpp3iQvil PdgExjLRlJvd6FM7vIeVs9icRpcOWNbHRkx7H8GmCLZ5jDmOpTKH0FHvns5s e1CBimcJJ7a490Q30JzOHs0U_BWdqgrOGgBH8L_vlXcm7Qbv_i9WrjjaAzBM Mv4nd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDB46A1.2050208@andybierman.com> Date: Wed, 10 Nov 2010 17:28:01 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> In-Reply-To: <20101110112633.GA60497@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 01:27:47 -0000 On 11/10/2010 03:26 AM, Juergen Schoenwaelder wrote: > On Wed, Nov 10, 2010 at 12:17:26PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Understood. Please elaborate "tells the transport". > > transport->switch_to(VERSION1_1); > > or > > fprintf(client, "%", (version == VERSION1_1) ? NEWEOM : EOLEOM); > > or > This is a serious layering violation and bad software design. It would prevent NETCONF from being implemented using transport layer code unless it could be specially hacked to support NETCONF. > .... > > This is obviously implementation specific - we do not have ASIs. I am > sure an implementer will find a way how to implement this. > > /js > Andy From ietf@andybierman.com Wed Nov 10 17:33: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 531BE3A68D3 for ; Wed, 10 Nov 2010 17:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 qNfgGTLJK9XZ for ; Wed, 10 Nov 2010 17:33:04 -0800 (PST) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.107]) by core3.amsl.com (Postfix) with SMTP id 72FD73A689C for ; Wed, 10 Nov 2010 17:32:33 -0800 (PST) Received: (qmail 1480 invoked from network); 11 Nov 2010 01:32:53 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 10 Nov 2010 17:32:50 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6AILLD0VM1m0CXiKPvjWxvLRWibOa9M8RI4k2njvK.jv8ws kuO1q.8YnEbGcGRk8nFwkbsgdOntz.zHW1VJWzpHG_yxmfrXSGIF4DFNdzvU pvz.5LAW2mPc9GTqLVYmKzktS7HmOpUhx6hVBR5PYrtxVSaMB2KQR5nEYseW IlQ__Yf8UxQPON9jgv1CB.6wstYdlwKvPEmBh3.TXUxlK._uz.ZnXEEHGcHq 2s.OR27pAz0B6Zh4jUzFTGKTayyaRa_hL5fuB0eY2WlDG7cur4wzOjPH2SXA YpnA5TvWXm_9T X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDB47C0.2070203@andybierman.com> Date: Wed, 10 Nov 2010 17:32:48 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Martin Bjorklund References: <1289374459.1437.62.camel@nomad> <20101110.090029.159985882.mbj@tail-f.com> In-Reply-To: <20101110.090029.159985882.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 01:33:08 -0000 On 11/10/2010 12:00 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> We are not protecting against data injection attacks at all unless >> there is real framing. So (b) is not solved. > > [...] > >> IMO, (b) is the only problem worth solving here, and only >> Phil's solution does that, using a new netconf-eom subsystem. > > I disagree. It protects against one form of injection, but there are > others. Specifically, it protects against an injection of the EOM, > followed by a new rpc. It does not protect against injection of > carefullt constructed XML tags that modifies the current operation, > as descibed in > http://www.ietf.org/mail-archive/web/netconf/current/msg04078.html > > The only solution that works is that the client checks the input. > So none of the proposed solutions actually does an adequate job of protecting against data injection attacks? Then that proves to me that none of the solutions should be adopted. Maybe by 2.0 someone will come up with a solution that actually works. The server cannot rely on the client to be bug-free and always send the right content and never send the EOM by mistake. > > /martin Andy From j.schoenwaelder@jacobs-university.de Wed Nov 10 17:57: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 9AEE63A68E7 for ; Wed, 10 Nov 2010 17:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pKisXNONfel for ; Wed, 10 Nov 2010 17:57:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 67C0D3A68C8 for ; Wed, 10 Nov 2010 17:57:28 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0BD9C002F; Thu, 11 Nov 2010 02:57:55 +0100 (CET) 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 hO5YafcWXwOD; Thu, 11 Nov 2010 02:57:55 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0960FC002E; Thu, 11 Nov 2010 02:57:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DA499159EDE9; Thu, 11 Nov 2010 02:57:53 +0100 (CET) Date: Thu, 11 Nov 2010 02:57:53 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101111015753.GA62096@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDB46A1.2050208@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 01:57:29 -0000 On Wed, Nov 10, 2010 at 05:28:01PM -0800, Andy Bierman wrote: > On 11/10/2010 03:26 AM, Juergen Schoenwaelder wrote: > >On Wed, Nov 10, 2010 at 12:17:26PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > >>Understood. Please elaborate "tells the transport". > > > > transport->switch_to(VERSION1_1); > > > >or > > > > fprintf(client, "%", (version == VERSION1_1) ? NEWEOM : EOLEOM); > > > >or > > > > This is a serious layering violation and bad software design. I must have missing the specification of the interface between the transport layer and the message layer you claim is violated. ;-) > It would prevent NETCONF from being implemented using transport > layer code unless it could be specially hacked to support NETCONF. ??? /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 Wed Nov 10 18:17: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 3961F3A6921 for ; Wed, 10 Nov 2010 18:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 xoGYRsnAFP+1 for ; Wed, 10 Nov 2010 18:17:23 -0800 (PST) Received: from nm15.bullet.mail.ne1.yahoo.com (nm15.bullet.mail.ne1.yahoo.com [98.138.90.78]) by core3.amsl.com (Postfix) with SMTP id 3C8B43A691F for ; Wed, 10 Nov 2010 18:17:23 -0800 (PST) Received: from [98.138.90.55] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 02:17:51 -0000 Received: from [98.138.88.238] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 02:17:51 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 02:17:51 -0000 X-Yahoo-Newman-Id: 741342.64738.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 66507 invoked from network); 11 Nov 2010 02:17:51 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 10 Nov 2010 18:17:50 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: SOuhtdAVM1n_H8RT5AnX32QuWq_FarVKEVyIkt1xbZDKfr2 aFXPN3_uPodbuWnr864O08DWUEYjTBqJKnR.RsyuIWkIMyAFOAN8.K5YQxgy 0mRM6YgfcLQJwECV4V3coDuNLfXCGQQ1hBtCRYIGFdL7FLOiQoOR0q.jtxqv zNicLhlSxY99jcye95PrgaAG7g09.tLXo_3ZB52bkgmkqDvfWvLCr4Za3bQP EsHyW7KUNIfqz9wGxkWVYs2bL.yYE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDB524B.9080901@andybierman.com> Date: Wed, 10 Nov 2010 18:17:47 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" , netconf@ietf.org References: <2E.DC.19358.B902ADC4@cm-omr3> <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> In-Reply-To: <20101111015753.GA62096@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 02:17:24 -0000 On 11/10/2010 05:57 PM, Juergen Schoenwaelder wrote: > On Wed, Nov 10, 2010 at 05:28:01PM -0800, Andy Bierman wrote: >> On 11/10/2010 03:26 AM, Juergen Schoenwaelder wrote: >>> On Wed, Nov 10, 2010 at 12:17:26PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: >>>> Understood. Please elaborate "tells the transport". >>> >>> transport->switch_to(VERSION1_1); >>> >>> or >>> >>> fprintf(client, "%", (version == VERSION1_1) ? NEWEOM : EOLEOM); >>> >>> or >>> >> >> This is a serious layering violation and bad software design. > > I must have missing the specification of the interface between the > transport layer and the message layer you claim is violated. ;-) > >> It would prevent NETCONF from being implemented using transport >> layer code unless it could be specially hacked to support NETCONF. > > ??? > IMO this is terrible protocol and software design. The solution: 1) creates unwarranted coupling between protocol layers 2) assumes the transport layer code can be modified to support NETCONF message layer hacks 3) creates timing issues between the layers. The SSH transport layer would be forced to deliver the first message and then wait to be told what EOM to look for after MSG #1. Meanwhile, new data is arriving and it has to be buffered until the message layer tells the transport layer how to do its job. Andy > /js > From j.schoenwaelder@jacobs-university.de Wed Nov 10 18:28:52 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 1EF2D28C100 for ; Wed, 10 Nov 2010 18:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbOYSqdcTbGZ for ; Wed, 10 Nov 2010 18:28:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6DE6B28B56A for ; Wed, 10 Nov 2010 18:28:50 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E74EC002E; Thu, 11 Nov 2010 03:29:18 +0100 (CET) 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 PmIOM56EQ8x2; Thu, 11 Nov 2010 03:29:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEE42C0007; Thu, 11 Nov 2010 03:29:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 36B32159F02C; Thu, 11 Nov 2010 03:29:16 +0100 (CET) Date: Thu, 11 Nov 2010 03:29:15 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101111022915.GA62441@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDB524B.9080901@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 02:28:52 -0000 On Wed, Nov 10, 2010 at 06:17:47PM -0800, Andy Bierman wrote: > IMO this is terrible protocol and software design. > The solution: > 1) creates unwarranted coupling between protocol layers > 2) assumes the transport layer code can be modified to support > NETCONF message layer hacks I am not aware of anything else that would use the transport layer code. Any solution to fix the EOM requires changes. > 3) creates timing issues between the layers. The SSH transport > layer would be forced to deliver the first message and then > wait to be told what EOM to look for after MSG #1. Meanwhile, > new data is arriving and it has to be buffered until the > message layer tells the transport layer how to do its job. Not true. I answered that before. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Internet-Drafts@ietf.org Wed Nov 10 18:30: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 9C5123A6933; Wed, 10 Nov 2010 18:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 IkwZab7BTWYy; Wed, 10 Nov 2010 18:30:21 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21BC3A6932; Wed, 10 Nov 2010 18:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101111023002.17527.95065.idtracker@localhost> Date: Wed, 10 Nov 2010 18:30:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-14.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, 11 Nov 2010 02:30:27 -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-14.txt Pages : 32 Date : 2010-11-10 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-14.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-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-10182651.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Wed Nov 10 21:20:56 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 02C833A6835 for ; Wed, 10 Nov 2010 21:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvkZShWXUc3v for ; Wed, 10 Nov 2010 21:20:54 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 7DDC83A67E2 for ; Wed, 10 Nov 2010 21:20:54 -0800 (PST) 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 1PGPb2-0004Ry-9X; Thu, 11 Nov 2010 06:21:22 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-4847.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PGPb1-0004sq-Fx; Thu, 11 Nov 2010 06:21:16 +0100 Message-ID: <4CDB7D48.8090308@bwijnen.net> Date: Thu, 11 Nov 2010 13:21:12 +0800 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> In-Reply-To: <20101111022915.GA62441@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b8e7f2a2eb29e5bd6f1ed7ec05ee1a1f X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b8e7f2a2eb29e5bd6f1ed7ec05ee1a1f Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 05:20:56 -0000 It seems we're not really communicating (at least not effectively). Can we get together at 5pm today? If Martin and Phil could dial in via skype or so, that would be great. I'll try to arrange a breakout room Bert On 11/11/10 10:29 AM, Juergen Schoenwaelder wrote: > On Wed, Nov 10, 2010 at 06:17:47PM -0800, Andy Bierman wrote: > >> IMO this is terrible protocol and software design. >> The solution: >> 1) creates unwarranted coupling between protocol layers >> 2) assumes the transport layer code can be modified to support >> NETCONF message layer hacks > I am not aware of anything else that would use the transport layer > code. Any solution to fix the EOM requires changes. > >> 3) creates timing issues between the layers. The SSH transport >> layer would be forced to deliver the first message and then >> wait to be told what EOM to look for after MSG #1. Meanwhile, >> new data is arriving and it has to be buffered until the >> message layer tells the transport layer how to do its job. > Not true. I answered that before. > > /js > From lhotka@cesnet.cz Wed Nov 10 21:57: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 8DA863A69EE for ; Wed, 10 Nov 2010 21:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 UUQUkyswLxFs for ; Wed, 10 Nov 2010 21:57:19 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 593F23A69ED for ; Wed, 10 Nov 2010 21:57:18 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id 011E62CDE058; Thu, 11 Nov 2010 06:57:43 +0100 (CET) From: Ladislav Lhotka To: "Bert (IETF) Wijnen" In-Reply-To: <4CDB7D48.8090308@bwijnen.net> References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 11 Nov 2010 13:57:40 +0800 Message-ID: <1289455060.2391.7.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] ssh EOM and netconf 1.1 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, 11 Nov 2010 05:57:20 -0000 On ÄŒt, 2010-11-11 at 13:21 +0800, Bert (IETF) Wijnen wrote: > It seems we're not really communicating (at least not effectively). > Can we get together at 5pm today? Unfortunately I can't be there, I bought the evening trip to the Great Wall and will be leaving at 4pm. Lada > > If Martin and Phil could dial in via skype or so, that would be great. > > I'll try to arrange a breakout room > Bert > > > On 11/11/10 10:29 AM, Juergen Schoenwaelder wrote: > > On Wed, Nov 10, 2010 at 06:17:47PM -0800, Andy Bierman wrote: > > > >> IMO this is terrible protocol and software design. > >> The solution: > >> 1) creates unwarranted coupling between protocol layers > >> 2) assumes the transport layer code can be modified to support > >> NETCONF message layer hacks > > I am not aware of anything else that would use the transport layer > > code. Any solution to fix the EOM requires changes. > > > >> 3) creates timing issues between the layers. The SSH transport > >> layer would be forced to deliver the first message and then > >> wait to be told what EOM to look for after MSG #1. Meanwhile, > >> new data is arriving and it has to be buffered until the > >> message layer tells the transport layer how to do its job. > > Not true. I answered that before. > > > > /js > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Wed Nov 10 22:12: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 BA3143A68EF for ; Wed, 10 Nov 2010 22:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.260, 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 q4WBhj93cP5z for ; Wed, 10 Nov 2010 22:12:17 -0800 (PST) Received: from smtp103.sbc.mail.re3.yahoo.com (smtp103.sbc.mail.re3.yahoo.com [66.196.96.86]) by core3.amsl.com (Postfix) with SMTP id 6FABB3A6A08 for ; Wed, 10 Nov 2010 22:11:42 -0800 (PST) Received: (qmail 6611 invoked from network); 11 Nov 2010 06:11:50 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp103.sbc.mail.re3.yahoo.com with SMTP; 10 Nov 2010 22:11:47 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 02IaeucVM1k7Y1.srfNQ3w2cSdGGdYTU41PmdtFH0uIT5mp RNTGealROocw0BqSvmFsr0j89VOYEehJoqT.ic3PDuYQFWKImRoQ73ByVEYj QibuQkBJPoE_xePkQN.A9npxpHv_DwuisQslmEhnQwOooGffb7VEAUoa2cjj ._Zkl8nyjkSU57ZpQ3JUjhJijvQmOM7e7VGrHUgo3SGaCv7TxM4Zi6b4qgLX .3qYQxj5oIgKJDcVjp5t7RHBzwxQzzY8RomStqU3DJJ.EFvN2868UIU6Ci4G OFjnfbNc7OYxo._68o6J_QBOZaJFSrwQgf_U9OzbEK50giESs5pt8I3FPqSQ IQkeqZLiVtw.c X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDB891F.8020902@andybierman.com> Date: Wed, 10 Nov 2010 22:11:43 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Martin Bjorklund References: <20101108.072529.22583674.mbj@tail-f.com> <20101108.094605.145687871.mbj@tail-f.com> In-Reply-To: <20101108.094605.145687871.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on 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, 11 Nov 2010 06:12:31 -0000 On 11/08/2010 12:46 AM, Martin Bjorklund wrote: > Martin Bjorklund wrote: >> 2.2 >> >> The module is called "ietf-netconf-system-notifications", but the >> document is called "System Notifications". This was discussed at >> the meeting, so I guess it will change. > > A comment on this. At the meeting, it was suggested that the > notifications etc will be renamed from sys-something to > netconf-something, if I got it right. The reason was that the > notifications are related to the NETCONF subsystem, rather than the > system as a whole. > > But does this affect how sys-config-change is defined? The config > data store can be modified by other means than over NETCONF. I hope > that this notification, whatever is called, is generated also when the > config is modified outside of NETCONF. > > Yes this changes sys-config-change. The WG is saying that all these events are NETCONF events, not system events. There is no support for anything outside a NETCONF-caused event if this module is changed from system to NETCONF events. Perhaps real system event support will be done in the future. > /martin Andy From mbj@tail-f.com Thu Nov 11 00:25: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 387543A67E3 for ; Thu, 11 Nov 2010 00:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 baB7ZKxaWSfv for ; Thu, 11 Nov 2010 00:25:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4BEE73A67A4 for ; Thu, 11 Nov 2010 00:25:25 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F87B616001; Thu, 11 Nov 2010 09:25:53 +0100 (CET) Date: Thu, 11 Nov 2010 09:25:52 +0100 (CET) Message-Id: <20101111.092552.203045010.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4CDB891F.8020902@andybierman.com> References: <20101108.072529.22583674.mbj@tail-f.com> <20101108.094605.145687871.mbj@tail-f.com> <4CDB891F.8020902@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on 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, 11 Nov 2010 08:25:26 -0000 Andy Bierman wrote: > On 11/08/2010 12:46 AM, Martin Bjorklund wrote: > > Martin Bjorklund wrote: > >> 2.2 > >> > >> The module is called "ietf-netconf-system-notifications", but the > >> document is called "System Notifications". This was discussed at > >> the meeting, so I guess it will change. > > > > A comment on this. At the meeting, it was suggested that the > > notifications etc will be renamed from sys-something to > > netconf-something, if I got it right. The reason was that the > > notifications are related to the NETCONF subsystem, rather than the > > system as a whole. > > > > But does this affect how sys-config-change is defined? The config > > data store can be modified by other means than over NETCONF. I hope > > that this notification, whatever is called, is generated also when the > > config is modified outside of NETCONF. > > > > > > Yes this changes sys-config-change. > The WG is saying that all these events are NETCONF events, not system events. I don't think this WG has said that. If if has, please send me a pointer to the ML dicsussion. AFAIK, this is the discussion, and hopefully the WG will reach a conclusion *after* the issue has been discussed. > There is no support for anything outside a NETCONF-caused event if this > module is changed from system to NETCONF events. If all this notification does is report when the config datastore is changed over NETCONF, but NOT if it changed from CLI, WebUI, SNMP... then it is not of much use. > Perhaps real system event support will be done in the future. I would rather standardize this single notification as a system-config-change notif, and remove the rest, than the other way around. /martin From ietf@andybierman.com Thu Nov 11 00:39: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 6E00A3A69AD for ; Thu, 11 Nov 2010 00:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, 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 L0xHJFPtUZtU for ; Thu, 11 Nov 2010 00:39:24 -0800 (PST) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id 57FEF3A6A0C for ; Thu, 11 Nov 2010 00:39:23 -0800 (PST) Received: (qmail 76720 invoked from network); 11 Nov 2010 08:39:51 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 11 Nov 2010 00:39:48 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: LiCKqc8VM1laXZ1iS21NQe55bpy991DQgcltR2sB5YwJ6eL 1Wj3ggv4fJmGX71MPtKY8KijAQqdIJLI0tfyzuIHrMI9L9wzCTdARU6geM7c WcClx89HkHDBTpkI9wU10G.HNZesSzsleq6Fz3bAYlXurvhRIDy_uK7heElJ va7N3tvk_Adn1_jbWHMLvBus_D2wG1kq9.OF.V.0zkuy802S0f5Lp0XACvRM LSdvsHu3Hfw3tilkqA3OFqE3MPldNQhdB77A0DQ70C5ie.hwfix4XuVlfPUJ IPg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDBABD2.2070101@andybierman.com> Date: Thu, 11 Nov 2010 00:39:46 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Martin Bjorklund References: <20101108.072529.22583674.mbj@tail-f.com> <20101108.094605.145687871.mbj@tail-f.com> <4CDB891F.8020902@andybierman.com> <20101111.092552.203045010.mbj@tail-f.com> In-Reply-To: <20101111.092552.203045010.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on 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, 11 Nov 2010 08:39:26 -0000 On 11/11/2010 12:25 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On 11/08/2010 12:46 AM, Martin Bjorklund wrote: >>> Martin Bjorklund wrote: >>>> 2.2 >>>> >>>> The module is called "ietf-netconf-system-notifications", but the >>>> document is called "System Notifications". This was discussed at >>>> the meeting, so I guess it will change. >>> >>> A comment on this. At the meeting, it was suggested that the >>> notifications etc will be renamed from sys-something to >>> netconf-something, if I got it right. The reason was that the >>> notifications are related to the NETCONF subsystem, rather than the >>> system as a whole. >>> >>> But does this affect how sys-config-change is defined? The config >>> data store can be modified by other means than over NETCONF. I hope >>> that this notification, whatever is called, is generated also when the >>> config is modified outside of NETCONF. >>> >>> >> >> Yes this changes sys-config-change. >> The WG is saying that all these events are NETCONF events, not system events. > > I don't think this WG has said that. If if has, please send me a > pointer to the ML dicsussion. AFAIK, this is the discussion, and > hopefully the WG will reach a conclusion *after* the issue has been > discussed. > OK -- maybe you are right. The netconf-config-change event just indicates that the NETCONF server has detected that the config has changed. Since it is a shared config, it doesn't matter who/what changed it. If the server does not know which user changed the config, it can put 'server'. I object to adding in details such as changed-by WEBui, CLI, SNMP, or whatever. That info can be added with proprietary extensions if applicable. >> There is no support for anything outside a NETCONF-caused event if this >> module is changed from system to NETCONF events. > > If all this notification does is report when the config datastore is > changed over NETCONF, but NOT if it changed from CLI, WebUI, > SNMP... then it is not of much use. > >> Perhaps real system event support will be done in the future. > > I would rather standardize this single notification as a > system-config-change notif, and remove the rest, than the other way > around. > > > /martin > > Andy From bertietf@bwijnen.net Thu Nov 11 00:44: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 882083A6A24 for ; Thu, 11 Nov 2010 00:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SQtAlFeIgsy for ; Thu, 11 Nov 2010 00:44:07 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 427E73A6A0E for ; Thu, 11 Nov 2010 00:44:07 -0800 (PST) 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 1PGSlg-0004Ac-TW; Thu, 11 Nov 2010 09:44:34 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-4847.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PGSlf-0003ID-Ut; Thu, 11 Nov 2010 09:44:28 +0100 Message-ID: <4CDBACE6.5060500@bwijnen.net> Date: Thu, 11 Nov 2010 16:44:22 +0800 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> In-Reply-To: <4CDB7D48.8090308@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d5fa2baf3bb95b562e4318909107e557 X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d5fa2baf3bb95b562e4318909107e557 Subject: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 11 Nov 2010 08:44:08 -0000 On 11/11/10 1:21 PM, Bert (IETF) Wijnen wrote: > It seems we're not really communicating (at least not effectively). > Can we get together at 5pm today? > > If Martin and Phil could dial in via skype or so, that would be great. > > I'll try to arrange a breakout room > Bert > From mbj@tail-f.com Thu Nov 11 01:00: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 8E84B28C152 for ; Thu, 11 Nov 2010 01:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 UvDdeZSXZG6o for ; Thu, 11 Nov 2010 01:00:49 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AD4EF28C151 for ; Thu, 11 Nov 2010 01:00:49 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9565B616001; Thu, 11 Nov 2010 10:01:18 +0100 (CET) Date: Thu, 11 Nov 2010 10:01:17 +0100 (CET) Message-Id: <20101111.100117.172855446.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4CDBABD2.2070101@andybierman.com> References: <4CDB891F.8020902@andybierman.com> <20101111.092552.203045010.mbj@tail-f.com> <4CDBABD2.2070101@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on 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, 11 Nov 2010 09:00:50 -0000 Andy Bierman wrote: > On 11/11/2010 12:25 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On 11/08/2010 12:46 AM, Martin Bjorklund wrote: > >>> Martin Bjorklund wrote: > >>>> 2.2 > >>>> > >>>> The module is called "ietf-netconf-system-notifications", but the > >>>> document is called "System Notifications". This was discussed at > >>>> the meeting, so I guess it will change. > >>> > >>> A comment on this. At the meeting, it was suggested that the > >>> notifications etc will be renamed from sys-something to > >>> netconf-something, if I got it right. The reason was that the > >>> notifications are related to the NETCONF subsystem, rather than the > >>> system as a whole. > >>> > >>> But does this affect how sys-config-change is defined? The config > >>> data store can be modified by other means than over NETCONF. I hope > >>> that this notification, whatever is called, is generated also when the > >>> config is modified outside of NETCONF. > >>> > >>> > >> > >> Yes this changes sys-config-change. > >> The WG is saying that all these events are NETCONF events, not system > >> events. > > > > I don't think this WG has said that. If if has, please send me a > > pointer to the ML dicsussion. AFAIK, this is the discussion, and > > hopefully the WG will reach a conclusion *after* the issue has been > > discussed. > > > > OK -- maybe you are right. > The netconf-config-change event just indicates that the NETCONF server > has detected that the config has changed. > > Since it is a shared config, it doesn't matter who/what changed it. > If the server does not know which user changed the config, it can put 'server'. Yes, this is fine. And if it doesn't know which objects are changed, no 'edit' entries are included. > I object to adding in details such as changed-by WEBui, CLI, SNMP, or whatever. > That info can be added with proprietary extensions if applicable. Fine with me. /martin From mbj@tail-f.com Thu Nov 11 02:08:18 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 0A1EA3A68C6 for ; Thu, 11 Nov 2010 02:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 tyBbTcWw+phH for ; Thu, 11 Nov 2010 02:08:17 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3A5513A6893 for ; Thu, 11 Nov 2010 02:08:17 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8499476C26E; Thu, 11 Nov 2010 11:08:45 +0100 (CET) Date: Thu, 11 Nov 2010 11:08:44 +0100 (CET) Message-Id: <20101111.110844.236772928.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4CD64A16.3090408@bwijnen.net> References: <4CD64A16.3090408@bwijnen.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 comments/notes - part 1 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, 11 Nov 2010 10:08:18 -0000 Hi Bert, "Bert (IETF) Wijnen" wrote: > 4. figure 1 (but also other places in the doc) talks about > RPC operation. I thought that in the new terminology we > talk about rpc messages and protocol operations > (rfc4741bis seems to use " operation" once, > maybe that should also be fixed? Actually 6020 has this definition: o RPC operation: A specific Remote Procedure Call, as used within the NETCONF protocol. It is also called a protocol operation. RFC 4741 uses the term "protocol operation" for the base netconf operations, edit-config, get-config etc. However 4741bis uses the term in a more generic way (which I think is a bit confusing). So I would prefer to import the term "RPC operation" from 6020 and use that. /martin From ietf@andybierman.com Thu Nov 11 02:15: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 50B183A68E5 for ; Thu, 11 Nov 2010 02:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 RkXLprEZosGA for ; Thu, 11 Nov 2010 02:15:10 -0800 (PST) Received: from nm30.bullet.mail.ne1.yahoo.com (nm30.bullet.mail.ne1.yahoo.com [98.138.90.93]) by core3.amsl.com (Postfix) with SMTP id 668B53A6835 for ; Thu, 11 Nov 2010 02:15:10 -0800 (PST) Received: from [98.138.90.48] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 10:15:37 -0000 Received: from [98.138.88.236] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 10:15:37 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 10:15:37 -0000 X-Yahoo-Newman-Id: 313286.23626.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 93386 invoked from network); 11 Nov 2010 10:15:37 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 11 Nov 2010 02:15:36 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: j2ONCUgVM1kB.Ge7wP3IZqgfGPyyGvFwPfrAsc_6QBL9.Ci d37APL0H4VdzWLVuE00lJVOPdVfWnGHNVLwGxg1izGpDMSgce.0VaCI7_.yg VQhq5kPD5ULOuPEyd2EKp0NrFywNoIAe6MjmfvHkfEEoUZZ.kq_8.y87PeEp 68xo1wWxLw97Od.SLJBJYBMc8g13qCvvFVv9.iY39rjPWdBUQEwvRbMwaP20 KsIUyHVE3p1kBcgHPO9l8kzSAqgn9pBfDBMCUN9vgY2IcdBahCbr8S4KZ4ve fhw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDBC245.2070901@andybierman.com> Date: Thu, 11 Nov 2010 02:15:33 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Martin Bjorklund References: <4CD64A16.3090408@bwijnen.net> <20101111.110844.236772928.mbj@tail-f.com> In-Reply-To: <20101111.110844.236772928.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] nacm comments/notes - part 1 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, 11 Nov 2010 10:15:11 -0000 On 11/11/2010 02:08 AM, Martin Bjorklund wrote: > Hi Bert, > > "Bert (IETF) Wijnen" wrote: > >> 4. figure 1 (but also other places in the doc) talks about >> RPC operation. I thought that in the new terminology we >> talk about rpc messages and protocol operations >> (rfc4741bis seems to use " operation" once, >> maybe that should also be fixed? > > Actually 6020 has this definition: > > o RPC operation: A specific Remote Procedure Call, as used within > the NETCONF protocol. It is also called a protocol operation. > > RFC 4741 uses the term "protocol operation" for the base netconf > operations, edit-config, get-config etc. However 4741bis uses the > term in a more generic way (which I think is a bit confusing). > > So I would prefer to import the term "RPC operation" from 6020 and use > that. > OK with me, but the NACM rpc-rules are generic -- they work for or in the same way. We don't want to cause confusion. OK -- too late for that. We want to minimize the confusion. > /martin Andy From j.schoenwaelder@jacobs-university.de Thu Nov 11 02:30: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 8FCAB3A689C for ; Thu, 11 Nov 2010 02:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7SA92hyndlr for ; Thu, 11 Nov 2010 02:30:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 24A983A686B for ; Thu, 11 Nov 2010 02:30:25 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25F73C002F; Thu, 11 Nov 2010 11:30:54 +0100 (CET) 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 305FgJetjK1D; Thu, 11 Nov 2010 11:30:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80CF6C0035; Thu, 11 Nov 2010 11:30:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 650C915A26E0; Thu, 11 Nov 2010 11:30:39 +0100 (CET) Date: Thu, 11 Nov 2010 11:30:38 +0100 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20101111103037.GB67708@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDBACE6.5060500@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 11 Nov 2010 10:30:26 -0000 On Thu, Nov 11, 2010 at 04:44:22PM +0800, Bert (IETF) Wijnen wrote: > On 11/11/10 1:21 PM, Bert (IETF) Wijnen wrote: > >It seems we're not really communicating (at least not effectively). > >Can we get together at 5pm today? > > > >If Martin and Phil could dial in via skype or so, that would be great. > > > >I'll try to arrange a breakout room There was no clear outcome. Anyway, I thought I write up how I look at things after the short discussion. Perhaps it helps, perhaps not. Note, I specifically do not consider procedural questions. * What: We need to find agreement whether the possible code injection issues are a problem worth to solve or not, independently of when and how. If we believe there is no problem to solve, stop. * When: Otherwise, we have to decide when to solve the problem. Solving it now may have a chance to replace the old framing before larger scale deployments of NETCONF. Solving it later, when NETCONF is deployed at a larger scale, means we will have to live much longer with old framings in the field. * How: The how has two aspects - the transport versioning aspect and the question how a more robust framing looks like. ** Transport Versioning The SSH and TLS transport layers do not provide a mechanism for versioning, except using diffent SSH subsystems or port numbers. Using SSH subsystems is relatively painful, since lots of security processing is lost by trying probing availability of SSH subsystems. Alternative is to allocate new port numbers (but that does not help on systems that also provide NETCONF access over the default SSH port number). One proposal to solve the transport versioning issue is by having the initial exchange always happen in the old format and to change the transport behaviour by having the message layer tell the transport which version is used after having processed the capabilities contained in the message. ** Robust Framing There have been several proposals for framing alternatives. Lada summarized them, see his slides. Again, this is how _I_ look at the situation. /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 Nov 11 02:42: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 74FA63A6933 for ; Thu, 11 Nov 2010 02:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngH4fBI7FhDZ for ; Thu, 11 Nov 2010 02:42:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B5543A68C6 for ; Thu, 11 Nov 2010 02:42:42 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81314C002F; Thu, 11 Nov 2010 11:43:11 +0100 (CET) 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 9ZcgCT8n29-B; Thu, 11 Nov 2010 11:43:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC66FC0005; Thu, 11 Nov 2010 11:43:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A2F9D15A27BE; Thu, 11 Nov 2010 11:43:10 +0100 (CET) Date: Thu, 11 Nov 2010 11:43:10 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101111104310.GB67779@elstar.local> Mail-Followup-To: Martin Bjorklund , bertietf@bwijnen.net, netconf@ietf.org References: <4CD64A16.3090408@bwijnen.net> <20101111.110844.236772928.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111.110844.236772928.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] nacm comments/notes - part 1 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, 11 Nov 2010 10:42:43 -0000 On Thu, Nov 11, 2010 at 11:08:44AM +0100, Martin Bjorklund wrote: > Hi Bert, > > "Bert (IETF) Wijnen" wrote: > > > 4. figure 1 (but also other places in the doc) talks about > > RPC operation. I thought that in the new terminology we > > talk about rpc messages and protocol operations > > (rfc4741bis seems to use " operation" once, > > maybe that should also be fixed? > > Actually 6020 has this definition: > > o RPC operation: A specific Remote Procedure Call, as used within > the NETCONF protocol. It is also called a protocol operation. > > RFC 4741 uses the term "protocol operation" for the base netconf > operations, edit-config, get-config etc. However 4741bis uses the > term in a more generic way (which I think is a bit confusing). > > So I would prefer to import the term "RPC operation" from 6020 and use > that. But RPC operation is also called a protocol operation. ;-) If there is a problem, we should refer to the "base protocol operations" if we specifically mean the 4741 set of RPC operations. Even 4741 says: o client: A client invokes protocol operations on a server. In addition, a client may subscribe to receive notifications from a server. This does not mean "base protocol operations" in 4741 either. And it says: o protocol operation: A specific remote procedure call, as used within the NETCONF protocol. Is this where you think the confusion may come from? Later 4741bis says: 3. The Operations layer defines a set of base protocol operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base protocol operations. Note "base protocol operations" being used here. (Yeah, different authors. ;-) Further on: The base protocol includes the following protocol operations: Qualified to be 'base'. [...] I do not really see the problem with "protocol operations". I do not think 4741bis implies "protocol operations" means "base protocol operations" per se. /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 Thu Nov 11 02:53: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 686013A6999 for ; Thu, 11 Nov 2010 02:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 DFzLAWqu0mZU for ; Thu, 11 Nov 2010 02:53:13 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3E7B53A6905 for ; Thu, 11 Nov 2010 02:53:13 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B50C76C265; Thu, 11 Nov 2010 11:53:42 +0100 (CET) Date: Thu, 11 Nov 2010 11:53:41 +0100 (CET) Message-Id: <20101111.115341.163268815.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101111104310.GB67779@elstar.local> References: <4CD64A16.3090408@bwijnen.net> <20101111.110844.236772928.mbj@tail-f.com> <20101111104310.GB67779@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 comments/notes - part 1 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, 11 Nov 2010 10:53:14 -0000 Juergen Schoenwaelder wrote: > On Thu, Nov 11, 2010 at 11:08:44AM +0100, Martin Bjorklund wrote: > > Hi Bert, > > > > "Bert (IETF) Wijnen" wrote: > > > > > 4. figure 1 (but also other places in the doc) talks about > > > RPC operation. I thought that in the new terminology we > > > talk about rpc messages and protocol operations > > > (rfc4741bis seems to use " operation" once, > > > maybe that should also be fixed? > > > > Actually 6020 has this definition: > > > > o RPC operation: A specific Remote Procedure Call, as used within > > the NETCONF protocol. It is also called a protocol operation. > > > > RFC 4741 uses the term "protocol operation" for the base netconf > > operations, edit-config, get-config etc. However 4741bis uses the > > term in a more generic way (which I think is a bit confusing). > > > > So I would prefer to import the term "RPC operation" from 6020 and use > > that. > > But RPC operation is also called a protocol operation. ;-) If there is > a problem, we should refer to the "base protocol operations" if we > specifically mean the 4741 set of RPC operations. Even 4741 says: > > o client: A client invokes protocol operations on a server. In > addition, a client may subscribe to receive notifications from a > server. This is from 4741bis, not 4741. /martin From j.schoenwaelder@jacobs-university.de Thu Nov 11 02:58: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 5F4333A6A14 for ; Thu, 11 Nov 2010 02:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht4g1NbWtn1O for ; Thu, 11 Nov 2010 02:58:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3B9A13A6996 for ; Thu, 11 Nov 2010 02:58:41 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79BA2C002F; Thu, 11 Nov 2010 11:59:10 +0100 (CET) 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 3nK4QX46gtXg; Thu, 11 Nov 2010 11:59:10 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C938EC0005; Thu, 11 Nov 2010 11:59:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C202615A2966; Thu, 11 Nov 2010 11:59:09 +0100 (CET) Date: Thu, 11 Nov 2010 11:59:09 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101111105909.GD67779@elstar.local> Mail-Followup-To: Martin Bjorklund , bertietf@bwijnen.net, netconf@ietf.org References: <4CD64A16.3090408@bwijnen.net> <20101111.110844.236772928.mbj@tail-f.com> <20101111104310.GB67779@elstar.local> <20101111.115341.163268815.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111.115341.163268815.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] nacm comments/notes - part 1 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, 11 Nov 2010 10:58:42 -0000 On Thu, Nov 11, 2010 at 11:53:41AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Nov 11, 2010 at 11:08:44AM +0100, Martin Bjorklund wrote: > > > Hi Bert, > > > > > > "Bert (IETF) Wijnen" wrote: > > > > > > > 4. figure 1 (but also other places in the doc) talks about > > > > RPC operation. I thought that in the new terminology we > > > > talk about rpc messages and protocol operations > > > > (rfc4741bis seems to use " operation" once, > > > > maybe that should also be fixed? > > > > > > Actually 6020 has this definition: > > > > > > o RPC operation: A specific Remote Procedure Call, as used within > > > the NETCONF protocol. It is also called a protocol operation. > > > > > > RFC 4741 uses the term "protocol operation" for the base netconf > > > operations, edit-config, get-config etc. However 4741bis uses the > > > term in a more generic way (which I think is a bit confusing). > > > > > > So I would prefer to import the term "RPC operation" from 6020 and use > > > that. > > > > But RPC operation is also called a protocol operation. ;-) If there is > > a problem, we should refer to the "base protocol operations" if we > > specifically mean the 4741 set of RPC operations. Even 4741 says: > > > > o client: A client invokes protocol operations on a server. In > > addition, a client may subscribe to receive notifications from a > > server. > > This is from 4741bis, not 4741. Sorry. Too much typing today. /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 Nov 11 05:44:48 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 C16073A69E5 for ; Thu, 11 Nov 2010 05:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 abQF0GRPghqO for ; Thu, 11 Nov 2010 05:44:48 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 8C3E33A68B7 for ; Thu, 11 Nov 2010 05:44:47 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id E146B2CDE05D; Thu, 11 Nov 2010 14:45:13 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101111103037.GB67708@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> <20101111103037.GB67708@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 11 Nov 2010 21:45:10 +0800 Message-ID: <1289483110.2391.36.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 11 Nov 2010 13:44:48 -0000 On ÄŒt, 2010-11-11 at 11:30 +0100, Juergen Schoenwaelder wrote: > On Thu, Nov 11, 2010 at 04:44:22PM +0800, Bert (IETF) Wijnen wrote: > > On 11/11/10 1:21 PM, Bert (IETF) Wijnen wrote: > > >It seems we're not really communicating (at least not effectively). > > >Can we get together at 5pm today? > > > > > >If Martin and Phil could dial in via skype or so, that would be great. > > > > > >I'll try to arrange a breakout room > > There was no clear outcome. Anyway, I thought I write up how I look > at things after the short discussion. Perhaps it helps, perhaps > not. Note, I specifically do not consider procedural questions. It is an objective description of the situation, I fully agree. Lada > > * What: > > We need to find agreement whether the possible code injection issues > are a problem worth to solve or not, independently of when and > how. If we believe there is no problem to solve, stop. > > * When: > > Otherwise, we have to decide when to solve the problem. Solving it > now may have a chance to replace the old framing before larger scale > deployments of NETCONF. Solving it later, when NETCONF is deployed > at a larger scale, means we will have to live much longer with old > framings in the field. > > * How: > > The how has two aspects - the transport versioning aspect and the > question how a more robust framing looks like. > > ** Transport Versioning > > The SSH and TLS transport layers do not provide a mechanism for > versioning, except using diffent SSH subsystems or port > numbers. Using SSH subsystems is relatively painful, since lots of > security processing is lost by trying probing availability of SSH > subsystems. Alternative is to allocate new port numbers (but that > does not help on systems that also provide NETCONF access over the > default SSH port number). > > One proposal to solve the transport versioning issue is by having > the initial exchange always happen in the old format and to > change the transport behaviour by having the message layer tell the > transport which version is used after having processed the > capabilities contained in the message. > > ** Robust Framing > > There have been several proposals for framing alternatives. Lada > summarized them, see his slides. > > Again, this is how _I_ look at the situation. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Thu Nov 11 15:53: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 BAB373A6781 for ; Thu, 11 Nov 2010 15:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 kcqtNDwR1Nl3 for ; Thu, 11 Nov 2010 15:53:30 -0800 (PST) Received: from nm16.bullet.mail.ne1.yahoo.com (nm16.bullet.mail.ne1.yahoo.com [98.138.90.79]) by core3.amsl.com (Postfix) with SMTP id 4AA283A679F for ; Thu, 11 Nov 2010 15:53:30 -0800 (PST) Received: from [98.138.90.48] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 23:54:01 -0000 Received: from [98.138.87.1] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 23:54:01 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 11 Nov 2010 23:54:01 -0000 X-Yahoo-Newman-Id: 161238.86488.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 32569 invoked from network); 11 Nov 2010 23:54:01 -0000 Received: from [130.129.64.158] (ietf@130.129.64.158 with plain) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 11 Nov 2010 15:53:59 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 2qMLjaEVM1mbMwZcmaL87tttcZFBIyB0C1qLw2p7Qn7ZG3p tMovG8HI98vuOlRlQ_wdgs0PChiYjWcSa6xMxpGwljml6vn3jQmwckqIatMl 2W4BNZbYpQ31qfGvFzmJPPXPeF3OOh.PTlEAC9GGWwKeormIzo2aQkBllsno QHtMixZ8RdL3eeAUnk4s3KImK8wXI1cf0BJzO5UcI_BVDYFXGUB4LG39kvgf PqyG7.besz8iu4suIa8WIS_ob5S1xA1M.BIYBRE5k_47wBmxwmVpSFqaIEJK 7l7oQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDC8215.60909@andybierman.com> Date: Thu, 11 Nov 2010 15:53:57 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Bert \(IETF\) Wijnen" References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> In-Reply-To: <4CDBACE6.5060500@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 11 Nov 2010 23:53:35 -0000 On 11/11/2010 12:44 AM, Bert (IETF) Wijnen wrote: > On 11/11/10 1:21 PM, Bert (IETF) Wijnen wrote: >> It seems we're not really communicating (at least not effectively). >> Can we get together at 5pm today? >> >> If Martin and Phil could dial in via skype or so, that would be great. >> >> I'll try to arrange a breakout room >> Bert >> > > > Here are the issues that I have with this entire discussion: What are we fixing? what problem are we trying to solve? People skip over this part as if it were irrelevant, but to me the solutions are irrelevant if we cannot agree on the problem. It seems the problem is that XML allows ]]>]]> to appear in an XML document, but NETCONF does not allow it. The current 4742bis text says so. So a real actual debatable issue is whether or not it is reasonable to require a NETCONF client application to make sure this sequence is not sent in an XML document. If so, then the current 4742bis solution is fine and no changes are needed to anything. If it is not reasonable to require a client to check for ]]>]]> and escape it (e.g., change > to >), then a new framing mechanism is needed. In that case, a new framing mechanism is needed. If any character sequence whatsoever is used within the content, then the client must implement it correctly. IMO, it is a purist's argument to say that a client must not need to check for otherwise legal XML. The client must escape the magic marker no matter what it is. Solutions which require the client to send some exact XML fragment are flawed, because from a purist POV we cannot restrict valid XML in any way at all. A magic PI or comment cannot be used because it is legal for a 4741 client to send them, and if a 4741bis server misinterprets the sequence, the wrong NETCONF version will be used. Way down the list, after a new framing mechanism is picked, there is the issue of coexistence with old servers. Then a new debatable issue exists, on how to do this. One approach is to use a new subsystem and another is to use a magic PI or XML comment before the . The base:1.1 capability in the could also be used. Using the same subsystem means the old message framing is used for the first message, but maybe not used after that, depending on if both sides agree to use base:1.1 or not. Using the old framing at all in the protocol means a hacker can still inject messages just the same as now, except only for the first message, instead of any message. So there is a debate whether using a new subsystem (e.g. netconf-eom) is too much burden or not. IMO, this is the safest and cleanest way to support both 4741 and 4741bis servers. A new client would first try netconf-eom and then netconf if that did not work. Over time, there will likely be only netconf-eom servers so the client will never need to try the old subsystem. Using 2 subsystems keeps the problem localized to the transport layer code. There are no new special interactions between the message and transport code needed. There are no buffering requirements for the transport, waiting to be told which transport framing mechanism has been negotiated in the operations layer. It is also very clear to implementors what to do because SSH is being used as designed. Using a magic PI or comment would be a hack that people who know SSH may not expect. Andy From lhotka@cesnet.cz Thu Nov 11 17:34: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 B49D13A6878 for ; Thu, 11 Nov 2010 17:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 lKU0QzJAAXiZ for ; Thu, 11 Nov 2010 17:34:38 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 9DC3F3A686E for ; Thu, 11 Nov 2010 17:34:37 -0800 (PST) Received: from [130.129.65.156] (dhcp-419c.meeting.ietf.org [130.129.65.156]) by office2.cesnet.cz (Postfix) with ESMTPSA id D9E0C2CDE05D; Fri, 12 Nov 2010 02:34:59 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4CDC8215.60909@andybierman.com> References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> <4CDC8215.60909@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 12 Nov 2010 09:34:54 +0800 Message-ID: <1289525694.12228.38.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 12 Nov 2010 01:34:39 -0000 On ÄŒt, 2010-11-11 at 15:53 -0800, Andy Bierman wrote: > Here are the issues that I have with this entire discussion: > > What are we fixing? what problem are we trying to solve? > People skip over this part as if it were irrelevant, but to me > the solutions are irrelevant if we cannot agree on the problem. I believe what we are fixing is a security hole. > > It seems the problem is that XML allows ]]>]]> to appear in > an XML document, but NETCONF does not allow it. The current > 4742bis text says so. This is also quite unsystematic. A transport layer spec should not state rules concerning message contents. Does it mean that I can use "]]>]]>" when using TLS but not when using SSH? On a practical side, XML well-formedness can be checked with off-the-shelf tools while the search for "]]>]]>" requires a special implementation. Lada > > So a real actual debatable issue is whether or not it is reasonable > to require a NETCONF client application to make sure this sequence > is not sent in an XML document. If so, then the current 4742bis solution > is fine and no changes are needed to anything. > > If it is not reasonable to require a client to check for ]]>]]> > and escape it (e.g., change > to >), then a new framing mechanism > is needed. > > In that case, a new framing mechanism is needed. > If any character sequence whatsoever is used within the content, > then the client must implement it correctly. > IMO, it is a purist's argument to say that a client must not > need to check for otherwise legal XML. The client must escape > the magic marker no matter what it is. Solutions which require > the client to send some exact XML fragment are flawed, because > from a purist POV we cannot restrict valid XML in any way at all. > A magic PI or comment cannot be used because it is legal for > a 4741 client to send them, and if a 4741bis server misinterprets > the sequence, the wrong NETCONF version will be used. > > Way down the list, after a new framing mechanism is picked, there is the > issue of coexistence with old servers. Then a new debatable issue exists, > on how to do this. One approach is to use a new subsystem and another > is to use a magic PI or XML comment before the . The base:1.1 > capability in the could also be used. Using the same subsystem > means the old message framing is used for the first message, but maybe > not used after that, depending on if both sides agree to use base:1.1 or not. > > Using the old framing at all in the protocol means a hacker can still > inject messages just the same as now, except only for the first message, > instead of any message. > > So there is a debate whether using a new subsystem (e.g. netconf-eom) > is too much burden or not. IMO, this is the safest and cleanest way > to support both 4741 and 4741bis servers. A new client would first try > netconf-eom and then netconf if that did not work. Over time, there > will likely be only netconf-eom servers so the client will never need > to try the old subsystem. > > Using 2 subsystems keeps the problem localized to the transport layer code. > There are no new special interactions between the message and transport code needed. > There are no buffering requirements for the transport, waiting to be told > which transport framing mechanism has been negotiated in the operations layer. > It is also very clear to implementors what to do because SSH is being used as designed. > Using a magic PI or comment would be a hack that people who know SSH may not expect. > > > Andy > > _______________________________________________ > 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 Nov 11 17:57: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 DB6403A6AA4 for ; Thu, 11 Nov 2010 17:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 OynFIrHgQ1Pg for ; Thu, 11 Nov 2010 17:57:57 -0800 (PST) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by core3.amsl.com (Postfix) with SMTP id 60E9A3A6872 for ; Thu, 11 Nov 2010 17:57:57 -0800 (PST) Received: from [98.139.52.196] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 12 Nov 2010 01:58:20 -0000 Received: from [98.139.52.174] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 12 Nov 2010 01:58:20 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 12 Nov 2010 01:58:20 -0000 X-Yahoo-Newman-Id: 494304.89789.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 33070 invoked from network); 12 Nov 2010 01:58:20 -0000 Received: from [130.129.115.111] (ietf@130.129.115.111 with plain) by smtp103.sbc.mail.re3.yahoo.com with SMTP; 11 Nov 2010 17:58:16 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: GBmpF7sVM1nErAZioMcOszqI9rlF1VkxnkpXYQEZb.43xNE raCbrYtltf86esH1RnvW9LwswnFXYgSXwSzcsGLxdlqeiNTq.vvXPJxYuBIz JBPwPzmEXlSJ7vxd73kvkm4q8fM6JqFqC.1hFW.uHI35w7nVJIcJtL2l2Qw8 rN6SrtRPXEiLKrIOsHM0eFknIFYpF2bWjgG_oGi8WTQWpGZO8RGAFCBcpHn7 2PhxoiKQXU7jBsvSuADB1uHb4noM2roihjPugQ2gt6B1eguwWweYmm.EpX10 est8PPfstjDFzcX_CYIqdvzlTdJRRiVpTUdb.sFjpc3G9C8lmxSbwLr5AiT6 2JAtvS6L9OF573g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDC9F35.1080407@andybierman.com> Date: Thu, 11 Nov 2010 17:58:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Ladislav Lhotka References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> <4CDC8215.60909@andybierman.com> <1289525694.12228.38.camel@nomad> In-Reply-To: <1289525694.12228.38.camel@nomad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 12 Nov 2010 01:57:59 -0000 On 11/11/2010 05:34 PM, Ladislav Lhotka wrote: > On ÄŒt, 2010-11-11 at 15:53 -0800, Andy Bierman wrote: > >> Here are the issues that I have with this entire discussion: >> >> What are we fixing? what problem are we trying to solve? >> People skip over this part as if it were irrelevant, but to me >> the solutions are irrelevant if we cannot agree on the problem. > > I believe what we are fixing is a security hole. > >> >> It seems the problem is that XML allows ]]>]]> to appear in >> an XML document, but NETCONF does not allow it. The current >> 4742bis text says so. > > This is also quite unsystematic. A transport layer spec should not state > rules concerning message contents. Does it mean that I can use "]]>]]>" > when using TLS but not when using SSH? > > On a practical side, XML well-formedness can be checked with > off-the-shelf tools while the search for "]]>]]>" requires a special > implementation. > Let's do a little reality check... We are not really concerned with XML attributes in NETCONF content because we are standardizing on YANG, and YANG does not allow them. There is only 1 place in the entire protocol where a client could possibly provide an XML attribute and that is in the element. There are no implementations at all that allow the user to specify XML attributes to add to and I doubt this will ever happen because it serves no use case at all. This NETCONF feature is for the client implementation. I do not know of any application implementation that actually uses it at all, let alone provides a user API to set these attributes. Therefore it seems quite reasonable to keep the current 4742bis text and require a client to make sure ]]>]]> is not sent inside a NETCONF message. In theory XML allows in in a PI or XML attribute. In reality, NETCONF does not use these XML features so a client should not ever need to send them. Andy > Lada > >> >> So a real actual debatable issue is whether or not it is reasonable >> to require a NETCONF client application to make sure this sequence >> is not sent in an XML document. If so, then the current 4742bis solution >> is fine and no changes are needed to anything. >> >> If it is not reasonable to require a client to check for ]]>]]> >> and escape it (e.g., change> to>), then a new framing mechanism >> is needed. >> >> In that case, a new framing mechanism is needed. >> If any character sequence whatsoever is used within the content, >> then the client must implement it correctly. >> IMO, it is a purist's argument to say that a client must not >> need to check for otherwise legal XML. The client must escape >> the magic marker no matter what it is. Solutions which require >> the client to send some exact XML fragment are flawed, because >> from a purist POV we cannot restrict valid XML in any way at all. >> A magic PI or comment cannot be used because it is legal for >> a 4741 client to send them, and if a 4741bis server misinterprets >> the sequence, the wrong NETCONF version will be used. >> >> Way down the list, after a new framing mechanism is picked, there is the >> issue of coexistence with old servers. Then a new debatable issue exists, >> on how to do this. One approach is to use a new subsystem and another >> is to use a magic PI or XML comment before the. The base:1.1 >> capability in the could also be used. Using the same subsystem >> means the old message framing is used for the first message, but maybe >> not used after that, depending on if both sides agree to use base:1.1 or not. >> >> Using the old framing at all in the protocol means a hacker can still >> inject messages just the same as now, except only for the first message, >> instead of any message. >> >> So there is a debate whether using a new subsystem (e.g. netconf-eom) >> is too much burden or not. IMO, this is the safest and cleanest way >> to support both 4741 and 4741bis servers. A new client would first try >> netconf-eom and then netconf if that did not work. Over time, there >> will likely be only netconf-eom servers so the client will never need >> to try the old subsystem. >> >> Using 2 subsystems keeps the problem localized to the transport layer code. >> There are no new special interactions between the message and transport code needed. >> There are no buffering requirements for the transport, waiting to be told >> which transport framing mechanism has been negotiated in the operations layer. >> It is also very clear to implementors what to do because SSH is being used as designed. >> Using a magic PI or comment would be a hack that people who know SSH may not expect. >> >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From lhotka@cesnet.cz Thu Nov 11 21:00: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 161A73A693E for ; Thu, 11 Nov 2010 21:00:31 -0800 (PST) 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=[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 Ouo2GV188Uhw for ; Thu, 11 Nov 2010 21:00:22 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 333C23A6984 for ; Thu, 11 Nov 2010 21:00:22 -0800 (PST) Received: from [1.202.81.120] (unknown [1.202.81.120]) by office2.cesnet.cz (Postfix) with ESMTPSA id 519E22CDE05E; Fri, 12 Nov 2010 06:00:47 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4CDC9F35.1080407@andybierman.com> References: <20101110045222.GA59331@elstar.local> <20101110053024.GA59500@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401346570@DEMUEXC006.nsn-intra.net> <20101110111315.GC60369@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64013468E2@DEMUEXC006.nsn-intra.net> <20101110112633.GA60497@elstar.local> <4CDB46A1.2050208@andybierman.com> <20101111015753.GA62096@elstar.local> <4CDB524B.9080901@andybierman.com> <20101111022915.GA62441@elstar.local> <4CDB7D48.8090308@bwijnen.net> <4CDBACE6.5060500@bwijnen.net> <4CDC8215.60909@andybierman.com> <1289525694.12228.38.camel@nomad> <4CDC9F35.1080407@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 12 Nov 2010 13:00:43 +0800 Message-ID: <1289538043.2145.14.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 12 Nov 2010 05:00:31 -0000 On ÄŒt, 2010-11-11 at 17:58 -0800, Andy Bierman wrote: > On 11/11/2010 05:34 PM, Ladislav Lhotka wrote: > > On ÄŒt, 2010-11-11 at 15:53 -0800, Andy Bierman wrote: > > > >> Here are the issues that I have with this entire discussion: > >> > >> What are we fixing? what problem are we trying to solve? > >> People skip over this part as if it were irrelevant, but to me > >> the solutions are irrelevant if we cannot agree on the problem. > > > > I believe what we are fixing is a security hole. > > > >> > >> It seems the problem is that XML allows ]]>]]> to appear in > >> an XML document, but NETCONF does not allow it. The current > >> 4742bis text says so. > > > > This is also quite unsystematic. A transport layer spec should not state > > rules concerning message contents. Does it mean that I can use "]]>]]>" > > when using TLS but not when using SSH? > > > > On a practical side, XML well-formedness can be checked with > > off-the-shelf tools while the search for "]]>]]>" requires a special > > implementation. > > > > Let's do a little reality check... > We are not really concerned with XML attributes in NETCONF content > because we are standardizing on YANG, and YANG does not allow them. > There is only 1 place in the entire protocol where a client could > possibly provide an XML attribute and that is in the element. > > There are no implementations at all that allow the user to specify > XML attributes to add to and I doubt this will ever happen because > it serves no use case at all. This NETCONF feature is for the client > implementation. I do not know of any application implementation that > actually uses it at all, let alone provides a user API to set these attributes. For a cracker, the easiest way is to try to smuggle an XML comment like this to _any_ place of the XML document: This is a perfectly valid XML, any parser will be happy to completely ignore the comment. If this is not a huge security hole, then I don't know what else is. Lada > > Therefore it seems quite reasonable to keep the current 4742bis text > and require a client to make sure ]]>]]> is not sent inside a NETCONF message. > In theory XML allows in in a PI or XML attribute. In reality, NETCONF > does not use these XML features so a client should not ever need to send them. > > > Andy > > > Lada > > > >> > >> So a real actual debatable issue is whether or not it is reasonable > >> to require a NETCONF client application to make sure this sequence > >> is not sent in an XML document. If so, then the current 4742bis solution > >> is fine and no changes are needed to anything. > >> > >> If it is not reasonable to require a client to check for ]]>]]> > >> and escape it (e.g., change> to>), then a new framing mechanism > >> is needed. > >> > >> In that case, a new framing mechanism is needed. > >> If any character sequence whatsoever is used within the content, > >> then the client must implement it correctly. > >> IMO, it is a purist's argument to say that a client must not > >> need to check for otherwise legal XML. The client must escape > >> the magic marker no matter what it is. Solutions which require > >> the client to send some exact XML fragment are flawed, because > >> from a purist POV we cannot restrict valid XML in any way at all. > >> A magic PI or comment cannot be used because it is legal for > >> a 4741 client to send them, and if a 4741bis server misinterprets > >> the sequence, the wrong NETCONF version will be used. > >> > >> Way down the list, after a new framing mechanism is picked, there is the > >> issue of coexistence with old servers. Then a new debatable issue exists, > >> on how to do this. One approach is to use a new subsystem and another > >> is to use a magic PI or XML comment before the. The base:1.1 > >> capability in the could also be used. Using the same subsystem > >> means the old message framing is used for the first message, but maybe > >> not used after that, depending on if both sides agree to use base:1.1 or not. > >> > >> Using the old framing at all in the protocol means a hacker can still > >> inject messages just the same as now, except only for the first message, > >> instead of any message. > >> > >> So there is a debate whether using a new subsystem (e.g. netconf-eom) > >> is too much burden or not. IMO, this is the safest and cleanest way > >> to support both 4741 and 4741bis servers. A new client would first try > >> netconf-eom and then netconf if that did not work. Over time, there > >> will likely be only netconf-eom servers so the client will never need > >> to try the old subsystem. > >> > >> Using 2 subsystems keeps the problem localized to the transport layer code. > >> There are no new special interactions between the message and transport code needed. > >> There are no buffering requirements for the transport, waiting to be told > >> which transport framing mechanism has been negotiated in the operations layer. > >> It is also very clear to implementors what to do because SSH is being used as designed. > >> Using a magic PI or comment would be a hack that people who know SSH may not expect. > >> > >> > >> Andy > >> > >> _______________________________________________ > >> 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 Nov 11 22:23: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 C4DCA3A69C6 for ; Thu, 11 Nov 2010 22:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.632, 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 BtkHdekyNGvm for ; Thu, 11 Nov 2010 22:23:40 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by core3.amsl.com (Postfix) with ESMTP id DC34B3A688B for ; Thu, 11 Nov 2010 22:23:39 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAC6OAhS022329 for ; Fri, 12 Nov 2010 01:24:10 -0500 Authentication-Results: cm-omr12 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [130.129.69.253] ([130.129.69.253:35182] helo=[130.129.69.253]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 90/ED-30981-88DDCDC4; Fri, 12 Nov 2010 01:24:10 -0500 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" Message-ID: <90.ED.30981.88DDCDC4@cm-omr12> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Fri, 12 Nov 2010 14:24:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1289543059832" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?Breakout_room_Diamond_1_-_for_EOM_discussion_?= =?utf-8?q?today=2C_5pm_Beijing_time=2E?= 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, 12 Nov 2010 06:23:45 -0000 ------=_Part_0_1289543059832 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpXZSBhcmUgaW1wbGVtZW50aW5nIG5ldGNvbmYsIG5vdCBYTUwgcGFyc2VycyB0aGF0IHNl bmQgZWFjaCBvdGhlciBtZXNzYWdlcy4gIEEgY29uZm9ybWFudCA0ODQyYmlzIGltcGxlbWVudGF0 aW9uIGlzIG5vdCBhbGxvd2VkIHRvIHNlbmQgdGhpcyBzdHJpbmcsIHNvIG9ubHkgYSBidWdneSBj bGllbnQgaGFzIHRoaXMgcHJvYmxlbS4KCklmIHdlIHVzZWQgMHg0IGluc3RlYWQgb2YgdGhlIGN1 cnJlbnQgZW9tIHRoZW4gYSBidWdneSBjbGllbnQgY2FuIGNhdXNlIHRoaXMgZXhhY3QgcHJvYmxl bSBpbiB0aGUgc2VydmVyLgoKSU1PLCB3ZSBhcmUgZGViYXRpbmcgbWVhbmluZ2xlc3MgY29uamVj dHVyZSB3aGVuIHdlIHRhbGsgYWJvdXQgd2hpY2ggYnVncyBhcmUgZ29pbmcgdG8gaGFwcGVuIGlu IHRoZSBmdXR1cmUuICAKCjQ3NDJiaXMgc2F5cyB3aGF0IGEgY2xpZW50IG11c3QgZG8uCkEgY2xp ZW50IHRoYXQgaW1wbGVtZW50cyB0aGUgc3BlYyBjb3JyZWN0bHkgZG9lc24ndCBoYXZlIGEgcHJv YmxlbS4KCgpBbmR5IAoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTGFkaXNsYXYg TGhvdGthIiA8bGhvdGthQGNlc25ldC5jej4KRGF0ZTogRnJpLCBOb3YgMTIsIDIwMTAgMTM6MDAK U3ViamVjdDogW05ldGNvbmZdIEJyZWFrb3V0IHJvb20gRGlhbW9uZCAxIC0gZm9yIEVPTSBkaXNj dXNzaW9uIHRvZGF5LCA1cG0gQmVpamluZyB0aW1lLgpUbzogIkFuZHkgQmllcm1hbiIgPGlldGZA YW5keWJpZXJtYW4uY29tPgpDYzogIkJlcnQgKElFVEYpIFdpam5lbiIgPGJlcnRpZXRmQGJ3aWpu ZW4ubmV0PiwgPG5ldGNvbmZAaWV0Zi5vcmc+CgoKT24gxIx0LCAyMDEwLTExLTExIGF0IDE3OjU4 IC0wODAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gT24gMTEvMTEvMjAxMCAwNTozNCBQTSwgTGFk aXNsYXYgTGhvdGthIHdyb3RlOgo+ID4gT24gxIx0LCAyMDEwLTExLTExIGF0IDE1OjUzIC0wODAw LCBBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gPgo+ID4+IEhlcmUgYXJlIHRoZSBpc3N1ZXMgdGhhdCBJ IGhhdmUgd2l0aCB0aGlzIGVudGlyZSBkaXNjdXNzaW9uOgo+ID4+Cj4gPj4gV2hhdCBhcmUgd2Ug Zml4aW5nPyB3aGF0IHByb2JsZW0gYXJlIHdlIHRyeWluZyB0byBzb2x2ZT8KPiA+PiBQZW9wbGUg c2tpcCBvdmVyIHRoaXMgcGFydCBhcyBpZiBpdCB3ZXJlIGlycmVsZXZhbnQsIGJ1dCB0byBtZQo+ ID4+IHRoZSBzb2x1dGlvbnMgYXJlIGlycmVsZXZhbnQgaWYgd2UgY2Fubm90IGFncmVlIG9uIHRo ZSBwcm9ibGVtLgo+ID4KPiA+IEkgYmVsaWV2ZSB3aGF0IHdlIGFyZSBmaXhpbmcgaXMgYSBzZWN1 cml0eSBob2xlLgo+ID4KPiA+Pgo+ID4+IEl0IHNlZW1zIHRoZSBwcm9ibGVtIGlzIHRoYXQgWE1M IGFsbG93cyBdXT5dXT4gIHRvIGFwcGVhciBpbgo+ID4+IGFuIFhNTCBkb2N1bWVudCwgYnV0IE5F VENPTkYgZG9lcyBub3QgYWxsb3cgaXQuICBUaGUgY3VycmVudAo+ID4+IDQ3NDJiaXMgdGV4dCBz YXlzIHNvLgo+ID4KPiA+IFRoaXMgaXMgYWxzbyBxdWl0ZSB1bnN5c3RlbWF0aWMuIEEgdHJhbnNw b3J0IGxheWVyIHNwZWMgc2hvdWxkIG5vdCBzdGF0ZQo+ID4gcnVsZXMgY29uY2VybmluZyBtZXNz YWdlIGNvbnRlbnRzLiBEb2VzIGl0IG1lYW4gdGhhdCBJIGNhbiB1c2UgIl1dPl1dPiIKPiA+IHdo ZW4gdXNpbmcgVExTIGJ1dCBub3Qgd2hlbiB1c2luZyBTU0g/Cj4gPgo+ID4gT24gYSBwcmFjdGlj YWwgc2lkZSwgWE1MIHdlbGwtZm9ybWVkbmVzcyBjYW4gYmUgY2hlY2tlZCB3aXRoCj4gPiBvZmYt dGhlLXNoZWxmIHRvb2xzIHdoaWxlIHRoZSBzZWFyY2ggZm9yICJdXT5dXT4iIHJlcXVpcmVzIGEg c3BlY2lhbAo+ID4gaW1wbGVtZW50YXRpb24uCj4gPgo+IAo+IExldCdzIGRvIGEgbGl0dGxlIHJl YWxpdHkgY2hlY2suLi4KPiBXZSBhcmUgbm90IHJlYWxseSBjb25jZXJuZWQgd2l0aCBYTUwgYXR0 cmlidXRlcyBpbiBORVRDT05GIGNvbnRlbnQKPiBiZWNhdXNlIHdlIGFyZSBzdGFuZGFyZGl6aW5n IG9uIFlBTkcsIGFuZCBZQU5HIGRvZXMgbm90IGFsbG93IHRoZW0uCj4gVGhlcmUgaXMgb25seSAx IHBsYWNlIGluIHRoZSBlbnRpcmUgcHJvdG9jb2wgd2hlcmUgYSBjbGllbnQgY291bGQKPiBwb3Nz aWJseSBwcm92aWRlIGFuIFhNTCBhdHRyaWJ1dGUgYW5kIHRoYXQgaXMgaW4gdGhlIDxycGM+IGVs ZW1lbnQuCj4gCj4gVGhlcmUgYXJlIG5vIGltcGxlbWVudGF0aW9ucyBhdCBhbGwgdGhhdCBhbGxv dyB0aGUgdXNlciB0byBzcGVjaWZ5Cj4gWE1MIGF0dHJpYnV0ZXMgdG8gYWRkIHRvIDxycGM+IGFu ZCBJIGRvdWJ0IHRoaXMgd2lsbCBldmVyIGhhcHBlbiBiZWNhdXNlCj4gaXQgc2VydmVzIG5vIHVz ZSBjYXNlIGF0IGFsbC4gIFRoaXMgTkVUQ09ORiBmZWF0dXJlIGlzIGZvciB0aGUgY2xpZW50Cj4g aW1wbGVtZW50YXRpb24uICBJIGRvIG5vdCBrbm93IG9mIGFueSBhcHBsaWNhdGlvbiBpbXBsZW1l bnRhdGlvbiB0aGF0Cj4gYWN0dWFsbHkgdXNlcyBpdCBhdCBhbGwsIGxldCBhbG9uZSBwcm92aWRl cyBhIHVzZXIgQVBJIHRvIHNldCB0aGVzZSBhdHRyaWJ1dGVzLgoKRm9yIGEgY3JhY2tlciwgdGhl IGVhc2llc3Qgd2F5IGlzIHRvIHRyeSB0byBzbXVnZ2xlIGFuIFhNTCBjb21tZW50IGxpa2UKdGhp cyB0byBfYW55XyBwbGFjZSBvZiB0aGUgWE1MIGRvY3VtZW50OgoKPCEtLSBdXT5dXT48cnBjIG1l c3NhZ2UtaWQ9IjEwMSIgeG1sbnM9Ii4uLiI+Li4uPC9ycGM+IC0tPgoKVGhpcyBpcyBhIHBlcmZl Y3RseSB2YWxpZCBYTUwsIGFueSBwYXJzZXIgd2lsbCBiZSBoYXBweSB0byBjb21wbGV0ZWx5Cmln bm9yZSB0aGUgY29tbWVudC4gSWYgdGhpcyBpcyBub3QgYSBodWdlIHNlY3VyaXR5IGhvbGUsIHRo ZW4gSSBkb24ndAprbm93IHdoYXQgZWxzZSBpcy4KCkxhZGEgCgogIAo+IAo+IFRoZXJlZm9yZSBp dCBzZWVtcyBxdWl0ZSByZWFzb25hYmxlIHRvIGtlZXAgdGhlIGN1cnJlbnQgNDc0MmJpcyB0ZXh0 Cj4gYW5kIHJlcXVpcmUgYSBjbGllbnQgdG8gbWFrZSBzdXJlIF1dPl1dPiBpcyBub3Qgc2VudCBp bnNpZGUgYSBORVRDT05GIG1lc3NhZ2UuCj4gSW4gdGhlb3J5IFhNTCBhbGxvd3MgaW4gaW4gYSBQ SSBvciBYTUwgYXR0cmlidXRlLiAgSW4gcmVhbGl0eSwgTkVUQ09ORgo+IGRvZXMgbm90IHVzZSB0 aGVzZSBYTUwgZmVhdHVyZXMgc28gYSBjbGllbnQgc2hvdWxkIG5vdCBldmVyIG5lZWQgdG8gc2Vu ZCB0aGVtLgo+IAo+IAo+IEFuZHkKPiAKPiA+IExhZGEKPiA+Cj4gPj4KPiA+PiBTbyBhIHJlYWwg YWN0dWFsIGRlYmF0YWJsZSBpc3N1ZSBpcyB3aGV0aGVyIG9yIG5vdCBpdCBpcyByZWFzb25hYmxl Cj4gPj4gdG8gcmVxdWlyZSBhIE5FVENPTkYgY2xpZW50IGFwcGxpY2F0aW9uIHRvIG1ha2Ugc3Vy ZSB0aGlzIHNlcXVlbmNlCj4gPj4gaXMgbm90IHNlbnQgaW4gYW4gWE1MIGRvY3VtZW50LiAgSWYg c28sIHRoZW4gdGhlIGN1cnJlbnQgNDc0MmJpcyBzb2x1dGlvbgo+ID4+IGlzIGZpbmUgYW5kIG5v IGNoYW5nZXMgYXJlIG5lZWRlZCB0byBhbnl0aGluZy4KPiA+Pgo+ID4+IElmIGl0IGlzIG5vdCBy ZWFzb25hYmxlIHRvIHJlcXVpcmUgYSBjbGllbnQgdG8gY2hlY2sgZm9yIF1dPl1dPgo+ID4+IGFu ZCBlc2NhcGUgaXQgKGUuZy4sIGNoYW5nZT4gIHRvJmd0OyksIHRoZW4gYSBuZXcgZnJhbWluZyBt ZWNoYW5pc20KPiA+PiBpcyBuZWVkZWQuCj4gPj4KPiA+PiBJbiB0aGF0IGNhc2UsIGEgbmV3IGZy YW1pbmcgbWVjaGFuaXNtIGlzIG5lZWRlZC4KPiA+PiBJZiBhbnkgY2hhcmFjdGVyIHNlcXVlbmNl IHdoYXRzb2V2ZXIgaXMgdXNlZCB3aXRoaW4gdGhlIGNvbnRlbnQsCj4gPj4gdGhlbiB0aGUgY2xp ZW50IG11c3QgaW1wbGVtZW50IGl0IGNvcnJlY3RseS4KPiA+PiBJTU8sIGl0IGlzIGEgcHVyaXN0 J3MgYXJndW1lbnQgdG8gc2F5IHRoYXQgYSBjbGllbnQgbXVzdCBub3QKPiA+PiBuZWVkIHRvIGNo ZWNrIGZvciBvdGhlcndpc2UgbGVnYWwgWE1MLiAgVGhlIGNsaWVudCBtdXN0IGVzY2FwZQo+ID4+ IHRoZSBtYWdpYyBtYXJrZXIgbm8gbWF0dGVyIHdoYXQgaXQgaXMuICBTb2x1dGlvbnMgd2hpY2gg cmVxdWlyZQo+ID4+IHRoZSBjbGllbnQgdG8gc2VuZCBzb21lIGV4YWN0IFhNTCBmcmFnbWVudCBh cmUgZmxhd2VkLCBiZWNhdXNlCj4gPj4gZnJvbSBhIHB1cmlzdCBQT1Ygd2UgY2Fubm90IHJlc3Ry aWN0IHZhbGlkIFhNTCBpbiBhbnkgd2F5IGF0IGFsbC4KPiA+PiBBIG1hZ2ljIFBJIG9yIGNvbW1l bnQgY2Fubm90IGJlIHVzZWQgYmVjYXVzZSBpdCBpcyBsZWdhbCBmb3IKPiA+PiBhIDQ3NDEgY2xp ZW50IHRvIHNlbmQgdGhlbSwgYW5kIGlmIGEgNDc0MWJpcyBzZXJ2ZXIgbWlzaW50ZXJwcmV0cwo+ ID4+IHRoZSBzZXF1ZW5jZSwgdGhlIHdyb25nIE5FVENPTkYgdmVyc2lvbiB3aWxsIGJlIHVzZWQu Cj4gPj4KPiA+PiBXYXkgZG93biB0aGUgbGlzdCwgYWZ0ZXIgYSBuZXcgZnJhbWluZyBtZWNoYW5p c20gaXMgcGlja2VkLCB0aGVyZSBpcyB0aGUKPiA+PiBpc3N1ZSBvZiBjb2V4aXN0ZW5jZSB3aXRo IG9sZCBzZXJ2ZXJzLiAgVGhlbiBhIG5ldyBkZWJhdGFibGUgaXNzdWUgZXhpc3RzLAo+ID4+IG9u IGhvdyB0byBkbyB0aGlzLiAgT25lIGFwcHJvYWNoIGlzIHRvIHVzZSBhIG5ldyBzdWJzeXN0ZW0g YW5kIGFub3RoZXIKPiA+PiBpcyB0byB1c2UgYSBtYWdpYyBQSSBvciBYTUwgY29tbWVudCBiZWZv cmUgdGhlPGhlbGxvPi4gIFRoZSBiYXNlOjEuMQo+ID4+IGNhcGFiaWxpdHkgaW4gdGhlPGhlbGxv PiAgY291bGQgYWxzbyBiZSB1c2VkLiAgVXNpbmcgdGhlIHNhbWUgc3Vic3lzdGVtCj4gPj4gbWVh bnMgdGhlIG9sZCBtZXNzYWdlIGZyYW1pbmcgaXMgdXNlZCBmb3IgdGhlIGZpcnN0IG1lc3NhZ2Us IGJ1dCBtYXliZQo+ID4+IG5vdCB1c2VkIGFmdGVyIHRoYXQsIGRlcGVuZGluZyBvbiBpZiBib3Ro IHNpZGVzIGFncmVlIHRvIHVzZSBiYXNlOjEuMSBvciBub3QuCj4gPj4KPiA+PiBVc2luZyB0aGUg b2xkIGZyYW1pbmcgYXQgYWxsIGluIHRoZSBwcm90b2NvbCBtZWFucyBhIGhhY2tlciBjYW4gc3Rp bGwKPiA+PiBpbmplY3QgbWVzc2FnZXMganVzdCB0aGUgc2FtZSBhcyBub3csIGV4Y2VwdCBvbmx5 IGZvciB0aGUgZmlyc3QgbWVzc2FnZSwKPiA+PiBpbnN0ZWFkIG9mIGFueSBtZXNzYWdlLgo+ID4+ Cj4gPj4gU28gdGhlcmUgaXMgYSBkZWJhdGUgd2hldGhlciB1c2luZyBhIG5ldyBzdWJzeXN0ZW0g KGUuZy4gbmV0Y29uZi1lb20pCj4gPj4gaXMgdG9vIG11Y2ggYnVyZGVuIG9yIG5vdC4gIElNTywg dGhpcyBpcyB0aGUgc2FmZXN0IGFuZCBjbGVhbmVzdCB3YXkKPiA+PiB0byBzdXBwb3J0IGJvdGgg NDc0MSBhbmQgNDc0MWJpcyBzZXJ2ZXJzLiAgQSBuZXcgY2xpZW50IHdvdWxkIGZpcnN0IHRyeQo+ ID4+IG5ldGNvbmYtZW9tIGFuZCB0aGVuIG5ldGNvbmYgaWYgdGhhdCBkaWQgbm90IHdvcmsuICBP dmVyIHRpbWUsIHRoZXJlCj4gPj4gd2lsbCBsaWtlbHkgYmUgb25seSBuZXRjb25mLWVvbSBzZXJ2 ZXJzIHNvIHRoZSBjbGllbnQgd2lsbCBuZXZlciBuZWVkCj4gPj4gdG8gdHJ5IHRoZSBvbGQgc3Vi c3lzdGVtLgo+ID4+Cj4gPj4gVXNpbmcgMiBzdWJzeXN0ZW1zIGtlZXBzIHRoZSBwcm9ibGVtIGxv Y2FsaXplZCB0byB0aGUgdHJhbnNwb3J0IGxheWVyIGNvZGUuCj4gPj4gVGhlcmUgYXJlIG5vIG5l dyBzcGVjaWFsIGludGVyYWN0aW9ucyBiZXR3ZWVuIHRoZSBtZXNzYWdlIGFuZCB0cmFuc3BvcnQg Y29kZSBuZWVkZWQuCj4gPj4gVGhlcmUgYXJlIG5vIGJ1ZmZlcmluZyByZXF1aXJlbWVudHMgZm9y IHRoZSB0cmFuc3BvcnQsIHdhaXRpbmcgdG8gYmUgdG9sZAo+ID4+IHdoaWNoIHRyYW5zcG9ydCBm cmFtaW5nIG1lY2hhbmlzbSBoYXMgYmVlbiBuZWdvdGlhdGVkIGluIHRoZSBvcGVyYXRpb25zIGxh eWVyLgo+ID4+IEl0IGlzIGFsc28gdmVyeSBjbGVhciB0byBpbXBsZW1lbnRvcnMgd2hhdCB0byBk byBiZWNhdXNlIFNTSCBpcyBiZWluZyB1c2VkIGFzIGRlc2lnbmVkLgo+ID4+IFVzaW5nIGEgbWFn aWMgUEkgb3IgY29tbWVudCB3b3VsZCBiZSBhIGhhY2sgdGhhdCBwZW9wbGUgd2hvIGtub3cgU1NI IG1heSBub3QgZXhwZWN0Lgo+ID4+Cj4gPj4KPiA+PiBBbmR5Cj4gPj4KPiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4+IE5ldGNvbmYgbWFpbGlu ZyBsaXN0Cj4gPj4gTmV0Y29uZkBpZXRmLm9yZwo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZgo+ID4KPiAKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05F VApQR1AgS2V5IElEOiBFNzRFOEMwQwoKCg== ------=_Part_0_1289543059832 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5XZSBhcmUgaW1wbGVtZW50aW5nIG5ldGNvbmYsIG5vdCBYTUwgcGFyc2VycyB0 aGF0IHNlbmQgZWFjaCBvdGhlciBtZXNzYWdlcy4gJm5ic3A7QSBjb25mb3JtYW50IDQ4NDJiaXMg aW1wbGVtZW50YXRpb24gaXMgbm90IGFsbG93ZWQgdG8gc2VuZCB0aGlzIHN0cmluZywgc28gb25s eSBhIGJ1Z2d5IGNsaWVudCBoYXMgdGhpcyBwcm9ibGVtLjxicj48YnI+SWYgd2UgdXNlZCAweDQg aW5zdGVhZCBvZiB0aGUgY3VycmVudCBlb20gdGhlbiBhIGJ1Z2d5IGNsaWVudCBjYW4gY2F1c2Ug dGhpcyBleGFjdCBwcm9ibGVtIGluIHRoZSBzZXJ2ZXIuPGJyPjxicj5JTU8sIHdlIGFyZSBkZWJh dGluZyBtZWFuaW5nbGVzcyBjb25qZWN0dXJlIHdoZW4gd2UgdGFsayBhYm91dCB3aGljaCBidWdz IGFyZSBnb2luZyB0byBoYXBwZW4gaW4gdGhlIGZ1dHVyZS4gJm5ic3A7PGJyPjxicj40NzQyYmlz IHNheXMgd2hhdCBhIGNsaWVudCBtdXN0IGRvLjxicj5BIGNsaWVudCB0aGF0IGltcGxlbWVudHMg dGhlIHNwZWMgY29ycmVjdGx5IGRvZXNuJiMzOTt0IGhhdmUgYSBwcm9ibGVtLjxicj48YnI+PGJy PkFuZHkgPGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0xh ZGlzbGF2IExob3RrYSZxdW90OyAmbHQ7bGhvdGthQGNlc25ldC5jeiZndDs8YnI+RGF0ZTogRnJp LCBOb3YgMTIsIDIwMTAgMTM6MDA8YnI+U3ViamVjdDogW05ldGNvbmZdIEJyZWFrb3V0IHJvb20g RGlhbW9uZCAxIC0gZm9yIEVPTSBkaXNjdXNzaW9uIHRvZGF5LCA1cG0gQmVpamluZyB0aW1lLjxi cj5UbzogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDtpZXRmQGFuZHliaWVybWFuLmNvbSZn dDs8YnI+Q2M6ICZxdW90O0JlcnQgKElFVEYpIFdpam5lbiZxdW90OyAmbHQ7YmVydGlldGZAYndp am5lbi5uZXQmZ3Q7LCAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+PGJyPjxicj5PbiDEjHQs IDIwMTAtMTEtMTEgYXQgMTc6NTggLTA4MDAsIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+Jmd0OyBP biAxMS8xMS8yMDEwIDA1OjM0IFBNLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6PGJyPiZndDsgJmd0 OyBPbiDEjHQsIDIwMTAtMTEtMTEgYXQgMTU6NTMgLTA4MDAsIEFuZHkgQmllcm1hbiB3cm90ZTo8 YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSGVyZSBhcmUgdGhlIGlzc3VlcyB0aGF0IEkg aGF2ZSB3aXRoIHRoaXMgZW50aXJlIGRpc2N1c3Npb246PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0OyBXaGF0IGFyZSB3ZSBmaXhpbmc/IHdoYXQgcHJvYmxlbSBhcmUgd2UgdHJ5aW5n IHRvIHNvbHZlPzxicj4mZ3Q7ICZndDsmZ3Q7IFBlb3BsZSBza2lwIG92ZXIgdGhpcyBwYXJ0IGFz IGlmIGl0IHdlcmUgaXJyZWxldmFudCwgYnV0IHRvIG1lPGJyPiZndDsgJmd0OyZndDsgdGhlIHNv bHV0aW9ucyBhcmUgaXJyZWxldmFudCBpZiB3ZSBjYW5ub3QgYWdyZWUgb24gdGhlIHByb2JsZW0u PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgSSBiZWxpZXZlIHdoYXQgd2UgYXJlIGZpeGluZyBp cyBhIHNlY3VyaXR5IGhvbGUuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsgSXQgc2VlbXMgdGhlIHByb2JsZW0gaXMgdGhhdCBYTUwgYWxsb3dzIF1dJmd0O11d Jmd0OyAmbmJzcDt0byBhcHBlYXIgaW48YnI+Jmd0OyAmZ3Q7Jmd0OyBhbiBYTUwgZG9jdW1lbnQs IGJ1dCBORVRDT05GIGRvZXMgbm90IGFsbG93IGl0LiAmbmJzcDtUaGUgY3VycmVudDxicj4mZ3Q7 ICZndDsmZ3Q7IDQ3NDJiaXMgdGV4dCBzYXlzIHNvLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 IFRoaXMgaXMgYWxzbyBxdWl0ZSB1bnN5c3RlbWF0aWMuIEEgdHJhbnNwb3J0IGxheWVyIHNwZWMg c2hvdWxkIG5vdCBzdGF0ZTxicj4mZ3Q7ICZndDsgcnVsZXMgY29uY2VybmluZyBtZXNzYWdlIGNv bnRlbnRzLiBEb2VzIGl0IG1lYW4gdGhhdCBJIGNhbiB1c2UgJnF1b3Q7XV0mZ3Q7XV0mZ3Q7JnF1 b3Q7PGJyPiZndDsgJmd0OyB3aGVuIHVzaW5nIFRMUyBidXQgbm90IHdoZW4gdXNpbmcgU1NIPzxi cj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IE9uIGEgcHJhY3RpY2FsIHNpZGUsIFhNTCB3ZWxsLWZv cm1lZG5lc3MgY2FuIGJlIGNoZWNrZWQgd2l0aDxicj4mZ3Q7ICZndDsgb2ZmLXRoZS1zaGVsZiB0 b29scyB3aGlsZSB0aGUgc2VhcmNoIGZvciAmcXVvdDtdXSZndDtdXSZndDsmcXVvdDsgcmVxdWly ZXMgYSBzcGVjaWFsPGJyPiZndDsgJmd0OyBpbXBsZW1lbnRhdGlvbi48YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgPGJyPiZndDsgTGV0JiMzOTtzIGRvIGEgbGl0dGxlIHJlYWxpdHkgY2hlY2suLi48YnI+ Jmd0OyBXZSBhcmUgbm90IHJlYWxseSBjb25jZXJuZWQgd2l0aCBYTUwgYXR0cmlidXRlcyBpbiBO RVRDT05GIGNvbnRlbnQ8YnI+Jmd0OyBiZWNhdXNlIHdlIGFyZSBzdGFuZGFyZGl6aW5nIG9uIFlB TkcsIGFuZCBZQU5HIGRvZXMgbm90IGFsbG93IHRoZW0uPGJyPiZndDsgVGhlcmUgaXMgb25seSAx IHBsYWNlIGluIHRoZSBlbnRpcmUgcHJvdG9jb2wgd2hlcmUgYSBjbGllbnQgY291bGQ8YnI+Jmd0 OyBwb3NzaWJseSBwcm92aWRlIGFuIFhNTCBhdHRyaWJ1dGUgYW5kIHRoYXQgaXMgaW4gdGhlICZs dDtycGMmZ3Q7IGVsZW1lbnQuPGJyPiZndDsgPGJyPiZndDsgVGhlcmUgYXJlIG5vIGltcGxlbWVu dGF0aW9ucyBhdCBhbGwgdGhhdCBhbGxvdyB0aGUgdXNlciB0byBzcGVjaWZ5PGJyPiZndDsgWE1M IGF0dHJpYnV0ZXMgdG8gYWRkIHRvICZsdDtycGMmZ3Q7IGFuZCBJIGRvdWJ0IHRoaXMgd2lsbCBl dmVyIGhhcHBlbiBiZWNhdXNlPGJyPiZndDsgaXQgc2VydmVzIG5vIHVzZSBjYXNlIGF0IGFsbC4g Jm5ic3A7VGhpcyBORVRDT05GIGZlYXR1cmUgaXMgZm9yIHRoZSBjbGllbnQ8YnI+Jmd0OyBpbXBs ZW1lbnRhdGlvbi4gJm5ic3A7SSBkbyBub3Qga25vdyBvZiBhbnkgYXBwbGljYXRpb24gaW1wbGVt ZW50YXRpb24gdGhhdDxicj4mZ3Q7IGFjdHVhbGx5IHVzZXMgaXQgYXQgYWxsLCBsZXQgYWxvbmUg cHJvdmlkZXMgYSB1c2VyIEFQSSB0byBzZXQgdGhlc2UgYXR0cmlidXRlcy48YnI+PGJyPkZvciBh IGNyYWNrZXIsIHRoZSBlYXNpZXN0IHdheSBpcyB0byB0cnkgdG8gc211Z2dsZSBhbiBYTUwgY29t bWVudCBsaWtlPGJyPnRoaXMgdG8gX2FueV8gcGxhY2Ugb2YgdGhlIFhNTCBkb2N1bWVudDo8YnI+ PGJyPiZsdDshLS0gXV0mZ3Q7XV0mZ3Q7Jmx0O3JwYyBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90 OyB4bWxucz0mcXVvdDsuLi4mcXVvdDsmZ3Q7Li4uJmx0Oy9ycGMmZ3Q7IC0tJmd0Ozxicj48YnI+ VGhpcyBpcyBhIHBlcmZlY3RseSB2YWxpZCBYTUwsIGFueSBwYXJzZXIgd2lsbCBiZSBoYXBweSB0 byBjb21wbGV0ZWx5PGJyPmlnbm9yZSB0aGUgY29tbWVudC4gSWYgdGhpcyBpcyBub3QgYSBodWdl IHNlY3VyaXR5IGhvbGUsIHRoZW4gSSBkb24mIzM5O3Q8YnI+a25vdyB3aGF0IGVsc2UgaXMuPGJy Pjxicj5MYWRhIDxicj48YnI+ICZuYnNwOzxicj4mZ3Q7IDxicj4mZ3Q7IFRoZXJlZm9yZSBpdCBz ZWVtcyBxdWl0ZSByZWFzb25hYmxlIHRvIGtlZXAgdGhlIGN1cnJlbnQgNDc0MmJpcyB0ZXh0PGJy PiZndDsgYW5kIHJlcXVpcmUgYSBjbGllbnQgdG8gbWFrZSBzdXJlIF1dJmd0O11dJmd0OyBpcyBu b3Qgc2VudCBpbnNpZGUgYSBORVRDT05GIG1lc3NhZ2UuPGJyPiZndDsgSW4gdGhlb3J5IFhNTCBh bGxvd3MgaW4gaW4gYSBQSSBvciBYTUwgYXR0cmlidXRlLiAmbmJzcDtJbiByZWFsaXR5LCBORVRD T05GPGJyPiZndDsgZG9lcyBub3QgdXNlIHRoZXNlIFhNTCBmZWF0dXJlcyBzbyBhIGNsaWVudCBz aG91bGQgbm90IGV2ZXIgbmVlZCB0byBzZW5kIHRoZW0uPGJyPiZndDsgPGJyPiZndDsgPGJyPiZn dDsgQW5keTxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgTGFkYTxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFNvIGEgcmVhbCBhY3R1YWwgZGViYXRhYmxlIGlzc3Vl IGlzIHdoZXRoZXIgb3Igbm90IGl0IGlzIHJlYXNvbmFibGU8YnI+Jmd0OyAmZ3Q7Jmd0OyB0byBy ZXF1aXJlIGEgTkVUQ09ORiBjbGllbnQgYXBwbGljYXRpb24gdG8gbWFrZSBzdXJlIHRoaXMgc2Vx dWVuY2U8YnI+Jmd0OyAmZ3Q7Jmd0OyBpcyBub3Qgc2VudCBpbiBhbiBYTUwgZG9jdW1lbnQuICZu YnNwO0lmIHNvLCB0aGVuIHRoZSBjdXJyZW50IDQ3NDJiaXMgc29sdXRpb248YnI+Jmd0OyAmZ3Q7 Jmd0OyBpcyBmaW5lIGFuZCBubyBjaGFuZ2VzIGFyZSBuZWVkZWQgdG8gYW55dGhpbmcuPGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBJZiBpdCBpcyBub3QgcmVhc29uYWJsZSB0byBy ZXF1aXJlIGEgY2xpZW50IHRvIGNoZWNrIGZvciBdXSZndDtdXSZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyBhbmQgZXNjYXBlIGl0IChlLmcuLCBjaGFuZ2UmZ3Q7ICZuYnNwO3RvJmFtcDtndDspLCB0aGVu IGEgbmV3IGZyYW1pbmcgbWVjaGFuaXNtPGJyPiZndDsgJmd0OyZndDsgaXMgbmVlZGVkLjxicj4m Z3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSW4gdGhhdCBjYXNlLCBhIG5ldyBmcmFtaW5n IG1lY2hhbmlzbSBpcyBuZWVkZWQuPGJyPiZndDsgJmd0OyZndDsgSWYgYW55IGNoYXJhY3RlciBz ZXF1ZW5jZSB3aGF0c29ldmVyIGlzIHVzZWQgd2l0aGluIHRoZSBjb250ZW50LDxicj4mZ3Q7ICZn dDsmZ3Q7IHRoZW4gdGhlIGNsaWVudCBtdXN0IGltcGxlbWVudCBpdCBjb3JyZWN0bHkuPGJyPiZn dDsgJmd0OyZndDsgSU1PLCBpdCBpcyBhIHB1cmlzdCYjMzk7cyBhcmd1bWVudCB0byBzYXkgdGhh dCBhIGNsaWVudCBtdXN0IG5vdDxicj4mZ3Q7ICZndDsmZ3Q7IG5lZWQgdG8gY2hlY2sgZm9yIG90 aGVyd2lzZSBsZWdhbCBYTUwuICZuYnNwO1RoZSBjbGllbnQgbXVzdCBlc2NhcGU8YnI+Jmd0OyAm Z3Q7Jmd0OyB0aGUgbWFnaWMgbWFya2VyIG5vIG1hdHRlciB3aGF0IGl0IGlzLiAmbmJzcDtTb2x1 dGlvbnMgd2hpY2ggcmVxdWlyZTxicj4mZ3Q7ICZndDsmZ3Q7IHRoZSBjbGllbnQgdG8gc2VuZCBz b21lIGV4YWN0IFhNTCBmcmFnbWVudCBhcmUgZmxhd2VkLCBiZWNhdXNlPGJyPiZndDsgJmd0OyZn dDsgZnJvbSBhIHB1cmlzdCBQT1Ygd2UgY2Fubm90IHJlc3RyaWN0IHZhbGlkIFhNTCBpbiBhbnkg d2F5IGF0IGFsbC48YnI+Jmd0OyAmZ3Q7Jmd0OyBBIG1hZ2ljIFBJIG9yIGNvbW1lbnQgY2Fubm90 IGJlIHVzZWQgYmVjYXVzZSBpdCBpcyBsZWdhbCBmb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyBhIDQ3NDEg Y2xpZW50IHRvIHNlbmQgdGhlbSwgYW5kIGlmIGEgNDc0MWJpcyBzZXJ2ZXIgbWlzaW50ZXJwcmV0 czxicj4mZ3Q7ICZndDsmZ3Q7IHRoZSBzZXF1ZW5jZSwgdGhlIHdyb25nIE5FVENPTkYgdmVyc2lv biB3aWxsIGJlIHVzZWQuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBXYXkgZG93 biB0aGUgbGlzdCwgYWZ0ZXIgYSBuZXcgZnJhbWluZyBtZWNoYW5pc20gaXMgcGlja2VkLCB0aGVy ZSBpcyB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyBpc3N1ZSBvZiBjb2V4aXN0ZW5jZSB3aXRoIG9sZCBz ZXJ2ZXJzLiAmbmJzcDtUaGVuIGEgbmV3IGRlYmF0YWJsZSBpc3N1ZSBleGlzdHMsPGJyPiZndDsg Jmd0OyZndDsgb24gaG93IHRvIGRvIHRoaXMuICZuYnNwO09uZSBhcHByb2FjaCBpcyB0byB1c2Ug YSBuZXcgc3Vic3lzdGVtIGFuZCBhbm90aGVyPGJyPiZndDsgJmd0OyZndDsgaXMgdG8gdXNlIGEg bWFnaWMgUEkgb3IgWE1MIGNvbW1lbnQgYmVmb3JlIHRoZSZsdDtoZWxsbyZndDsuICZuYnNwO1Ro ZSBiYXNlOjEuMTxicj4mZ3Q7ICZndDsmZ3Q7IGNhcGFiaWxpdHkgaW4gdGhlJmx0O2hlbGxvJmd0 OyAmbmJzcDtjb3VsZCBhbHNvIGJlIHVzZWQuICZuYnNwO1VzaW5nIHRoZSBzYW1lIHN1YnN5c3Rl bTxicj4mZ3Q7ICZndDsmZ3Q7IG1lYW5zIHRoZSBvbGQgbWVzc2FnZSBmcmFtaW5nIGlzIHVzZWQg Zm9yIHRoZSBmaXJzdCBtZXNzYWdlLCBidXQgbWF5YmU8YnI+Jmd0OyAmZ3Q7Jmd0OyBub3QgdXNl ZCBhZnRlciB0aGF0LCBkZXBlbmRpbmcgb24gaWYgYm90aCBzaWRlcyBhZ3JlZSB0byB1c2UgYmFz ZToxLjEgb3Igbm90Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgVXNpbmcgdGhl IG9sZCBmcmFtaW5nIGF0IGFsbCBpbiB0aGUgcHJvdG9jb2wgbWVhbnMgYSBoYWNrZXIgY2FuIHN0 aWxsPGJyPiZndDsgJmd0OyZndDsgaW5qZWN0IG1lc3NhZ2VzIGp1c3QgdGhlIHNhbWUgYXMgbm93 LCBleGNlcHQgb25seSBmb3IgdGhlIGZpcnN0IG1lc3NhZ2UsPGJyPiZndDsgJmd0OyZndDsgaW5z dGVhZCBvZiBhbnkgbWVzc2FnZS48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFNv IHRoZXJlIGlzIGEgZGViYXRlIHdoZXRoZXIgdXNpbmcgYSBuZXcgc3Vic3lzdGVtIChlLmcuIG5l dGNvbmYtZW9tKTxicj4mZ3Q7ICZndDsmZ3Q7IGlzIHRvbyBtdWNoIGJ1cmRlbiBvciBub3QuICZu YnNwO0lNTywgdGhpcyBpcyB0aGUgc2FmZXN0IGFuZCBjbGVhbmVzdCB3YXk8YnI+Jmd0OyAmZ3Q7 Jmd0OyB0byBzdXBwb3J0IGJvdGggNDc0MSBhbmQgNDc0MWJpcyBzZXJ2ZXJzLiAmbmJzcDtBIG5l dyBjbGllbnQgd291bGQgZmlyc3QgdHJ5PGJyPiZndDsgJmd0OyZndDsgbmV0Y29uZi1lb20gYW5k IHRoZW4gbmV0Y29uZiBpZiB0aGF0IGRpZCBub3Qgd29yay4gJm5ic3A7T3ZlciB0aW1lLCB0aGVy ZTxicj4mZ3Q7ICZndDsmZ3Q7IHdpbGwgbGlrZWx5IGJlIG9ubHkgbmV0Y29uZi1lb20gc2VydmVy cyBzbyB0aGUgY2xpZW50IHdpbGwgbmV2ZXIgbmVlZDxicj4mZ3Q7ICZndDsmZ3Q7IHRvIHRyeSB0 aGUgb2xkIHN1YnN5c3RlbS48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFVzaW5n IDIgc3Vic3lzdGVtcyBrZWVwcyB0aGUgcHJvYmxlbSBsb2NhbGl6ZWQgdG8gdGhlIHRyYW5zcG9y dCBsYXllciBjb2RlLjxicj4mZ3Q7ICZndDsmZ3Q7IFRoZXJlIGFyZSBubyBuZXcgc3BlY2lhbCBp bnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgbWVzc2FnZSBhbmQgdHJhbnNwb3J0IGNvZGUgbmVlZGVk Ljxicj4mZ3Q7ICZndDsmZ3Q7IFRoZXJlIGFyZSBubyBidWZmZXJpbmcgcmVxdWlyZW1lbnRzIGZv ciB0aGUgdHJhbnNwb3J0LCB3YWl0aW5nIHRvIGJlIHRvbGQ8YnI+Jmd0OyAmZ3Q7Jmd0OyB3aGlj aCB0cmFuc3BvcnQgZnJhbWluZyBtZWNoYW5pc20gaGFzIGJlZW4gbmVnb3RpYXRlZCBpbiB0aGUg b3BlcmF0aW9ucyBsYXllci48YnI+Jmd0OyAmZ3Q7Jmd0OyBJdCBpcyBhbHNvIHZlcnkgY2xlYXIg dG8gaW1wbGVtZW50b3JzIHdoYXQgdG8gZG8gYmVjYXVzZSBTU0ggaXMgYmVpbmcgdXNlZCBhcyBk ZXNpZ25lZC48YnI+Jmd0OyAmZ3Q7Jmd0OyBVc2luZyBhIG1hZ2ljIFBJIG9yIGNvbW1lbnQgd291 bGQgYmUgYSBoYWNrIHRoYXQgcGVvcGxlIHdobyBrbm93IFNTSCBtYXkgbm90IGV4cGVjdC48YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgQW5keTxicj4m Z3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlz dDxicj4mZ3Q7ICZndDsmZ3Q7IE5ldGNvbmZAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+Jmd0OyAmZ3Q7 PGJyPiZndDsgPGJyPjxicj4tLSA8YnI+TGFkaXNsYXYgTGhvdGthLCBDRVNORVQ8YnI+UEdQIEtl eSBJRDogRTc0RThDMEM8YnI+PGJyPjxicj48YnI+PGJyPg== ------=_Part_0_1289543059832-- From phil@juniper.net Fri Nov 12 05:47: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 B767A3A697A for ; Fri, 12 Nov 2010 05:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8x2=0.246] 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 ToTLwt52j7vO for ; Fri, 12 Nov 2010 05:47:07 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 019C33A68C1 for ; Fri, 12 Nov 2010 05:47:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTN1Fdmnl7QR4GKjPGIXeO1mGhYnl0zMl@postini.com; Fri, 12 Nov 2010 05:47:37 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Nov 2010 05:45:21 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oACDjKU44241; Fri, 12 Nov 2010 05:45:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oACDO3vu008250; Fri, 12 Nov 2010 13:24:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011121324.oACDO3vu008250@idle.juniper.net> To: =?utf-8?B?QW5keSBCaWVybWFu?= In-Reply-To: <90.ED.30981.88DDCDC4@cm-omr12> Date: Fri, 12 Nov 2010 08:24:03 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?Breakout_room_Diamond_1_-_for_EOM_discussion_?= =?utf-8?q?today=2C_5pm_Beijing_time=2E?= 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, 12 Nov 2010 13:47:07 -0000 "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >4742bis says what a client must do. >A client that implements the spec correctly doesn't have a problem. s/4742bis/The new 4742bis/ s/the spec/the new spec/ So the question is if we are fixing the problem via a new spec, why not fix it in a simpler, more straight-forward way that doesn't involve making valid content illegal and that allows us to deprecate this annoying multi-byte EOM marker? Thanks, Phil From phil@juniper.net Fri Nov 12 05:56:18 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 BE44C3A6A06 for ; Fri, 12 Nov 2010 05:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 mNM4U3kT5rcU for ; Fri, 12 Nov 2010 05:56:18 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 30B483A6886 for ; Fri, 12 Nov 2010 05:56:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTN1HoEPbUgL8oJ2huV8CQMueHwoagObs@postini.com; Fri, 12 Nov 2010 05:56:51 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 12 Nov 2010 05:55:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oACDtDU48114; Fri, 12 Nov 2010 05:55:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oACDXuk3008395; Fri, 12 Nov 2010 13:33:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011121333.oACDXuk3008395@idle.juniper.net> To: Andy Bierman Date: Fri, 12 Nov 2010 08:33:56 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm ***Beijing time. 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, 12 Nov 2010 13:56:18 -0000 Andy Bierman writes: >We are not really concerned with XML attributes in NETCONF content >because we are standardizing on YANG, and YANG does not allow them. YANG is a modeling language for NETCONF, but that doesn't mean that suddenly all NETCONF traffic must abide by YANG's rules. >There is only 1 place in the entire protocol where a client could >possibly provide an XML attribute and that is in the element. This is not correct. The "value" and "key" attributes contain text matching user-defined data. Are you wanting to add a new restriction saying one can't make data values that contain our secret EOM marker? There's also "anyxml", which I guess we could define in -bis as "any xml except our EOM marker". Thanks, Phil From ietf@andybierman.com Fri Nov 12 20:04: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 D29123A6927 for ; Fri, 12 Nov 2010 20:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 ZeWuZCv+Mvo2 for ; Fri, 12 Nov 2010 20:04:49 -0800 (PST) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id C9FE23A6903 for ; Fri, 12 Nov 2010 20:04:48 -0800 (PST) Received: (qmail 93013 invoked from network); 13 Nov 2010 04:05:19 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 12 Nov 2010 20:05:16 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: PlBT.6gVM1lytLxEfUaYWNK4.BxTeMcu8g38g_LN9NDX7C2 PYagOW3vhtFAcgxrU9LFoHDVvZ9WTo7KfDyRGMFFctaLaeC.Cn_CyvYXVgu5 z99NbILbh8KSgBDZN5VWQjOwpX_KPPJWaoMAyqAfAkcHNxqjMIdknCiPKjPH bMwpQz7uZwv76XdTEctfyeinOjRPmdy3u1U50YqGrqkdR.lYQ80Lh1q3o46e 1BKoppF8Eu78xlEmMZeqxSbSw.StKWPCJ5UzaJS0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDE0E7B.6060107@andybierman.com> Date: Fri, 12 Nov 2010 20:05:15 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Phil Shafer References: <201011121324.oACDO3vu008250@idle.juniper.net> In-Reply-To: <201011121324.oACDO3vu008250@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 04:04:50 -0000 On 11/12/2010 05:24 AM, Phil Shafer wrote: > "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >> 4742bis says what a client must do. >> A client that implements the spec correctly doesn't have a problem. > > s/4742bis/The new 4742bis/ > s/the spec/the new spec/ > actually the 4742bis draft is technically done and off the WG plate. > So the question is if we are fixing the problem via a new spec, why > not fix it in a simpler, more straight-forward way that doesn't > involve making valid content illegal and that allows us to deprecate > this annoying multi-byte EOM marker? > So the problem is that the EOM has too many bytes? The fact that we were told to use the wrong char sequence for 4741 is annoying. Too bad Lada wasn't on the XML Directorate then. Oh well. If only we had 0x4 from the start. All the solutions suck, so we are trying to pick the least suckiest solution. IMO the least suckiest is to force NETCONF peers to encode ]]>]]> in some other way if it is part of the message content. For example, the yuma code will always generate > instead of >, even for attribute content. No user data can make it into a comment. No PIs are ever used at all. Problem solved. Libxml2 takes care of character entity replacement at the receiving end. The user data at both ends contains >, but the bytes on the wire do not. I really want to avoid a huge non-backward compatible change for 1.1. I have a long list of features I want to add to NETCONF. If we are making this a major release, then we should rewrite the charter. > Thanks, > Phil > > Andy From ietf@andybierman.com Fri Nov 12 21:10: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 DF47A3A691C for ; Fri, 12 Nov 2010 21:10:34 -0800 (PST) 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=[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 LU9pnJ0SyeVI for ; Fri, 12 Nov 2010 21:10:27 -0800 (PST) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id C23C33A6A73 for ; Fri, 12 Nov 2010 21:10:27 -0800 (PST) Received: (qmail 35675 invoked from network); 13 Nov 2010 05:10:51 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 12 Nov 2010 21:10:48 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: jXVigSoVM1k5McgYvMMDACUUPkuzMSTuU.dILSr9eTbWTU_ yHKOXMsQmbf7xVsz_zzSQZKEgoPjEIktFOSjvfHP8OHrm4gp37UwTwNxQXOQ YexwV_pqr1T_Gxe3x19wOodjrYShGoCaw.xX6lfFZOVXc2qLiLh8_g5KhISx UzZRi9Sksd7bEx1kK4_6CM0G3mNUCeLkCvEtfhiChSQ.xrp2mYHQB9Ce6ZrQ NWumN6BTHiD5MBN8maVr5aVXp4WJZh2RdJL_4EEcPynZrh6PsF1uKsXOKn.K ZPqsDJM2Og2Clw_2oYiI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDE1DD8.3080609@andybierman.com> Date: Fri, 12 Nov 2010 21:10:48 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Phil Shafer References: <201011121324.oACDO3vu008250@idle.juniper.net> <4CDE0E7B.6060107@andybierman.com> In-Reply-To: <4CDE0E7B.6060107@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 05:10:35 -0000 On 11/12/2010 08:05 PM, Andy Bierman wrote: I take back what I said about wish 0x4 was here from the start. From the data-injection-attack POV, 0x4, or any magic sequence in the data, are all equally bad. * It doesn't really matter whatsoever if the magic pattern is not allowed to appear in valid XML. * The magic pattern will never will appear in any XML document on a server that implements SSH message-chopping correctly. That's the point Wes has been making over and over. * If the client does not check for the magic pattern and escape it, then the data injection attack can succeed. It does not matter what the magic pattern is. * Clients that don't check the user data on input are never going to check it. * No real client sends data through a validating parser. They just serialize data structures, writing directly to the session. Phil, why don't you want to do real framing now? That seems the the most difficult to implement but also the most difficult to hack. It seems like if we were solving the data injection attack problem then using tags outside of the XML stream seems the best choice. Andy > On 11/12/2010 05:24 AM, Phil Shafer wrote: >> "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >>> 4742bis says what a client must do. >>> A client that implements the spec correctly doesn't have a problem. >> >> s/4742bis/The new 4742bis/ >> s/the spec/the new spec/ >> > > actually the 4742bis draft is technically done and off the WG plate. > >> So the question is if we are fixing the problem via a new spec, why >> not fix it in a simpler, more straight-forward way that doesn't >> involve making valid content illegal and that allows us to deprecate >> this annoying multi-byte EOM marker? >> > > So the problem is that the EOM has too many bytes? > The fact that we were told to use the wrong char sequence for 4741 > is annoying. Too bad Lada wasn't on the XML Directorate then. Oh well. > If only we had 0x4 from the start. > > All the solutions suck, so we are trying to pick the least suckiest > solution. > > IMO the least suckiest is to force NETCONF peers to encode ]]>]]> > in some other way if it is part of the message content. > For example, the yuma code will always generate > instead of >, > even for attribute content. No user data can make it into a comment. > No PIs are ever used at all. Problem solved. > > Libxml2 takes care of character entity replacement at the receiving end. > The user data at both ends contains >, but the bytes on the wire do not. > > I really want to avoid a huge non-backward compatible change for 1.1. > > I have a long list of features I want to add to NETCONF. > If we are making this a major release, then we should rewrite the charter. > > > >> Thanks, >> Phil >> >> > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From ietf@andybierman.com Sat Nov 13 14:37: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 978D13A693A for ; Sat, 13 Nov 2010 14:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 WL6qAMO7226J for ; Sat, 13 Nov 2010 14:37:38 -0800 (PST) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id 6637E3A6B4F for ; Sat, 13 Nov 2010 14:37:27 -0800 (PST) Received: (qmail 21860 invoked from network); 13 Nov 2010 22:38:01 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 13 Nov 2010 14:37:57 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: wfa2Ir8VM1nYROHjmtf7TeXUztbOg5ZZSjQkZqqDwno4xzW C3zRDK6ALBrEDwAtW6929nTZopAMqtTTv.5FIP9w2ogZGk8g09WfDtghru8p Z._KeyLaiKH.8R8I0X.DB4E7TXcMzfhTrqp02lUh5hQLKhP5r3YzaWaoJKW7 bHLNUkebvCZ_UnHmhqf84oVayU24t2BYWWxp9I0uJ8N9EVyRu9gQGukLd_Ml GrgrgBNK1jwGogKB0pnF0.2AwIYQ1VqG7lTcnJSuerXWJMNROlt_YHOR98dc kurnOnDomopHGNE4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CDF134A.5090705@andybierman.com> Date: Sat, 13 Nov 2010 14:38:02 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] way forward on netconf EOM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 22:37:40 -0000 Hi, Step 1: Problem It is clear that the WG agrees there is a problem to be solved, which is that the current EOM is permitted in NETCONF messages even though it is used as the SSH and TLS EOM marker. Step 2: Timeframe There seems to be agreement that if we have a good solution now then we should fix this now. I can imagine the IESG sending the document back to the WG until a solution is found. We cannot decide a security hole is not important because we don't agree on a solution. So we have to agree on a solution now. Step 3: Process I can imagine the IESG asking the Security Directorate if the NETCONF message framing problem is fixed or not. We know that changing one magic pattern for another one does not fix the problem. I really think getting help for the Security Directorate (or just listen to Wes ;-) is a good idea. Step 4: Solution It is true that 0x4 is better than ]]>]]>. It makes it harder than before to inject data, but still relies on the client implementing the content layer validation correctly. Consider also the availability of free test tools (e.g., yangcli) that allow arbitrary XML to be easily injected in NETCONF packets for testing purposes. There is absolutely so safe magic pattern if people write tools designed to exploit this protocol bug. (This is why NACM is needed in addition to real framing.) IMO, Phil's framing is the best choice from the security review POV. Step 5: Deployment Assuming a framing method is chosen it has to be deployed. A flag day that breaks all existing 4741 deployments is not possible. In order to keep supporting 4742 framing there needs to be a new subsystem or a hack to switch framing methods after the first message chop. I am now inclined to accept Juergen's solution. I had thought about this before but rejected it as a hack. It is a hack, but it saves an SSH session startup. The key is that each chop is supposed to represent a single XML instance document which means one top-level element. The server is supposed to check for extra top-level elements and reject the message if it is not a valid XML instance document, So it is relatively safe to expect exactly one message followed by the old EOM, then zero or more [ new-eom] pairs. (Of course a hacker could inject followed by the new eom if a different magic pattern is used for the framing solution.) It is also OK to say that a new client SHOULD NOT begin using the session for until it processes the server and determines if base:1.0 or base:1.1 is being used. TCP will make the client wait if the server is not ready to accept messages due to some latency for the message layer to tell the transport layer the framing to use. If base:1.1 then new-eom is set. If base:1.0, then old-eom is set. No magic PIs or comments are needed. Andy From Internet-Drafts@ietf.org Sun Nov 14 18:45:13 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 CFE783A693A; Sun, 14 Nov 2010 18:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 BXhw+jbWtcMK; Sun, 14 Nov 2010 18:45:06 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBDF3A6A38; Sun, 14 Nov 2010 18:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101115024502.501.64179.idtracker@localhost> Date: Sun, 14 Nov 2010 18:45:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-02.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, 15 Nov 2010 02:45:13 -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 Notification Events Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-02.txt Pages : 13 Date : 2010-11-14 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the events within the NETCONF server. This document defines a YANG module which allows a NETCONF client to receive notifications for some common events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-14183215.I-D@ietf.org> --NextPart-- From phil@juniper.net Sun Nov 14 18:49: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 AEDB33A6B4C for ; Sun, 14 Nov 2010 18:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 J6hfiSP44AZF for ; Sun, 14 Nov 2010 18:49:54 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 4C79B3A6BBF for ; Sun, 14 Nov 2010 18:49:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTOCf+eQXCnvUJjpl+jhpfQ6pYibc6qN8@postini.com; Sun, 14 Nov 2010 18:50:34 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 14 Nov 2010 18:49:19 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oAF2nIU60631; Sun, 14 Nov 2010 18:49:18 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oAF2RwhW025546; Mon, 15 Nov 2010 02:27:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011150227.oAF2RwhW025546@idle.juniper.net> To: Andy Bierman In-Reply-To: <4CDE1DD8.3080609@andybierman.com> Date: Sun, 14 Nov 2010 21:27:58 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time. 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, 15 Nov 2010 02:49:54 -0000 Andy Bierman writes: >Phil, why don't you want to do real framing now? Because the WG does not seem to have an interest in it, which is sad. >That seems the the most difficult to implement but also the most difficult to hack. >It seems like if we were solving the data injection attack problem then >using tags outside of the XML stream seems the best choice. Amen. Thanks, Phil From mbj@tail-f.com Mon Nov 15 03:53: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 C579B28B56A for ; Mon, 15 Nov 2010 03:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 5Dcp9O+FAOZE for ; Mon, 15 Nov 2010 03:53:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D5BE23A6C96 for ; Mon, 15 Nov 2010 03:53:44 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AD178616001; Mon, 15 Nov 2010 12:54:24 +0100 (CET) Date: Mon, 15 Nov 2010 12:54:23 +0100 (CET) Message-Id: <20101115.125423.174894940.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4CDF134A.5090705@andybierman.com> References: <4CDF134A.5090705@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 15 Nov 2010 11:53:47 -0000 Andy Bierman wrote: > Hi, > > Step 1: Problem > It is clear that the WG agrees there is a problem to be solved, > which is that the current EOM is permitted in NETCONF messages > even though it is used as the SSH and TLS EOM marker. This is one of the two problems, i.e. legal NETCONF messages can be truncated by this transport protocol. The other problem is the security problem (the injection problem). In the rest of your email, you talk about the injection problem. > Step 2: Timeframe > There seems to be agreement that if we have a good solution now > then we should fix this now. I can imagine the IESG sending the > document back to the WG until a solution is found. We cannot > decide a security hole is not important because we don't agree > on a solution. So we have to agree on a solution now. > > Step 3: Process > I can imagine the IESG asking the Security Directorate if the NETCONF > message framing problem is fixed or not. We know that changing one > magic pattern for another one does not fix the problem. > I really think getting help for the Security Directorate (or just > listen to Wes ;-) is a good idea. > > Step 4: Solution > It is true that 0x4 is better than ]]>]]>. > It makes it harder than before to inject data, but still relies > on the client implementing the content layer validation correctly. > Consider also the availability of free test tools (e.g., yangcli) > that allow arbitrary XML to be easily injected in NETCONF packets > for testing purposes. There is absolutely so safe magic pattern > if people write tools designed to exploit this protocol bug. > (This is why NACM is needed in addition to real framing.) > > IMO, Phil's framing is the best choice from the security review POV. It should be clear by now that Phil's solution does not solve the injection problem. Also note that the injection problem is a problem only when you have a client that authenticates as some user, and then reads input from another user, and inserts the inputted data without doing any checks. > Step 5: Deployment > Assuming a framing method is chosen it has to be deployed. > A flag day that breaks all existing 4741 deployments is not possible. > In order to keep supporting 4742 framing there needs to be a new subsystem > or a hack to switch framing methods after the first message chop. > > I am now inclined to accept Juergen's solution. Juergen's solution to the versioning problem can be used with any of the three "framing" solutions. Did you mean Juergen's solution + 0x04? [...] > If base:1.1 then new-eom is set. If base:1.0, then old-eom is set. > No magic PIs or comments are needed. So you want to tie the base protocol version to the transport version? I would prefer a separate indication (PI, comment, capability, ...). /martin From phil@juniper.net Mon Nov 15 06:12:40 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 F32F53A6CAC for ; Mon, 15 Nov 2010 06:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 2E8bjgMqLAIo for ; Mon, 15 Nov 2010 06:12:33 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id B668E3A68D4 for ; Mon, 15 Nov 2010 06:12:29 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTOE/9/lbLz5W8AJPkO+GQJEv43tjdhYV@postini.com; Mon, 15 Nov 2010 06:13:14 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Nov 2010 06:02:59 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oAFE2wU66539; Mon, 15 Nov 2010 06:02:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oAFDfcE1028905; Mon, 15 Nov 2010 13:41:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011151341.oAFDfcE1028905@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20101115.125423.174894940.mbj@tail-f.com> Date: Mon, 15 Nov 2010 08:41:38 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 15 Nov 2010 14:12:40 -0000 Martin Bjorklund writes: >> IMO, Phil's framing is the best choice from the security review POV. >It should be clear by now that Phil's solution does not solve the >injection problem. I think he's referring to my original suggestion of a real, honest to goodness framing mechanism. http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html Thanks, Phil From mbj@tail-f.com Mon Nov 15 06:38: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 C670928C0EB for ; Mon, 15 Nov 2010 06:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 Dk4vwcMeKZte for ; Mon, 15 Nov 2010 06:38:37 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CC01228C117 for ; Mon, 15 Nov 2010 06:38:36 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2315D616001; Mon, 15 Nov 2010 15:39:17 +0100 (CET) Date: Mon, 15 Nov 2010 15:39:16 +0100 (CET) Message-Id: <20101115.153916.162594769.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201011151341.oAFDfcE1028905@idle.juniper.net> References: <20101115.125423.174894940.mbj@tail-f.com> <201011151341.oAFDfcE1028905@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] way forward on netconf EOM 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, 15 Nov 2010 14:38:43 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >> IMO, Phil's framing is the best choice from the security review POV. > >It should be clear by now that Phil's solution does not solve the > >injection problem. > > I think he's referring to my original suggestion of a real, honest > to goodness framing mechanism. > > http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html > http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html I know. And I referred to: http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html If the attacker can insert something that modifies the current edit-config so that e.g. the password for an admin user is changed, then the attacker can do anything. /martin From ietf@andybierman.com Mon Nov 15 07:46: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 14A773A6CC5 for ; Mon, 15 Nov 2010 07:46:17 -0800 (PST) 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=[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 iXUY+Chwt0D3 for ; Mon, 15 Nov 2010 07:46:10 -0800 (PST) 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 45EB83A6CC8 for ; Mon, 15 Nov 2010 07:46:10 -0800 (PST) Received: (qmail 52422 invoked from network); 15 Nov 2010 15:46:40 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 15 Nov 2010 07:46:37 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: X10sp_gVM1kYJTBj6XQDhfatr3NGjqCIp7AjNYuXrajEArj G7eXmeJwvfY.zBdCR7QE_GrL54Q8kg8UcWjcKjCePIfO3DctMyyCo64gdQuf fjuO8zwiaYuwjqEYk15DX.FD.GDxQXi7rZbDOf3NDup5vtp8KuHEzO7kiRoj ihfYWSP2hfBMf2zHSuwC.YlVz0RixyJFhrw1ZScQb07bVbeeYGIJ7qOA_4mN GcC.FeSLDkCWJA9X.AKejIUD3AXFSN9SDo_g6jf4q6rFdaHbu7hxs2nigxfv XNdY.nulMJEBUOsdzlO2NG4HJbg9zNJUyTZuTHp66VYnNhvLVWS4MviU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CE155ED.1010206@andybierman.com> Date: Mon, 15 Nov 2010 07:46:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Martin Bjorklund References: <20101115.125423.174894940.mbj@tail-f.com> <201011151341.oAFDfcE1028905@idle.juniper.net> <20101115.153916.162594769.mbj@tail-f.com> In-Reply-To: <20101115.153916.162594769.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 15 Nov 2010 15:46:17 -0000 On 11/15/2010 06:39 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>>> IMO, Phil's framing is the best choice from the security review POV. >>> It should be clear by now that Phil's solution does not solve the >>> injection problem. >> >> I think he's referring to my original suggestion of a real, honest >> to goodness framing mechanism. >> >> http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html >> http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html > > I know. And I referred to: > > http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html > > If the attacker can insert something that modifies the current > edit-config so that e.g. the password for an admin user is changed, > then the attacker can do anything. > This is only addressed by NACM. If the framing relies on NETCONF content it is not real framing. Period. Or should I say, ]]>]]>. There is no need whatsoever to mix-and-match framing with protocol ersions. 4741bis MUST use the new framing. 4741 MUST use the old framing. This applies to SSH and TLS. IMO, we should use Phil's framing proposal + Juergen's base:1.1 check to change the framing after the hello. Also, 4741bis should be changed so any loss of framing causes the session to be dropped. The server MUST send operation-failed and then MUST drop the session. > /martin > > > Andy From biermana@Brocade.com Mon Nov 15 09:47: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 BF6D428C120 for ; Mon, 15 Nov 2010 09:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xA+Ch4C+Ayvy for ; Mon, 15 Nov 2010 09:46:54 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 10B143A6B4F for ; Mon, 15 Nov 2010 09:46:54 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAFHlavl015675 for ; Mon, 15 Nov 2010 09:47:36 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id sk90yr0sg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Nov 2010 09:47:35 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 15 Nov 2010 09:47:57 -0800 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; Mon, 15 Nov 2010 09:47:35 -0800 From: Andy Bierman To: "netconf@ietf.org" Date: Mon, 15 Nov 2010 09:47:32 -0800 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-02.txt Thread-Index: AcuEb0w3kbqe7b9xRYyq6vT2vrLOygAfKIFQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_B11AB91666F22D498EEC66410EB3D3C4F412BED2B1HQ1EXCH01corp_" 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-11-15_08:2010-11-15, 2010-11-15, 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-1010190000 definitions=main-1011150151 Subject: [Netconf] FW: I-D Action:draft-ietf-netconf-system-notifications-02.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, 15 Nov 2010 17:47:00 -0000 --_003_B11AB91666F22D498EEC66410EB3D3C4F412BED2B1HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This draft, the module in it, and all the notifications in the module, have been renamed, as requested. Please review the latest draft. I think it is ready for WGLC. Note that the event discussed at the meeting has not been added. The only changes were: * rename doc title, module, namespace, notifications * all the changes requested by Martin (Nov. 7 email to WG ML) Thanks, Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Sunday, November 14, 2010 6:45 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-02.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of the= IETF. Title : Network Configuration Protocol Notification Events Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-02.txt Pages : 13 Date : 2010-11-14 The NETCONF protocol provides mechanisms to manipulate configuration datast= ores. However, client applications often need to be aware of common events= such as a change in NETCONF capabilities, which may impact management appl= ications. Standard mechanisms are needed to support the monitoring of the = events within the NETCONF server. This document defines a YANG module whic= h allows a NETCONF client to receive notifications for some common events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -02.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_003_B11AB91666F22D498EEC66410EB3D3C4F412BED2B1HQ1EXCH01corp_ Content-Type: text/plain; name="draft-ietf-netconf-system-notifications-02.url.txt" Content-Description: draft-ietf-netconf-system-notifications-02.url.txt Content-Disposition: attachment; filename="draft-ietf-netconf-system-notifications-02.url.txt"; size=107; creation-date="Sun, 14 Nov 2010 18:46:26 GMT"; modification-date="Sun, 14 Nov 2010 18:46:26 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_003_B11AB91666F22D498EEC66410EB3D3C4F412BED2B1HQ1EXCH01corp_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=136; creation-date="Sun, 14 Nov 2010 18:46:26 GMT"; modification-date="Sun, 14 Nov 2010 18:46:26 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_003_B11AB91666F22D498EEC66410EB3D3C4F412BED2B1HQ1EXCH01corp_-- From lhotka@cesnet.cz Tue Nov 16 02:03: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 D884F3A6DA1 for ; Tue, 16 Nov 2010 02:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[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 Hwcp6w58-zBO for ; Tue, 16 Nov 2010 02:03:28 -0800 (PST) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id DA59F3A6D8C for ; Tue, 16 Nov 2010 02:03:27 -0800 (PST) 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 280113E0085; Tue, 16 Nov 2010 11:04:08 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , phil@juniper.net In-Reply-To: <20101115.153916.162594769.mbj@tail-f.com> References: <20101115.125423.174894940.mbj@tail-f.com> <201011151341.oAFDfcE1028905@idle.juniper.net> <20101115.153916.162594769.mbj@tail-f.com> User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1 (i686-pc-linux-gnu) Date: Tue, 16 Nov 2010 11:03:45 +0100 Message-ID: <87r5elvb3y.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 10:03:28 -0000 On Mon, 15 Nov 2010 15:39:16 +0100 (CET), Martin Bjorklund wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > > >> IMO, Phil's framing is the best choice from the security review POV. > > >It should be clear by now that Phil's solution does not solve the > > >injection problem. > > > > I think he's referring to my original suggestion of a real, honest > > to goodness framing mechanism. > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html > > http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html > > I know. And I referred to: > > http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html > > If the attacker can insert something that modifies the current > edit-config so that e.g. the password for an admin user is changed, > then the attacker can do anything. True, but this is no more an issue for the transport layer. I would support Juergen's switchover hack with Phil's framing, I only think it would be better to signal the new framing to the transport layer via a PI. What if we had both - the base:1.1 AND the PIs? An implementation then could decide what to use. I guess this would be the best outcome of this whole affair, especially if it could be fixed now. Lada > > > /martin > > _______________________________________________ > 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 Tue Nov 16 02:17: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 443FD3A6D9C for ; Tue, 16 Nov 2010 02:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlvS7ZOLAU6u for ; Tue, 16 Nov 2010 02:17:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 376753A6D8C for ; Tue, 16 Nov 2010 02:17:02 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F82BC001A; Tue, 16 Nov 2010 11:17:45 +0100 (CET) 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 cmLroYB8RIz7; Tue, 16 Nov 2010 11:17:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53230C001C; Tue, 16 Nov 2010 11:17:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 538EE15ABAD2; Tue, 16 Nov 2010 11:17:42 +0100 (CET) Date: Tue, 16 Nov 2010 11:17:42 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101116101741.GA81806@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , phil@juniper.net, netconf@ietf.org References: <20101115.125423.174894940.mbj@tail-f.com> <201011151341.oAFDfcE1028905@idle.juniper.net> <20101115.153916.162594769.mbj@tail-f.com> <87r5elvb3y.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r5elvb3y.fsf@cesnet.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 10:17:03 -0000 On Tue, Nov 16, 2010 at 11:03:45AM +0100, Ladislav Lhotka wrote: > True, but this is no more an issue for the transport layer. I would > support Juergen's switchover hack with Phil's framing, I only think it > would be better to signal the new framing to the transport layer via a > PI. What if we had both - the base:1.1 AND the PIs? An implementation > then could decide what to use. Having two ways to do this is IMHO a bad idea; this allows combinations that are not really fun to have. /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 Tue Nov 16 07:27: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 5AC843A6B71 for ; Tue, 16 Nov 2010 07:27:59 -0800 (PST) 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 na16LKekfo34 for ; Tue, 16 Nov 2010 07:27:58 -0800 (PST) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id 4826C3A6899 for ; Tue, 16 Nov 2010 07:27:58 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAGFSfSG004061 for ; Tue, 16 Nov 2010 10:28:41 -0500 Authentication-Results: cm-omr5 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [174.144.38.43] ([174.144.38.43:60984] helo=[174.144.38.43]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7C/58-13031-623A2EC4; Tue, 16 Nov 2010 10:28:41 -0500 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" , "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" , phil@juniper.net Message-ID: <7C.58.13031.623A2EC4@cm-omr5> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 16 Nov 2010 23:28:54 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1289921334897" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?way_forward_on_netconf_EOM?= 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, 16 Nov 2010 15:27:59 -0000 ------=_Part_1_1289921334897 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgZG8gbm90IG5lZWQgMiB3YXlzIHRvIGluZGljYXRlIHRoZSBuZXcgZnJhbWluZy4gQWxsIHBl ZXJzIHdvdWxkIGhhdmUgdG8gc3VwcG9ydCBhbGwgb3B0aW9ucy4gIFRoZXJlIGlzIG5vIGNob2lj ZSBvZiBlb20gYWxsb3dlZC4gIDEuMSBtZWFucyBuZXcgZnJhbWluZy4gIE5vIGV4Y2VwdGlvbnMu CgpBbmR5CgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTGFkaXNsYXYgTGhvdGth IiA8bGhvdGthQGNlc25ldC5jej4KRGF0ZTogVHVlLCBOb3YgMTYsIDIwMTAgMDI6MDMKU3ViamVj dDogW05ldGNvbmZdIHdheSBmb3J3YXJkIG9uIG5ldGNvbmYgRU9NClRvOiAiTWFydGluIEJqb3Jr bHVuZCIgPG1iakB0YWlsLWYuY29tPiwgPHBoaWxAanVuaXBlci5uZXQ+CkNjOiA8bmV0Y29uZkBp ZXRmLm9yZz4KCgpPbiBNb24sIDE1IE5vdiAyMDEwIDE1OjM5OjE2ICswMTAwIChDRVQpLCBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6Cj4gUGhpbCBTaGFmZXIgPHBoaWxA anVuaXBlci5uZXQ+IHdyb3RlOgo+ID4gTWFydGluIEJqb3JrbHVuZCB3cml0ZXM6Cj4gPiA+PiBJ TU8sIFBoaWwncyBmcmFtaW5nIGlzIHRoZSBiZXN0IGNob2ljZSBmcm9tIHRoZSBzZWN1cml0eSBy ZXZpZXcgUE9WLgo+ID4gPkl0IHNob3VsZCBiZSBjbGVhciBieSBub3cgdGhhdCBQaGlsJ3Mgc29s dXRpb24gZG9lcyBub3Qgc29sdmUgdGhlCj4gPiA+aW5qZWN0aW9uIHByb2JsZW0uCj4gPiAKPiA+ IEkgdGhpbmsgaGUncyByZWZlcnJpbmcgdG8gbXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiBvZiBhIHJl YWwsIGhvbmVzdAo+ID4gdG8gZ29vZG5lc3MgZnJhbWluZyBtZWNoYW5pc20uCj4gPiAKPiA+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYy MTYuaHRtbAo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYv Y3VycmVudC9tc2cwNjIxOS5odG1sCj4gCj4gSSBrbm93LiAgQW5kIEkgcmVmZXJyZWQgdG86Cj4g Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9t c2cwNjU1Ni5odG1sCj4gCj4gSWYgdGhlIGF0dGFja2VyIGNhbiBpbnNlcnQgc29tZXRoaW5nIHRo YXQgbW9kaWZpZXMgdGhlIGN1cnJlbnQKPiBlZGl0LWNvbmZpZyBzbyB0aGF0IGUuZy4gdGhlIHBh c3N3b3JkIGZvciBhbiBhZG1pbiB1c2VyIGlzIGNoYW5nZWQsCj4gdGhlbiB0aGUgYXR0YWNrZXIg Y2FuIGRvIGFueXRoaW5nLgoKVHJ1ZSwgYnV0IHRoaXMgaXMgbm8gbW9yZSBhbiBpc3N1ZSBmb3Ig dGhlIHRyYW5zcG9ydCBsYXllci4gSSB3b3VsZApzdXBwb3J0IEp1ZXJnZW4ncyBzd2l0Y2hvdmVy IGhhY2sgd2l0aCBQaGlsJ3MgZnJhbWluZywgSSBvbmx5IHRoaW5rIGl0CndvdWxkIGJlIGJldHRl ciB0byBzaWduYWwgdGhlIG5ldyBmcmFtaW5nIHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIgdmlhIGEK UEkuIFdoYXQgaWYgd2UgaGFkIGJvdGggLSB0aGUgYmFzZToxLjEgQU5EIHRoZSBQSXM/IEFuIGlt cGxlbWVudGF0aW9uCnRoZW4gY291bGQgZGVjaWRlIHdoYXQgdG8gdXNlLgoKSSBndWVzcyB0aGlz IHdvdWxkIGJlIHRoZSBiZXN0IG91dGNvbWUgb2YgdGhpcyB3aG9sZSBhZmZhaXIsIGVzcGVjaWFs bHkKaWYgaXQgY291bGQgYmUgZml4ZWQgbm93LgoKTGFkYQoKPiAKPiAKPiAvbWFydGluCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBOZXRjb25m IG1haWxpbmcgbGlzdAo+IE5ldGNvbmZAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1Ag S2V5IElEOiBFNzRFOEMwQwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpOZXRjb25mIG1haWxpbmcgbGlzdApOZXRjb25mQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgoK ------=_Part_1_1289921334897 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgZG8gbm90IG5lZWQgMiB3YXlzIHRvIGluZGljYXRlIHRoZSBuZXcgZnJhbWluZy4gQWxsIHBl ZXJzIHdvdWxkIGhhdmUgdG8gc3VwcG9ydCBhbGwgb3B0aW9ucy4gJm5ic3A7VGhlcmUgaXMgbm8g Y2hvaWNlIG9mIGVvbSBhbGxvd2VkLiAmbmJzcDsxLjEgbWVhbnMgbmV3IGZyYW1pbmcuICZuYnNw O05vIGV4Y2VwdGlvbnMuPGJyPjxicj5BbmR5PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2Fn ZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtMYWRpc2xhdiBMaG90a2EmcXVvdDsgJmx0O2xob3RrYUBj ZXNuZXQuY3omZ3Q7PGJyPkRhdGU6IFR1ZSwgTm92IDE2LCAyMDEwIDAyOjAzPGJyPlN1YmplY3Q6 IFtOZXRjb25mXSB3YXkgZm9yd2FyZCBvbiBuZXRjb25mIEVPTTxicj5UbzogJnF1b3Q7TWFydGlu IEJqb3JrbHVuZCZxdW90OyAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7LCAmbHQ7cGhpbEBqdW5pcGVy Lm5ldCZndDs8YnI+Q2M6ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPk9uIE1v biwgMTUgTm92IDIwMTAgMTU6Mzk6MTYgKzAxMDAgKENFVCksIE1hcnRpbiBCam9ya2x1bmQgJmx0 O21iakB0YWlsLWYuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyBQaGlsIFNoYWZlciAmbHQ7cGhpbEBq dW5pcGVyLm5ldCZndDsgd3JvdGU6PGJyPiZndDsgJmd0OyBNYXJ0aW4gQmpvcmtsdW5kIHdyaXRl czo8YnI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7IElNTywgUGhpbCYjMzk7cyBmcmFtaW5nIGlzIHRoZSBi ZXN0IGNob2ljZSBmcm9tIHRoZSBzZWN1cml0eSByZXZpZXcgUE9WLjxicj4mZ3Q7ICZndDsgJmd0 O0l0IHNob3VsZCBiZSBjbGVhciBieSBub3cgdGhhdCBQaGlsJiMzOTtzIHNvbHV0aW9uIGRvZXMg bm90IHNvbHZlIHRoZTxicj4mZ3Q7ICZndDsgJmd0O2luamVjdGlvbiBwcm9ibGVtLjxicj4mZ3Q7 ICZndDsgPGJyPiZndDsgJmd0OyBJIHRoaW5rIGhlJiMzOTtzIHJlZmVycmluZyB0byBteSBvcmln aW5hbCBzdWdnZXN0aW9uIG9mIGEgcmVhbCwgaG9uZXN0PGJyPiZndDsgJmd0OyB0byBnb29kbmVz cyBmcmFtaW5nIG1lY2hhbmlzbS48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cw NjIxNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9j dXJyZW50L21zZzA2MjE2Lmh0bWw8L2E+PGJyPiZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA2MjE5Lmh0bWwi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNn MDYyMTkuaHRtbDwvYT48YnI+Jmd0OyA8YnI+Jmd0OyBJIGtub3cuICZuYnNwO0FuZCBJIHJlZmVy cmVkIHRvOjxicj4mZ3Q7IDxicj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDY1NTYuaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjU1Ni5odG1sPC9h Pjxicj4mZ3Q7IDxicj4mZ3Q7IElmIHRoZSBhdHRhY2tlciBjYW4gaW5zZXJ0IHNvbWV0aGluZyB0 aGF0IG1vZGlmaWVzIHRoZSBjdXJyZW50PGJyPiZndDsgZWRpdC1jb25maWcgc28gdGhhdCBlLmcu IHRoZSBwYXNzd29yZCBmb3IgYW4gYWRtaW4gdXNlciBpcyBjaGFuZ2VkLDxicj4mZ3Q7IHRoZW4g dGhlIGF0dGFja2VyIGNhbiBkbyBhbnl0aGluZy48YnI+PGJyPlRydWUsIGJ1dCB0aGlzIGlzIG5v IG1vcmUgYW4gaXNzdWUgZm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIuIEkgd291bGQ8YnI+c3VwcG9y dCBKdWVyZ2VuJiMzOTtzIHN3aXRjaG92ZXIgaGFjayB3aXRoIFBoaWwmIzM5O3MgZnJhbWluZywg SSBvbmx5IHRoaW5rIGl0PGJyPndvdWxkIGJlIGJldHRlciB0byBzaWduYWwgdGhlIG5ldyBmcmFt aW5nIHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIgdmlhIGE8YnI+UEkuIFdoYXQgaWYgd2UgaGFkIGJv dGggLSB0aGUgYmFzZToxLjEgQU5EIHRoZSBQSXM/IEFuIGltcGxlbWVudGF0aW9uPGJyPnRoZW4g Y291bGQgZGVjaWRlIHdoYXQgdG8gdXNlLjxicj48YnI+SSBndWVzcyB0aGlzIHdvdWxkIGJlIHRo ZSBiZXN0IG91dGNvbWUgb2YgdGhpcyB3aG9sZSBhZmZhaXIsIGVzcGVjaWFsbHk8YnI+aWYgaXQg Y291bGQgYmUgZml4ZWQgbm93Ljxicj48YnI+TGFkYTxicj48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+ Jmd0OyAvbWFydGluPGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4mZ3Q7 IE5ldGNvbmZAaWV0Zi5vcmc8YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZjwvYT48YnI+PGJyPi0tIDxicj5MYWRpc2xhdiBMaG90a2EsIENFU05FVDxi cj5QR1AgS2V5IElEOiBFNzRFOEMwQzxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5OZXRjb25mIG1haWxpbmcgbGlzdDxicj5OZXRjb25mQGlldGYu b3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxi cj48YnI+PGJyPjxicj4= ------=_Part_1_1289921334897-- From lhotka@cesnet.cz Tue Nov 16 07:34: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 0CCD03A6D86 for ; Tue, 16 Nov 2010 07:34:16 -0800 (PST) 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 SPFYtyJU2nqE for ; Tue, 16 Nov 2010 07:34:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B5B063A6C7F for ; Tue, 16 Nov 2010 07:34:14 -0800 (PST) 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 8C1A32CDE05B; Tue, 16 Nov 2010 16:34:56 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <7C.58.13031.623A2EC4@cm-omr5> References: <7C.58.13031.623A2EC4@cm-omr5> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 16 Nov 2010 16:34:55 +0100 Message-ID: <1289921695.8360.51.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 15:34:16 -0000 On Út, 2010-11-16 at 23:28 +0800, Andy Bierman wrote: > We do not need 2 ways to indicate the new framing. All peers would > have to support all options. There is no choice of eom allowed. 1.1 > means new framing. No exceptions. OK, then I am slightly in favor of the PI as the authoritative indication of the new framing. Lada > > Andy > > > ----- Reply message ----- > From: "Ladislav Lhotka" > Date: Tue, Nov 16, 2010 02:03 > Subject: [Netconf] way forward on netconf EOM > To: "Martin Bjorklund" , > Cc: > > > On Mon, 15 Nov 2010 15:39:16 +0100 (CET), Martin Bjorklund > wrote: > > Phil Shafer wrote: > > > Martin Bjorklund writes: > > > >> IMO, Phil's framing is the best choice from the security review > POV. > > > >It should be clear by now that Phil's solution does not solve the > > > >injection problem. > > > > > > I think he's referring to my original suggestion of a real, honest > > > to goodness framing mechanism. > > > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html > > > > I know. And I referred to: > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html > > > > If the attacker can insert something that modifies the current > > edit-config so that e.g. the password for an admin user is changed, > > then the attacker can do anything. > > True, but this is no more an issue for the transport layer. I would > support Juergen's switchover hack with Phil's framing, I only think it > would be better to signal the new framing to the transport layer via a > PI. What if we had both - the base:1.1 AND the PIs? An implementation > then could decide what to use. > > I guess this would be the best outcome of this whole affair, > especially > if it could be fixed now. > > Lada > > > > > > > /martin > > > > _______________________________________________ > > 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 Tue Nov 16 07:52: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 653B33A6DEF for ; Tue, 16 Nov 2010 07:52:22 -0800 (PST) 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 RW+54MNPHvGE for ; Tue, 16 Nov 2010 07:52:21 -0800 (PST) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by core3.amsl.com (Postfix) with ESMTP id 3CB203A6DED for ; Tue, 16 Nov 2010 07:52:20 -0800 (PST) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAGFr1bR010137 for ; Tue, 16 Nov 2010 10:53:03 -0500 Authentication-Results: cm-omr6 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [174.144.38.43] ([174.144.38.43:57301] helo=[174.144.38.43]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C5/60-20749-9D8A2EC4; Tue, 16 Nov 2010 10:53:01 -0500 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 16 Nov 2010 23:53:14 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3_1289922794648" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?way_forward_on_netconf_EOM?= 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, 16 Nov 2010 15:52:22 -0000 ------=_Part_3_1289922794648 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2h5PwpUaGUgYmFzZToxLjEgaXMgY2xlYXIgYW5kIHVuYW1iaWd1b3VzLiAgTmV0Y29uZiBkb2Vz IG5vdCByZXF1aXJlIFBJIHByb2Nlc3NpbmcuICBXZSBzaG91bGQga2VlcCBpdCB0aGF0IHdheS4K ClRoZSBiYXNlIHVyaSBhbHJlYWR5IGhhcyB0byBiZSBwcmVzZW50LiAgVGhlcmUgaXMgbm8gbmVl ZCBmb3IgbmV3IGhhY2tzIGFuZCBkZWFsaW5nIHdpdGggdGhlIGNvcm5lciBjYXNlcy4gIEkgZG8g bm90IHdhbnQgdG8gbGV0IGltcGxlbWVudGVycyBjaG9vc2UgdGhlIHdyb25nIGZyYW1pbmcuCgoK LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGth QGNlc25ldC5jej4KRGF0ZTogVHVlLCBOb3YgMTYsIDIwMTAgMDc6MzQKU3ViamVjdDogW05ldGNv bmZdIHdheSBmb3J3YXJkIG9uIG5ldGNvbmYgRU9NClRvOiAiQW5keSBCaWVybWFuIiA8aWV0ZkBh bmR5Ymllcm1hbi5jb20+CkNjOiAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPiwg PHBoaWxAanVuaXBlci5uZXQ+LCA8bmV0Y29uZkBpZXRmLm9yZz4KCgpPbiDDmnQsIDIwMTAtMTEt MTYgYXQgMjM6MjggKzA4MDAsIEFuZHkgQmllcm1hbiB3cm90ZToKPiBXZSBkbyBub3QgbmVlZCAy IHdheXMgdG8gaW5kaWNhdGUgdGhlIG5ldyBmcmFtaW5nLiBBbGwgcGVlcnMgd291bGQKPiBoYXZl IHRvIHN1cHBvcnQgYWxsIG9wdGlvbnMuICBUaGVyZSBpcyBubyBjaG9pY2Ugb2YgZW9tIGFsbG93 ZWQuICAxLjEKPiBtZWFucyBuZXcgZnJhbWluZy4gIE5vIGV4Y2VwdGlvbnMuCgpPSywgdGhlbiBJ IGFtIHNsaWdodGx5IGluIGZhdm9yIG9mIHRoZSBQSSBhcyB0aGUgYXV0aG9yaXRhdGl2ZQppbmRp Y2F0aW9uIG9mIHRoZSBuZXcgZnJhbWluZy4KCkxhZGEKCj4gCj4gQW5keQo+IAo+IAo+IC0tLS0t IFJlcGx5IG1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQGNl c25ldC5jej4KPiBEYXRlOiBUdWUsIE5vdiAxNiwgMjAxMCAwMjowMwo+IFN1YmplY3Q6IFtOZXRj b25mXSB3YXkgZm9yd2FyZCBvbiBuZXRjb25mIEVPTQo+IFRvOiAiTWFydGluIEJqb3JrbHVuZCIg PG1iakB0YWlsLWYuY29tPiwgPHBoaWxAanVuaXBlci5uZXQ+Cj4gQ2M6IDxuZXRjb25mQGlldGYu b3JnPgo+IAo+IAo+IE9uIE1vbiwgMTUgTm92IDIwMTAgMTU6Mzk6MTYgKzAxMDAgKENFVCksIE1h cnRpbiBCam9ya2x1bmQKPiA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOgo+ID4gUGhpbCBTaGFmZXIg PHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOgo+ID4gPiBNYXJ0aW4gQmpvcmtsdW5kIHdyaXRlczoK PiA+ID4gPj4gSU1PLCBQaGlsJ3MgZnJhbWluZyBpcyB0aGUgYmVzdCBjaG9pY2UgZnJvbSB0aGUg c2VjdXJpdHkgcmV2aWV3Cj4gUE9WLgo+ID4gPiA+SXQgc2hvdWxkIGJlIGNsZWFyIGJ5IG5vdyB0 aGF0IFBoaWwncyBzb2x1dGlvbiBkb2VzIG5vdCBzb2x2ZSB0aGUKPiA+ID4gPmluamVjdGlvbiBw cm9ibGVtLgo+ID4gPiAKPiA+ID4gSSB0aGluayBoZSdzIHJlZmVycmluZyB0byBteSBvcmlnaW5h bCBzdWdnZXN0aW9uIG9mIGEgcmVhbCwgaG9uZXN0Cj4gPiA+IHRvIGdvb2RuZXNzIGZyYW1pbmcg bWVjaGFuaXNtLgo+ID4gPiAKPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjIxNi5odG1sCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYyMTkuaHRtbAo+ID4gCj4g PiBJIGtub3cuICBBbmQgSSByZWZlcnJlZCB0bzoKPiA+IAo+ID4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjU1Ni5odG1sCj4gPiAKPiA+ IElmIHRoZSBhdHRhY2tlciBjYW4gaW5zZXJ0IHNvbWV0aGluZyB0aGF0IG1vZGlmaWVzIHRoZSBj dXJyZW50Cj4gPiBlZGl0LWNvbmZpZyBzbyB0aGF0IGUuZy4gdGhlIHBhc3N3b3JkIGZvciBhbiBh ZG1pbiB1c2VyIGlzIGNoYW5nZWQsCj4gPiB0aGVuIHRoZSBhdHRhY2tlciBjYW4gZG8gYW55dGhp bmcuCj4gCj4gVHJ1ZSwgYnV0IHRoaXMgaXMgbm8gbW9yZSBhbiBpc3N1ZSBmb3IgdGhlIHRyYW5z cG9ydCBsYXllci4gSSB3b3VsZAo+IHN1cHBvcnQgSnVlcmdlbidzIHN3aXRjaG92ZXIgaGFjayB3 aXRoIFBoaWwncyBmcmFtaW5nLCBJIG9ubHkgdGhpbmsgaXQKPiB3b3VsZCBiZSBiZXR0ZXIgdG8g c2lnbmFsIHRoZSBuZXcgZnJhbWluZyB0byB0aGUgdHJhbnNwb3J0IGxheWVyIHZpYSBhCj4gUEku IFdoYXQgaWYgd2UgaGFkIGJvdGggLSB0aGUgYmFzZToxLjEgQU5EIHRoZSBQSXM/IEFuIGltcGxl bWVudGF0aW9uCj4gdGhlbiBjb3VsZCBkZWNpZGUgd2hhdCB0byB1c2UuCj4gCj4gSSBndWVzcyB0 aGlzIHdvdWxkIGJlIHRoZSBiZXN0IG91dGNvbWUgb2YgdGhpcyB3aG9sZSBhZmZhaXIsCj4gZXNw ZWNpYWxseQo+IGlmIGl0IGNvdWxkIGJlIGZpeGVkIG5vdy4KPiAKPiBMYWRhCj4gCj4gPiAKPiA+ IAo+ID4gL21hcnRpbgo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QKPiA+IE5ldGNvbmZAaWV0Zi5v cmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgo+IAo+ IC0tIAo+IExhZGlzbGF2IExob3RrYSwgQ0VTTkVUCj4gUEdQIEtleSBJRDogRTc0RThDMEMKPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE5ldGNvbmYg bWFpbGluZyBsaXN0Cj4gTmV0Y29uZkBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZgo+IAo+IAo+IAoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VT TkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgoK ------=_Part_3_1289922794648 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2h5Pzxicj5UaGUgYmFzZToxLjEgaXMgY2xlYXIgYW5kIHVuYW1iaWd1b3VzLiAmbmJzcDtOZXRj b25mIGRvZXMgbm90IHJlcXVpcmUgUEkgcHJvY2Vzc2luZy4gJm5ic3A7V2Ugc2hvdWxkIGtlZXAg aXQgdGhhdCB3YXkuPGJyPjxicj5UaGUgYmFzZSB1cmkgYWxyZWFkeSBoYXMgdG8gYmUgcHJlc2Vu dC4gJm5ic3A7VGhlcmUgaXMgbm8gbmVlZCBmb3IgbmV3IGhhY2tzIGFuZCBkZWFsaW5nIHdpdGgg dGhlIGNvcm5lciBjYXNlcy4gJm5ic3A7SSBkbyBub3Qgd2FudCB0byBsZXQgaW1wbGVtZW50ZXJz IGNob29zZSB0aGUgd3JvbmcgZnJhbWluZy48YnI+PGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdl IC0tLS0tPGJyPkZyb206ICZxdW90O0xhZGlzbGF2IExob3RrYSZxdW90OyAmbHQ7bGhvdGthQGNl c25ldC5jeiZndDs8YnI+RGF0ZTogVHVlLCBOb3YgMTYsIDIwMTAgMDc6MzQ8YnI+U3ViamVjdDog W05ldGNvbmZdIHdheSBmb3J3YXJkIG9uIG5ldGNvbmYgRU9NPGJyPlRvOiAmcXVvdDtBbmR5IEJp ZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5keWJpZXJtYW4uY29tJmd0Ozxicj5DYzogJnF1b3Q7TWFy dGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7LCAmbHQ7cGhpbEBqdW5p cGVyLm5ldCZndDssICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPk9uIMOadCwg MjAxMC0xMS0xNiBhdCAyMzoyOCArMDgwMCwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4mZ3Q7IFdl IGRvIG5vdCBuZWVkIDIgd2F5cyB0byBpbmRpY2F0ZSB0aGUgbmV3IGZyYW1pbmcuIEFsbCBwZWVy cyB3b3VsZDxicj4mZ3Q7IGhhdmUgdG8gc3VwcG9ydCBhbGwgb3B0aW9ucy4gJm5ic3A7VGhlcmUg aXMgbm8gY2hvaWNlIG9mIGVvbSBhbGxvd2VkLiAmbmJzcDsxLjE8YnI+Jmd0OyBtZWFucyBuZXcg ZnJhbWluZy4gJm5ic3A7Tm8gZXhjZXB0aW9ucy48YnI+PGJyPk9LLCB0aGVuIEkgYW0gc2xpZ2h0 bHkgaW4gZmF2b3Igb2YgdGhlIFBJIGFzIHRoZSBhdXRob3JpdGF0aXZlPGJyPmluZGljYXRpb24g b2YgdGhlIG5ldyBmcmFtaW5nLjxicj48YnI+TGFkYTxicj48YnI+Jmd0OyA8YnI+Jmd0OyBBbmR5 PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4m Z3Q7IEZyb206ICZxdW90O0xhZGlzbGF2IExob3RrYSZxdW90OyAmbHQ7bGhvdGthQGNlc25ldC5j eiZndDs8YnI+Jmd0OyBEYXRlOiBUdWUsIE5vdiAxNiwgMjAxMCAwMjowMzxicj4mZ3Q7IFN1Ympl Y3Q6IFtOZXRjb25mXSB3YXkgZm9yd2FyZCBvbiBuZXRjb25mIEVPTTxicj4mZ3Q7IFRvOiAmcXVv dDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDttYmpAdGFpbC1mLmNvbSZndDssICZsdDtwaGls QGp1bmlwZXIubmV0Jmd0Ozxicj4mZ3Q7IENjOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+ Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBPbiBNb24sIDE1IE5vdiAyMDEwIDE1OjM5OjE2ICswMTAw IChDRVQpLCBNYXJ0aW4gQmpvcmtsdW5kPGJyPiZndDsgJmx0O21iakB0YWlsLWYuY29tJmd0OyB3 cm90ZTo8YnI+Jmd0OyAmZ3Q7IFBoaWwgU2hhZmVyICZsdDtwaGlsQGp1bmlwZXIubmV0Jmd0OyB3 cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgTWFydGluIEJqb3JrbHVuZCB3cml0ZXM6PGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7IElNTywgUGhpbCYjMzk7cyBmcmFtaW5nIGlzIHRoZSBiZXN0IGNo b2ljZSBmcm9tIHRoZSBzZWN1cml0eSByZXZpZXc8YnI+Jmd0OyBQT1YuPGJyPiZndDsgJmd0OyAm Z3Q7ICZndDtJdCBzaG91bGQgYmUgY2xlYXIgYnkgbm93IHRoYXQgUGhpbCYjMzk7cyBzb2x1dGlv biBkb2VzIG5vdCBzb2x2ZSB0aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0O2luamVjdGlvbiBwcm9i bGVtLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgSSB0aGluayBoZSYjMzk7 cyByZWZlcnJpbmcgdG8gbXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiBvZiBhIHJlYWwsIGhvbmVzdDxi cj4mZ3Q7ICZndDsgJmd0OyB0byBnb29kbmVzcyBmcmFtaW5nIG1lY2hhbmlzbS48YnI+Jmd0OyAm Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYyMTYuaHRtbCI+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjIxNi5odG1s PC9hPjxicj4mZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA2MjE5Lmh0bWwiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYyMTkuaHRtbDwvYT48 YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSSBrbm93LiAmbmJzcDtBbmQgSSByZWZlcnJlZCB0 bzo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjU1Ni5odG1sIj5odHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA2NTU2Lmh0 bWw8L2E+PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IElmIHRoZSBhdHRhY2tlciBjYW4gaW5z ZXJ0IHNvbWV0aGluZyB0aGF0IG1vZGlmaWVzIHRoZSBjdXJyZW50PGJyPiZndDsgJmd0OyBlZGl0 LWNvbmZpZyBzbyB0aGF0IGUuZy4gdGhlIHBhc3N3b3JkIGZvciBhbiBhZG1pbiB1c2VyIGlzIGNo YW5nZWQsPGJyPiZndDsgJmd0OyB0aGVuIHRoZSBhdHRhY2tlciBjYW4gZG8gYW55dGhpbmcuPGJy PiZndDsgPGJyPiZndDsgVHJ1ZSwgYnV0IHRoaXMgaXMgbm8gbW9yZSBhbiBpc3N1ZSBmb3IgdGhl IHRyYW5zcG9ydCBsYXllci4gSSB3b3VsZDxicj4mZ3Q7IHN1cHBvcnQgSnVlcmdlbiYjMzk7cyBz d2l0Y2hvdmVyIGhhY2sgd2l0aCBQaGlsJiMzOTtzIGZyYW1pbmcsIEkgb25seSB0aGluayBpdDxi cj4mZ3Q7IHdvdWxkIGJlIGJldHRlciB0byBzaWduYWwgdGhlIG5ldyBmcmFtaW5nIHRvIHRoZSB0 cmFuc3BvcnQgbGF5ZXIgdmlhIGE8YnI+Jmd0OyBQSS4gV2hhdCBpZiB3ZSBoYWQgYm90aCAtIHRo ZSBiYXNlOjEuMSBBTkQgdGhlIFBJcz8gQW4gaW1wbGVtZW50YXRpb248YnI+Jmd0OyB0aGVuIGNv dWxkIGRlY2lkZSB3aGF0IHRvIHVzZS48YnI+Jmd0OyA8YnI+Jmd0OyBJIGd1ZXNzIHRoaXMgd291 bGQgYmUgdGhlIGJlc3Qgb3V0Y29tZSBvZiB0aGlzIHdob2xlIGFmZmFpciw8YnI+Jmd0OyBlc3Bl Y2lhbGx5PGJyPiZndDsgaWYgaXQgY291bGQgYmUgZml4ZWQgbm93Ljxicj4mZ3Q7IDxicj4mZ3Q7 IExhZGE8YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAv bWFydGluPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyBOZXRjb25mIG1haWxpbmcgbGlz dDxicj4mZ3Q7ICZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPiZndDsgPGJyPiZndDsgLS0g PGJyPiZndDsgTGFkaXNsYXYgTGhvdGthLCBDRVNORVQ8YnI+Jmd0OyBQR1AgS2V5IElEOiBFNzRF OEMwQzxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBOZXRjb25mQGlldGYub3Jn PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+ PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgPGJyPjxicj4tLSA8YnI+TGFkaXNsYXYgTGhvdGth LCBDRVNORVQ8YnI+UEdQIEtleSBJRDogRTc0RThDMEM8YnI+PGJyPjxicj48YnI+PGJyPg== ------=_Part_3_1289922794648-- From lhotka@cesnet.cz Tue Nov 16 08:02: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 E76B73A6CB4 for ; Tue, 16 Nov 2010 08:02:55 -0800 (PST) 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 vcdAkIAwLr21 for ; Tue, 16 Nov 2010 08:02:55 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 6AE533A6B8A for ; Tue, 16 Nov 2010 08:02:54 -0800 (PST) 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 4436D2CDE05C; Tue, 16 Nov 2010 17:03:37 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 16 Nov 2010 17:03:36 +0100 Message-ID: <1289923416.8360.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 16:02:56 -0000 On Út, 2010-11-16 at 23:53 +0800, Andy Bierman wrote: > Why? > The base:1.1 is clear and unambiguous. Netconf does not require PI > processing. We should keep it that way. > > The base uri already has to be present. There is no need for new > hacks and dealing with the corner cases. I do not want to let > implementers choose the wrong framing. The parsing of hello is done by the message layer for which this will be a special case to signal the version to the SSH transport - it is not needed for any other transport. It also means the message layer cannot be transport-agnostic and use a generic transport layer API. IMO, SSH transport should eat its own dog food. Lada > > > ----- Reply message ----- > From: "Ladislav Lhotka" > Date: Tue, Nov 16, 2010 07:34 > Subject: [Netconf] way forward on netconf EOM > To: "Andy Bierman" > Cc: "Martin Bjorklund" , , > > > > On Út, 2010-11-16 at 23:28 +0800, Andy Bierman wrote: > > We do not need 2 ways to indicate the new framing. All peers would > > have to support all options. There is no choice of eom allowed. > 1.1 > > means new framing. No exceptions. > > OK, then I am slightly in favor of the PI as the authoritative > indication of the new framing. > > Lada > > > > > Andy > > > > > > ----- Reply message ----- > > From: "Ladislav Lhotka" > > Date: Tue, Nov 16, 2010 02:03 > > Subject: [Netconf] way forward on netconf EOM > > To: "Martin Bjorklund" , > > Cc: > > > > > > On Mon, 15 Nov 2010 15:39:16 +0100 (CET), Martin Bjorklund > > wrote: > > > Phil Shafer wrote: > > > > Martin Bjorklund writes: > > > > >> IMO, Phil's framing is the best choice from the security > review > > POV. > > > > >It should be clear by now that Phil's solution does not solve > the > > > > >injection problem. > > > > > > > > I think he's referring to my original suggestion of a real, > honest > > > > to goodness framing mechanism. > > > > > > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06216.html > > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06219.html > > > > > > I know. And I referred to: > > > > > > http://www.ietf.org/mail-archive/web/netconf/current/msg06556.html > > > > > > If the attacker can insert something that modifies the current > > > edit-config so that e.g. the password for an admin user is > changed, > > > then the attacker can do anything. > > > > True, but this is no more an issue for the transport layer. I would > > support Juergen's switchover hack with Phil's framing, I only think > it > > would be better to signal the new framing to the transport layer via > a > > PI. What if we had both - the base:1.1 AND the PIs? An > implementation > > then could decide what to use. > > > > I guess this would be the best outcome of this whole affair, > > especially > > if it could be fixed now. > > > > Lada > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > 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 > > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Nov 16 08:11: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 061303A6CA1 for ; Tue, 16 Nov 2010 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.169 X-Spam-Level: X-Spam-Status: No, score=-103.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St3GAK2Zypjl for ; Tue, 16 Nov 2010 08:11:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 711E13A6CB1 for ; Tue, 16 Nov 2010 08:11:16 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0EE8C0004; Tue, 16 Nov 2010 17:11:58 +0100 (CET) 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 bgFfdYD-drlc; Tue, 16 Nov 2010 17:11:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01463C000D; Tue, 16 Nov 2010 17:11:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB15A15AC7AE; Tue, 16 Nov 2010 17:11:57 +0100 (CET) Date: Tue, 16 Nov 2010 17:11:57 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101116161157.GA83349@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , netconf@ietf.org References: <1289923416.8360.58.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1289923416.8360.58.camel@missotis> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 16:11:24 -0000 On Tue, Nov 16, 2010 at 05:03:36PM +0100, Ladislav Lhotka wrote: > On Út, 2010-11-16 at 23:53 +0800, Andy Bierman wrote: > > Why? > > The base:1.1 is clear and unambiguous. Netconf does not require PI > > processing. We should keep it that way. > > > > The base uri already has to be present. There is no need for new > > hacks and dealing with the corner cases. I do not want to let > > implementers choose the wrong framing. > > The parsing of hello is done by the message layer for which this will be > a special case to signal the version to the SSH transport - it is not > needed for any other transport. It also means the message layer cannot > be transport-agnostic and use a generic transport layer API. Since there is no specific transport layer API, any arguments about how such an API looks are somewhat amusing. > IMO, SSH transport should eat its own dog food. Strictly speaking, the parsing of the whole XML document is done by the message layer - including any magic PIs. So the layering argument is not a strong one anyway. That said, I do not care too much as long as we do not need new subsystems or port numbers. /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 Tue Nov 16 08:33: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 306D13A6B69 for ; Tue, 16 Nov 2010 08:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 zxy9v8iMGyLA for ; Tue, 16 Nov 2010 08:33:09 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id D36663A68F2 for ; Tue, 16 Nov 2010 08:33:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTOKybPJSnCvarG6sdgDfractAEpDyyH2@postini.com; Tue, 16 Nov 2010 08:33:53 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 16 Nov 2010 08:32:11 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oAGGWAU90911; Tue, 16 Nov 2010 08:32:11 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oAGGAnIr048692; Tue, 16 Nov 2010 16:10:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011161610.oAGGAnIr048692@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1289923416.8360.58.camel@missotis> Date: Tue, 16 Nov 2010 11:10:49 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 16:33:10 -0000 Ladislav Lhotka writes: >The parsing of hello is done by the message layer for which this will be >a special case to signal the version to the SSH transport - it is not >needed for any other transport. It also means the message layer cannot >be transport-agnostic and use a generic transport layer API. > >IMO, SSH transport should eat its own dog food. One goal is that the transport handling layer should not have to parse XML for things to work right. This is for both framing of contents and for detection of the framing system. In Juergen's proposal, the NETCONF system detects the ability to use the new framing mechanism and signals (via function call/IPC/whatever) that the connection is now using the new mechanism. Thanks, Phil From lhotka@cesnet.cz Tue Nov 16 08:43:18 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 EBCF83A6CAF for ; Tue, 16 Nov 2010 08:43:18 -0800 (PST) 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 PCayE6SLOPkK for ; Tue, 16 Nov 2010 08:43:18 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D0E373A6D81 for ; Tue, 16 Nov 2010 08:43:17 -0800 (PST) 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 DC73C2CDE05B; Tue, 16 Nov 2010 17:43:56 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20101116161157.GA83349@elstar.local> References: <1289923416.8360.58.camel@missotis> <20101116161157.GA83349@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 16 Nov 2010 17:43:55 +0100 Message-ID: <1289925835.8360.63.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] way forward on netconf EOM 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, 16 Nov 2010 16:43:19 -0000 On Út, 2010-11-16 at 17:11 +0100, Juergen Schoenwaelder wrote: > On Tue, Nov 16, 2010 at 05:03:36PM +0100, Ladislav Lhotka wrote: > > On Út, 2010-11-16 at 23:53 +0800, Andy Bierman wrote: > > > Why? > > > The base:1.1 is clear and unambiguous. Netconf does not require PI > > > processing. We should keep it that way. > > > > > > The base uri already has to be present. There is no need for new > > > hacks and dealing with the corner cases. I do not want to let > > > implementers choose the wrong framing. > > > > The parsing of hello is done by the message layer for which this will be > > a special case to signal the version to the SSH transport - it is not > > needed for any other transport. It also means the message layer cannot > > be transport-agnostic and use a generic transport layer API. > > Since there is no specific transport layer API, any arguments about > how such an API looks are somewhat amusing. For any implementation supporting multiple transports, such an (internal) API seems quite logical. There is no such implementation so far, right? > > > IMO, SSH transport should eat its own dog food. > > Strictly speaking, the parsing of the whole XML document is done by > the message layer - including any magic PIs. So the layering argument > is not a strong one anyway. That said, I do not care too much as long > as we do not need new subsystems or port numbers. Martin proposed a procedure for "poor man's" parsing of the hello front matter, which is supposed to be performed by the SSH transport layer. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Tue Nov 16 10:05: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 E65CD3A6D8C for ; Tue, 16 Nov 2010 10:05:24 -0800 (PST) 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 aDTVBWhZ0M46 for ; Tue, 16 Nov 2010 10:05:23 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 11F913A6C89 for ; Tue, 16 Nov 2010 10:05:22 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAGI66ES025006 for ; Tue, 16 Nov 2010 13:06:06 -0500 Authentication-Results: cm-omr9 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [174.144.37.9] ([174.144.37.9:59661] helo=[174.144.37.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id DA/FB-06780-C08C2EC4; Tue, 16 Nov 2010 13:06:06 -0500 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 17 Nov 2010 02:06:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4_1289930779192" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?way_forward_on_netconf_EOM?= 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, 16 Nov 2010 18:05:25 -0000 ------=_Part_4_1289930779192 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBvYmplY3QgdG8gYW55IHBhcnNpbmcgb2YgWE1MIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIuICBB IDQ3NDFiaXMgcGVlciBtdXN0IGJlIGFibGUgdG8gdGVsbCBiYXNlIDEuMCBmcm9tIDEuMS4KVGhp cyBpcyBhbHdheXMgdGhlIGNvcnJlY3QgYW5zd2VyIGZvciB3aGljaCBmcmFtaW5nLiBUaGVyZSBp cyBubyB3YXkgYWRkaXRpb25hbCBmbGFncyBzaG91bGQgYmUgdXNlZC4KCgotLS0tLSBSZXBseSBt ZXNzYWdlIC0tLS0tCkZyb206ICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAY2VzbmV0LmN6PgpE YXRlOiBUdWUsIE5vdiAxNiwgMjAxMCAwNzozNApTdWJqZWN0OiBbTmV0Y29uZl0gd2F5IGZvcndh cmQgb24gbmV0Y29uZiBFT00KVG86ICJBbmR5IEJpZXJtYW4iIDxpZXRmQGFuZHliaWVybWFuLmNv bT4KQ2M6ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+LCA8cGhpbEBqdW5pcGVy Lm5ldD4sIDxuZXRjb25mQGlldGYub3JnPgoKCk9uIMOadCwgMjAxMC0xMS0xNiBhdCAyMzoyOCAr MDgwMCwgQW5keSBCaWVybWFuIHdyb3RlOgo+IFdlIGRvIG5vdCBuZWVkIDIgd2F5cyB0byBpbmRp Y2F0ZSB0aGUgbmV3IGZyYW1pbmcuIEFsbCBwZWVycyB3b3VsZAo+IGhhdmUgdG8gc3VwcG9ydCBh bGwgb3B0aW9ucy4gIFRoZXJlIGlzIG5vIGNob2ljZSBvZiBlb20gYWxsb3dlZC4gIDEuMQo+IG1l YW5zIG5ldyBmcmFtaW5nLiAgTm8gZXhjZXB0aW9ucy4KCk9LLCB0aGVuIEkgYW0gc2xpZ2h0bHkg aW4gZmF2b3Igb2YgdGhlIFBJIGFzIHRoZSBhdXRob3JpdGF0aXZlCmluZGljYXRpb24gb2YgdGhl IG5ldyBmcmFtaW5nLgoKTGFkYQoKPiAKPiBBbmR5Cj4gCj4gCj4gLS0tLS0gUmVwbHkgbWVzc2Fn ZSAtLS0tLQo+IEZyb206ICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAY2VzbmV0LmN6Pgo+IERh dGU6IFR1ZSwgTm92IDE2LCAyMDEwIDAyOjAzCj4gU3ViamVjdDogW05ldGNvbmZdIHdheSBmb3J3 YXJkIG9uIG5ldGNvbmYgRU9NCj4gVG86ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5j b20+LCA8cGhpbEBqdW5pcGVyLm5ldD4KPiBDYzogPG5ldGNvbmZAaWV0Zi5vcmc+Cj4gCj4gCj4g T24gTW9uLCAxNSBOb3YgMjAxMCAxNTozOToxNiArMDEwMCAoQ0VUKSwgTWFydGluIEJqb3JrbHVu ZAo+IDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6Cj4gPiBQaGlsIFNoYWZlciA8cGhpbEBqdW5pcGVy Lm5ldD4gd3JvdGU6Cj4gPiA+IE1hcnRpbiBCam9ya2x1bmQgd3JpdGVzOgo+ID4gPiA+PiBJTU8s IFBoaWwncyBmcmFtaW5nIGlzIHRoZSBiZXN0IGNob2ljZSBmcm9tIHRoZSBzZWN1cml0eSByZXZp ZXcKPiBQT1YuCj4gPiA+ID5JdCBzaG91bGQgYmUgY2xlYXIgYnkgbm93IHRoYXQgUGhpbCdzIHNv bHV0aW9uIGRvZXMgbm90IHNvbHZlIHRoZQo+ID4gPiA+aW5qZWN0aW9uIHByb2JsZW0uCj4gPiA+ IAo+ID4gPiBJIHRoaW5rIGhlJ3MgcmVmZXJyaW5nIHRvIG15IG9yaWdpbmFsIHN1Z2dlc3Rpb24g b2YgYSByZWFsLCBob25lc3QKPiA+ID4gdG8gZ29vZG5lc3MgZnJhbWluZyBtZWNoYW5pc20uCj4g PiA+IAo+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9j dXJyZW50L21zZzA2MjE2Lmh0bWwKPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwNjIxOS5odG1sCj4gPiAKPiA+IEkga25vdy4gIEFu ZCBJIHJlZmVycmVkIHRvOgo+ID4gCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA2NTU2Lmh0bWwKPiA+IAo+ID4gSWYgdGhlIGF0dGFj a2VyIGNhbiBpbnNlcnQgc29tZXRoaW5nIHRoYXQgbW9kaWZpZXMgdGhlIGN1cnJlbnQKPiA+IGVk aXQtY29uZmlnIHNvIHRoYXQgZS5nLiB0aGUgcGFzc3dvcmQgZm9yIGFuIGFkbWluIHVzZXIgaXMg Y2hhbmdlZCwKPiA+IHRoZW4gdGhlIGF0dGFja2VyIGNhbiBkbyBhbnl0aGluZy4KPiAKPiBUcnVl LCBidXQgdGhpcyBpcyBubyBtb3JlIGFuIGlzc3VlIGZvciB0aGUgdHJhbnNwb3J0IGxheWVyLiBJ IHdvdWxkCj4gc3VwcG9ydCBKdWVyZ2VuJ3Mgc3dpdGNob3ZlciBoYWNrIHdpdGggUGhpbCdzIGZy YW1pbmcsIEkgb25seSB0aGluayBpdAo+IHdvdWxkIGJlIGJldHRlciB0byBzaWduYWwgdGhlIG5l dyBmcmFtaW5nIHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIgdmlhIGEKPiBQSS4gV2hhdCBpZiB3ZSBo YWQgYm90aCAtIHRoZSBiYXNlOjEuMSBBTkQgdGhlIFBJcz8gQW4gaW1wbGVtZW50YXRpb24KPiB0 aGVuIGNvdWxkIGRlY2lkZSB3aGF0IHRvIHVzZS4KPiAKPiBJIGd1ZXNzIHRoaXMgd291bGQgYmUg dGhlIGJlc3Qgb3V0Y29tZSBvZiB0aGlzIHdob2xlIGFmZmFpciwKPiBlc3BlY2lhbGx5Cj4gaWYg aXQgY291bGQgYmUgZml4ZWQgbm93Lgo+IAo+IExhZGEKPiAKPiA+IAo+ID4gCj4gPiAvbWFydGlu Cj4gPiAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdAo+ID4gTmV0Y29uZkBpZXRmLm9yZwo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCj4gCj4gLS0gCj4gTGFkaXNs YXYgTGhvdGthLCBDRVNORVQKPiBQR1AgS2V5IElEOiBFNzRFOEMwQwo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QK PiBOZXRjb25mQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mCj4gCj4gCj4gCgotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJ RDogRTc0RThDMEMKCgo= ------=_Part_4_1289930779192 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBvYmplY3QgdG8gYW55IHBhcnNpbmcgb2YgWE1MIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIuICZu YnNwO0EgNDc0MWJpcyBwZWVyIG11c3QgYmUgYWJsZSB0byB0ZWxsIGJhc2UgMS4wIGZyb20gMS4x Ljxicj5UaGlzIGlzIGFsd2F5cyB0aGUgY29ycmVjdCBhbnN3ZXIgZm9yIHdoaWNoIGZyYW1pbmcu IFRoZXJlIGlzIG5vIHdheSBhZGRpdGlvbmFsIGZsYWdzIHNob3VsZCBiZSB1c2VkLjxicj48YnI+ PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7TGFkaXNsYXYgTGhv dGthJnF1b3Q7ICZsdDtsaG90a2FAY2VzbmV0LmN6Jmd0Ozxicj5EYXRlOiBUdWUsIE5vdiAxNiwg MjAxMCAwNzozNDxicj5TdWJqZWN0OiBbTmV0Y29uZl0gd2F5IGZvcndhcmQgb24gbmV0Y29uZiBF T008YnI+VG86ICZxdW90O0FuZHkgQmllcm1hbiZxdW90OyAmbHQ7aWV0ZkBhbmR5Ymllcm1hbi5j b20mZ3Q7PGJyPkNjOiAmcXVvdDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDttYmpAdGFpbC1m LmNvbSZndDssICZsdDtwaGlsQGp1bmlwZXIubmV0Jmd0OywgJmx0O25ldGNvbmZAaWV0Zi5vcmcm Z3Q7PGJyPjxicj48YnI+T24gw5p0LCAyMDEwLTExLTE2IGF0IDIzOjI4ICswODAwLCBBbmR5IEJp ZXJtYW4gd3JvdGU6PGJyPiZndDsgV2UgZG8gbm90IG5lZWQgMiB3YXlzIHRvIGluZGljYXRlIHRo ZSBuZXcgZnJhbWluZy4gQWxsIHBlZXJzIHdvdWxkPGJyPiZndDsgaGF2ZSB0byBzdXBwb3J0IGFs bCBvcHRpb25zLiAmbmJzcDtUaGVyZSBpcyBubyBjaG9pY2Ugb2YgZW9tIGFsbG93ZWQuICZuYnNw OzEuMTxicj4mZ3Q7IG1lYW5zIG5ldyBmcmFtaW5nLiAmbmJzcDtObyBleGNlcHRpb25zLjxicj48 YnI+T0ssIHRoZW4gSSBhbSBzbGlnaHRseSBpbiBmYXZvciBvZiB0aGUgUEkgYXMgdGhlIGF1dGhv cml0YXRpdmU8YnI+aW5kaWNhdGlvbiBvZiB0aGUgbmV3IGZyYW1pbmcuPGJyPjxicj5MYWRhPGJy Pjxicj4mZ3Q7IDxicj4mZ3Q7IEFuZHk8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLSBS ZXBseSBtZXNzYWdlIC0tLS0tPGJyPiZndDsgRnJvbTogJnF1b3Q7TGFkaXNsYXYgTGhvdGthJnF1 b3Q7ICZsdDtsaG90a2FAY2VzbmV0LmN6Jmd0Ozxicj4mZ3Q7IERhdGU6IFR1ZSwgTm92IDE2LCAy MDEwIDAyOjAzPGJyPiZndDsgU3ViamVjdDogW05ldGNvbmZdIHdheSBmb3J3YXJkIG9uIG5ldGNv bmYgRU9NPGJyPiZndDsgVG86ICZxdW90O01hcnRpbiBCam9ya2x1bmQmcXVvdDsgJmx0O21iakB0 YWlsLWYuY29tJmd0OywgJmx0O3BoaWxAanVuaXBlci5uZXQmZ3Q7PGJyPiZndDsgQ2M6ICZsdDtu ZXRjb25mQGlldGYub3JnJmd0Ozxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IE9uIE1vbiwgMTUg Tm92IDIwMTAgMTU6Mzk6MTYgKzAxMDAgKENFVCksIE1hcnRpbiBCam9ya2x1bmQ8YnI+Jmd0OyAm bHQ7bWJqQHRhaWwtZi5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7ICZndDsgUGhpbCBTaGFmZXIgJmx0 O3BoaWxAanVuaXBlci5uZXQmZ3Q7IHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0OyBNYXJ0aW4gQmpv cmtsdW5kIHdyaXRlczo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgSU1PLCBQaGlsJiMzOTtz IGZyYW1pbmcgaXMgdGhlIGJlc3QgY2hvaWNlIGZyb20gdGhlIHNlY3VyaXR5IHJldmlldzxicj4m Z3Q7IFBPVi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0O0l0IHNob3VsZCBiZSBjbGVhciBieSBub3cg dGhhdCBQaGlsJiMzOTtzIHNvbHV0aW9uIGRvZXMgbm90IHNvbHZlIHRoZTxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7aW5qZWN0aW9uIHByb2JsZW0uPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZn dDsgJmd0OyBJIHRoaW5rIGhlJiMzOTtzIHJlZmVycmluZyB0byBteSBvcmlnaW5hbCBzdWdnZXN0 aW9uIG9mIGEgcmVhbCwgaG9uZXN0PGJyPiZndDsgJmd0OyAmZ3Q7IHRvIGdvb2RuZXNzIGZyYW1p bmcgbWVjaGFuaXNtLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9t c2cwNjIxNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29u Zi9jdXJyZW50L21zZzA2MjE2Lmh0bWw8L2E+PGJyPiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDYy MTkuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3Vy cmVudC9tc2cwNjIxOS5odG1sPC9hPjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBJIGtub3cu ICZuYnNwO0FuZCBJIHJlZmVycmVkIHRvOjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50 L21zZzA2NTU2Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRj b25mL2N1cnJlbnQvbXNnMDY1NTYuaHRtbDwvYT48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsg SWYgdGhlIGF0dGFja2VyIGNhbiBpbnNlcnQgc29tZXRoaW5nIHRoYXQgbW9kaWZpZXMgdGhlIGN1 cnJlbnQ8YnI+Jmd0OyAmZ3Q7IGVkaXQtY29uZmlnIHNvIHRoYXQgZS5nLiB0aGUgcGFzc3dvcmQg Zm9yIGFuIGFkbWluIHVzZXIgaXMgY2hhbmdlZCw8YnI+Jmd0OyAmZ3Q7IHRoZW4gdGhlIGF0dGFj a2VyIGNhbiBkbyBhbnl0aGluZy48YnI+Jmd0OyA8YnI+Jmd0OyBUcnVlLCBidXQgdGhpcyBpcyBu byBtb3JlIGFuIGlzc3VlIGZvciB0aGUgdHJhbnNwb3J0IGxheWVyLiBJIHdvdWxkPGJyPiZndDsg c3VwcG9ydCBKdWVyZ2VuJiMzOTtzIHN3aXRjaG92ZXIgaGFjayB3aXRoIFBoaWwmIzM5O3MgZnJh bWluZywgSSBvbmx5IHRoaW5rIGl0PGJyPiZndDsgd291bGQgYmUgYmV0dGVyIHRvIHNpZ25hbCB0 aGUgbmV3IGZyYW1pbmcgdG8gdGhlIHRyYW5zcG9ydCBsYXllciB2aWEgYTxicj4mZ3Q7IFBJLiBX aGF0IGlmIHdlIGhhZCBib3RoIC0gdGhlIGJhc2U6MS4xIEFORCB0aGUgUElzPyBBbiBpbXBsZW1l bnRhdGlvbjxicj4mZ3Q7IHRoZW4gY291bGQgZGVjaWRlIHdoYXQgdG8gdXNlLjxicj4mZ3Q7IDxi cj4mZ3Q7IEkgZ3Vlc3MgdGhpcyB3b3VsZCBiZSB0aGUgYmVzdCBvdXRjb21lIG9mIHRoaXMgd2hv bGUgYWZmYWlyLDxicj4mZ3Q7IGVzcGVjaWFsbHk8YnI+Jmd0OyBpZiBpdCBjb3VsZCBiZSBmaXhl ZCBub3cuPGJyPiZndDsgPGJyPiZndDsgTGFkYTxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZn dDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IC9tYXJ0aW48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAm Z3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPiZndDsgJmd0OyBOZXRjb25mQGlldGYub3JnPGJy PiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwv YT48YnI+Jmd0OyA8YnI+Jmd0OyAtLSA8YnI+Jmd0OyBMYWRpc2xhdiBMaG90a2EsIENFU05FVDxi cj4mZ3Q7IFBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxi cj4mZ3Q7IE5ldGNvbmZAaWV0Zi5vcmc8YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+PGJy Pi0tIDxicj5MYWRpc2xhdiBMaG90a2EsIENFU05FVDxicj5QR1AgS2V5IElEOiBFNzRFOEMwQzxi cj48YnI+PGJyPjxicj48YnI+ ------=_Part_4_1289930779192-- From bertietf@bwijnen.net Thu Nov 18 08:45: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 AF0043A67B5 for ; Thu, 18 Nov 2010 08:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.843 X-Spam-Level: X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, J_CHICKENPOX_15=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 VT8C2tGUaa7o for ; Thu, 18 Nov 2010 08:45:08 -0800 (PST) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id CFBC23A6897 for ; Thu, 18 Nov 2010 08:45:07 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PJ7cP-0004l7-OI; Thu, 18 Nov 2010 17:45:53 +0100 Message-ID: <11219245CCA4442EB4E724876715DD96@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "t.petch" , "netconf" References: In-Reply-To: Date: Thu, 18 Nov 2010 17:37:52 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-14.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, 18 Nov 2010 16:45:10 -0000 Tom, revision 14 now references 4741bis and no lobnger RFC4741. May Iconsider your concern addressed? Bert Wijnen document shepherd ----- Original Message ----- From: "Andy Bierman" To: "t.petch" ; "Andy Bierman" ; "Bert \(IETF\) Wijnen" ; "netconf" Sent: Thursday, November 11, 2010 1:10 AM Subject: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt Ok... I will change the reference to 4741bis. Andy ----- Reply message ----- From: "t.petch" Date: Thu, Nov 11, 2010 01:46 Subject: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt To: "Andy Bierman" , "Bert \(IETF\) Wijnen" , "netconf" ----- Original Message ----- From: "Andy Bierman" To: "t.petch" ; "Bert (IETF) Wijnen" ; "netconf" Sent: Wednesday, November 10, 2010 4:12 PM Subject: RE: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt RFC 4741 sec 5.1 defines a datastore. The section heading is not called 'Terminology', but the term is defined. What is your concern? It defines a configuration datastore, which, as has been discussed before, is not the only kind of datastore, so the definition of datastore is a superset of the definition given in RFC4741 for configuration datastore. As I said, there is a definition of datastore unqualified in 4741bis so I think the reference should be change to that. Tom Petch Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of t.petch Sent: Wednesday, November 10, 2010 3:59 AM To: Bert (IETF) Wijnen; netconf Subject: Re: [Netconf] Fwd: I-D Action:draft-ietf-netconf-with-defaults-13.txt ----- Original Message ----- From: "Bert (IETF) Wijnen" To: "netconf" Sent: Tuesday, November 09, 2010 8:48 AM > Netcon WG participants, > > This revision is the result of IETF LC and IESG review. > While I am checking with the IESG if this revision indeed > addresses all their concerns, pls take a look and speak > up if you see anything weird. > > Do not re-open old issues that we have already decided on. Bert Trouble is, I do not know what issues we have decided on, and re-reading the archives leaves me none the wiser. There is an issue that I raised in August, that caused changes to be made, that were objected to, that caused changes to be unmade, at the end of which the I-D remains wrong (IMO). I am unclear if you regard this as a beaten-to-death issue not to be re-raised, but I expect Alfred will raise it as an erratum if it is not resolved now so here goes. s1.1 says " The following terms are defined in [RFC4741]: o client o datastore" RFC4741 does not have a definitions section; s5.1 defines a configuration datastore which is the term used extensively, along with target datastore, but 'datastore' per se is never defined. Perhaps we should reference 4741bis instead Tom Petch > Bert and Mehmet > > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > Date: Mon, 08 Nov 2010 20:30:02 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of > the IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-13.txt > Pages : 32 > Date : 2010-11-08 > > 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-13.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -------------------------------------------------------------------------------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietfc@btconnect.com Fri Nov 19 01:55: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 D7E4B3A68F1 for ; Fri, 19 Nov 2010 01:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=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 Tp8O-3WMMUzO for ; Fri, 19 Nov 2010 01:55:29 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 669C73A6890 for ; Fri, 19 Nov 2010 01:55:28 -0800 (PST) Received: from host81-156-207-177.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.177]) by c2bthomr14.btconnect.com with SMTP id ASF19999; Fri, 19 Nov 2010 09:56:14 +0000 (GMT) Message-ID: <008a01cb87c7$5b7929e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert Wijnen \(IETF\)" , "netconf" References: <11219245CCA4442EB4E724876715DD96@BertLaptop> Date: Fri, 19 Nov 2010 09:53:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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.0A0B0301.4CE649AC.00D5, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4CE649BF.0236,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 09:55:30 -0000 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "t.petch" ; "netconf" Cc: Sent: Thursday, November 18, 2010 5:37 PM > Tom, revision 14 now references 4741bis and no lobnger RFC4741. > > May Iconsider your concern addressed? Ok. When next this is revised, you may want to amend: s8 The security consideration apply to either The security considerations apply or The security consideration applies s1.2 The actual nodes omitted depends to The actual nodes omitted depend s1 knowledge can be obtained a document to knowledge can be obtained from a document Tom Petch > Bert Wijnen > document shepherd > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" ; "Andy Bierman" ; > "Bert \(IETF\) Wijnen" ; "netconf" > Sent: Thursday, November 11, 2010 1:10 AM > Subject: Re: [Netconf] Fwd: > I-DAction:draft-ietf-netconf-with-defaults-13.txt > > > Ok... I will change the reference to 4741bis. > > Andy > > > ----- Reply message ----- > From: "t.petch" > Date: Thu, Nov 11, 2010 01:46 > Subject: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt > To: "Andy Bierman" , "Bert \(IETF\) Wijnen" > , "netconf" > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" ; "Bert (IETF) Wijnen" > ; "netconf" > Sent: Wednesday, November 10, 2010 4:12 PM > Subject: RE: [Netconf] Fwd: > I-DAction:draft-ietf-netconf-with-defaults-13.txt > > > RFC 4741 sec 5.1 defines a datastore. > The section heading is not called 'Terminology', but the term is defined. > What is your concern? > > It defines a configuration datastore, which, as has been discussed before, > is > not the only kind of datastore, so the definition of datastore is a superset > of > the definition given in RFC4741 for configuration datastore. As I said, > there > is a definition of datastore unqualified in 4741bis so I think the reference > should be change to that. > > Tom Petch > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of > t.petch > Sent: Wednesday, November 10, 2010 3:59 AM > To: Bert (IETF) Wijnen; netconf > Subject: Re: [Netconf] Fwd: I-D > Action:draft-ietf-netconf-with-defaults-13.txt > > ----- Original Message ----- > From: "Bert (IETF) Wijnen" > To: "netconf" > Sent: Tuesday, November 09, 2010 8:48 AM > > > Netcon WG participants, > > > > This revision is the result of IETF LC and IESG review. > > While I am checking with the IESG if this revision indeed > > addresses all their concerns, pls take a look and speak > > up if you see anything weird. > > > > Do not re-open old issues that we have already decided on. > > Bert > > Trouble is, I do not know what issues we have decided on, and re-reading the > archives leaves me none the wiser. There is an issue that I raised in > August, > that caused changes to be made, that were objected to, that caused changes > to be > unmade, at the end of which the I-D remains wrong (IMO). I am unclear if > you > regard this as a beaten-to-death issue not to be re-raised, but I expect > Alfred > will > raise it as an erratum if it is not resolved now so here goes. > > s1.1 says > " The following terms are defined in [RFC4741]: > o client > o datastore" > > RFC4741 does not have a definitions section; s5.1 defines a configuration > datastore which is the term used extensively, along with target datastore, > but > 'datastore' per se is never defined. > > Perhaps we should reference 4741bis instead > > Tom Petch > > > Bert and Mehmet > > > > -------- Original Message -------- > > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > > Date: Mon, 08 Nov 2010 20:30:02 -0800 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: netconf@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Network Configuration Working Group of > > the > IETF. > > > > > > Title : With-defaults capability for NETCONF > > Author(s) : A. Bierman, B. Lengyel > > Filename : draft-ietf-netconf-with-defaults-13.txt > > Pages : 32 > > Date : 2010-11-08 > > > > 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-13.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > ------------------------------------------------------------------------------ -- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Fri Nov 19 02:04: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 355D33A68B9 for ; Fri, 19 Nov 2010 02:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.843 X-Spam-Level: X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, J_CHICKENPOX_15=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 Fr3fPAYogqdZ for ; Fri, 19 Nov 2010 02:04:23 -0800 (PST) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id B24503A68A3 for ; Fri, 19 Nov 2010 02:04:21 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PJNq9-0005d6-Li; Fri, 19 Nov 2010 11:05:09 +0100 Message-ID: <94FC03D1FD914C2C8BBDB6D6F3C2AC48@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "t.petch" , "netconf" References: <11219245CCA4442EB4E724876715DD96@BertLaptop> <008a01cb87c7$5b7929e0$4001a8c0@gateway.2wire.net> In-Reply-To: <008a01cb87c7$5b7929e0$4001a8c0@gateway.2wire.net> Date: Fri, 19 Nov 2010 11:04:59 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 10:04:24 -0000 Thanks Tom. I ecpect the RFC-Editor tio catch the remaining editorial changes too. If not, I herewith ask the editors/authors of the document to keep an eye on this during AUTH48. Bert ----- Original Message ----- From: "t.petch" To: "Bert Wijnen (IETF)" ; "netconf" Cc: Sent: Friday, November 19, 2010 9:53 AM Subject: Re: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-14.txt ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "t.petch" ; "netconf" Cc: Sent: Thursday, November 18, 2010 5:37 PM > Tom, revision 14 now references 4741bis and no lobnger RFC4741. > > May Iconsider your concern addressed? Ok. When next this is revised, you may want to amend: s8 The security consideration apply to either The security considerations apply or The security consideration applies s1.2 The actual nodes omitted depends to The actual nodes omitted depend s1 knowledge can be obtained a document to knowledge can be obtained from a document Tom Petch > Bert Wijnen > document shepherd > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" ; "Andy Bierman" > ; > "Bert \(IETF\) Wijnen" ; "netconf" > > Sent: Thursday, November 11, 2010 1:10 AM > Subject: Re: [Netconf] Fwd: > I-DAction:draft-ietf-netconf-with-defaults-13.txt > > > Ok... I will change the reference to 4741bis. > > Andy > > > ----- Reply message ----- > From: "t.petch" > Date: Thu, Nov 11, 2010 01:46 > Subject: [Netconf] Fwd: I-DAction:draft-ietf-netconf-with-defaults-13.txt > To: "Andy Bierman" , "Bert \(IETF\) Wijnen" > , "netconf" > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" ; "Bert (IETF) Wijnen" > ; "netconf" > Sent: Wednesday, November 10, 2010 4:12 PM > Subject: RE: [Netconf] Fwd: > I-DAction:draft-ietf-netconf-with-defaults-13.txt > > > RFC 4741 sec 5.1 defines a datastore. > The section heading is not called 'Terminology', but the term is defined. > What is your concern? > > It defines a configuration datastore, which, as has been discussed before, > is > not the only kind of datastore, so the definition of datastore is a > superset > of > the definition given in RFC4741 for configuration datastore. As I said, > there > is a definition of datastore unqualified in 4741bis so I think the > reference > should be change to that. > > Tom Petch > > Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of > t.petch > Sent: Wednesday, November 10, 2010 3:59 AM > To: Bert (IETF) Wijnen; netconf > Subject: Re: [Netconf] Fwd: I-D > Action:draft-ietf-netconf-with-defaults-13.txt > > ----- Original Message ----- > From: "Bert (IETF) Wijnen" > To: "netconf" > Sent: Tuesday, November 09, 2010 8:48 AM > > > Netcon WG participants, > > > > This revision is the result of IETF LC and IESG review. > > While I am checking with the IESG if this revision indeed > > addresses all their concerns, pls take a look and speak > > up if you see anything weird. > > > > Do not re-open old issues that we have already decided on. > > Bert > > Trouble is, I do not know what issues we have decided on, and re-reading > the > archives leaves me none the wiser. There is an issue that I raised in > August, > that caused changes to be made, that were objected to, that caused changes > to be > unmade, at the end of which the I-D remains wrong (IMO). I am unclear if > you > regard this as a beaten-to-death issue not to be re-raised, but I expect > Alfred > will > raise it as an erratum if it is not resolved now so here goes. > > s1.1 says > " The following terms are defined in [RFC4741]: > o client > o datastore" > > RFC4741 does not have a definitions section; s5.1 defines a configuration > datastore which is the term used extensively, along with target datastore, > but > 'datastore' per se is never defined. > > Perhaps we should reference 4741bis instead > > Tom Petch > > > Bert and Mehmet > > > > -------- Original Message -------- > > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-13.txt > > Date: Mon, 08 Nov 2010 20:30:02 -0800 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: netconf@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Network Configuration Working Group of > > the > IETF. > > > > > > Title : With-defaults capability for NETCONF > > Author(s) : A. Bierman, B. Lengyel > > Filename : draft-ietf-netconf-with-defaults-13.txt > > Pages : 32 > > Date : 2010-11-08 > > > > 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-13.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > ------------------------------------------------------------------------------ -- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From mehmet.ersue@nsn.com Fri Nov 26 09:17: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 6CF2828C0FB for ; Fri, 26 Nov 2010 09:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_46=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 U5NKlLDTKGp1 for ; Fri, 26 Nov 2010 09:17:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7BC8028C101 for ; Fri, 26 Nov 2010 09:17:34 -0800 (PST) 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 oAQHIaoU018274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Nov 2010 18:18:36 +0100 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 oAQHIYh1010581 for ; Fri, 26 Nov 2010 18:18:36 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Nov 2010 18:18:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2010 18:18:35 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64014847DB@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AIs from IETF 79 NETCONF Session thread-index: AcuIxg6Zt1XMj2ZbTua4lTI8J28lXQExrKOQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 26 Nov 2010 17:18:35.0987 (UTC) FILETIME=[F58EC230:01CB8D8D] Subject: [Netconf] AIs from IETF 79 NETCONF Session 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, 26 Nov 2010 17:17:35 -0000 Hi All, please find below the summary of action items and corresponding hums from the NETCONF session in IETF #79 for confirmation. Please let us=20 know whether we missed something. - Move authentication objects to separate document? Hum in favour, discussion will be continued on ML - Copy-config on non-authorized data -> Basic approach in 4741bis and nacm is fine, documentation can be improved. - Access-denied notification: Not much interest. If anyone wants can bring concrete proposal to ML. - W3C XML access control: Juergen S. took an AI to post pointers to generic XML access control work to ML. - Open issue #8 in the I-D on nacm:secure and nacm:very-secure extensions=20 being optional to support, via a YANG feature: Wes will look at it as security person and post analysis to ML. - Change name: System in the name is misleading. Change to netconf-server-notification. - Authentication failure notification will be discussed on ML. Bert & Mehmet From mehmet.ersue@nsn.com Fri Nov 26 09:17: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 7C3D328C101 for ; Fri, 26 Nov 2010 09:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.695 X-Spam-Level: X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_46=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 2UBnYzxms31n for ; Fri, 26 Nov 2010 09:17:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BCF7528C102 for ; Fri, 26 Nov 2010 09:17:38 -0800 (PST) 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 oAQHIgiA018471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Nov 2010 18:18:42 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAQHIaIW010636 for ; Fri, 26 Nov 2010 18:18:41 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Nov 2010 18:18:41 +0100 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_01CB8D8D.F8835500" Date: Fri, 26 Nov 2010 18:18:40 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64014847DC@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 79 NETCONF Session Minutes thread-index: AcuIxfysvrwoNFw7R/2gcNQWxZGCxwEx0b0g From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 26 Nov 2010 17:18:41.0100 (UTC) FILETIME=[F89AF0C0:01CB8D8D] Subject: [Netconf] Draft IETF 79 NETCONF Session Minutes 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, 26 Nov 2010 17:17:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8D8D.F8835500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find attached the draft merged minutes of the IETF 79 NETCONF=20 session. Pls send us your change requests by December 10, 2010. Special thanks to the minute takers Juergen Schoenwaelder, Lada Lhotka=20 and Jabber scribe Wes Hardaker. <<101120_IETF 79_NETCONF Session Minutes_.txt>>=20 Bert & Mehmet ------_=_NextPart_001_01CB8D8D.F8835500 Content-Type: text/plain; name="101120_IETF 79_NETCONF Session Minutes_.txt" Content-Transfer-Encoding: base64 Content-Description: 101120_IETF 79_NETCONF Session Minutes_.txt Content-Disposition: attachment; filename="101120_IETF 79_NETCONF Session Minutes_.txt" TWludXRlcyBvZiB0aGUgTkVUQ09ORiBXRyBzZXNzaW9uLCA4IE5vdmVtYmVyIDIwMTANClRoZSBz ZXNzaW9uIHN0YXJ0ZWQgYXQgMTM6MDUsIGJsdWUgc2hlZXRzIHdlcmUgY2lyY3VsYXRlZC4NCg0K TWFueSB0aGFua3MgdG8gdGhlIG1pbnV0ZSB0YWtlcnMgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBM YWRhIExob3RrYSBhbmQgSmFiYmVyIHNjcmliZSBXZXMgSGFyZGFrZXINCg0KKiBBZ2VuZGEgQmFz aGluZw0KICAtIG5vIGNoYW5nZSB0byB0aGUgYWdlbmRhDQoNCiogQWJyZXZpYXRpb24gb2YgYWN0 b3JzDQogICBCVyAtIEJlcnQgV2lqbmVuDQogICBNRSAtIE1laG1ldCBFcnN1ZQ0KICAgQUIgLSBB bmR5IEJpZXJtYW4NCiAgIEpTIC0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQogICBXSCAtIFdlcyBI YXJkYWtlcg0KDQpTdGF0dXMgb2YgdGhlIGRyYWZ0cw0KPT09PT09PT09PT09PT09PT09PT0NCg0K LSBBbmR5OiBJIGhhdmUgYSBuZXcgdmVyc2lvbiBvZiAtd2l0aC1kZWZhdWx0cyBTaG91bGQgSSBz ZW5kIGl0Pw0KICBCZXJ0OiBSZXBvc2l0b3J5IHdpbGwgb3BlbiB0b2RheSwgcGxlYXNlIHNlbmQg aXQuDQoNCiogTkVUQ09ORiBBY2Nlc3MgQ29udHJvbCBNb2RlbA0KDQotIEp1ZXJnZW46IEkgYW0g aW4gZmF2b3Igb2YgbW92aW5nIGF1dGhvcml6YXRpb24gb3V0IG9mIHRoZSBkb2N1bWVudCwgbGF5 ZXJpbmcgaXMgZGVzaXJhYmxlLCBpdCdzIGJldHRlciB0byBzdGljayB3aXRoIGFjY2VzcyBjb250 cm9sIG9ubHkuDQogIEJlcnQ6IFdlIGNhbiBnZXQgaXQgY29tcGxldGVkIHdpdGhvdXQgZmluaXNo aW5nIGFsbCB0aGUgYXV0aGVudGljYXRpb24gZGV0YWlscyAobG9jYWwgZ3JvdXBzKSwgSSBhbSBp biBmYXZvciBvZiBmaW5pc2hpbmcgaXQgYXNhcC4NCi0gSnVlcmdlbjogV2UgY2FuIGRvIGJldHRl ciB3aXRoIGdyb3VwIG5hbWUgcHJvdmlzaW9uaW5nIHRoYW4gaW4gU05NUC4NCi0gSnVlcmdlbjog UmFkaXVzIGhhcyBhIHNlcGFyYXRlIGlzc3VlIC0gc3NoIGF1dGhlbnRpY2F0ZXMgYmVmb3JlIGtu b3dpbmcgdGhlIHN1YnN5c3RlbSwgc28gdGhlcmUgaXMgYSBjaGlja2VuLWFuZC1lZ2cgcHJvYmxl bSB3aXRoIFJhZGl1cy4NCiAgQW5keTogQ29uZmlybXMsIGluIE9wZW5TU0ggdGhlIGF1dGggcHJv Y2VzcyBpcyBpbmRlZWQgc2VxdWVuY2VkLg0KICBCVyBhc2tlZCB3aG8gaXMgaW4gZmF2b3VyIG9m IGtlZXBpbmcgdGhlIGRvY3VtZW50IGFzIGlzIGFuZCB3aG8gaXMgaW4gZmF2b3VyIG9mIG1vdmUg YXV0aGVudGljYXRpb24gZGV0YWlscyBvdXQgb2YgdGhlIGFjY2VzcyBjb250cm9sIGRvY3VtZW50 LiAgICAgIEhlIGhlYXJkIGEgaHVtIGluIGZhdm91ciBvZiBtb3ZpbmcgYXV0aGVudGljYXRpb24g b2JqZWN0cyBvdXQgb2YuDQoNCiAgLSBVc2VyIHRvIGdyb3VwIG1hcHBpbmdzPw0KDQogIEl0IHdh cyBkaXNjdXNzZWQgdG8ga2VlcCB0aGUgY3VycmVudCB1c2VyIHRvIGdyb3VwIG1hcHBpbmcuIEhv d2V2ZXIsIHRoZSBkb2N1bWVudCBzaG91bGQgY29uc2lkZXIgZHluYW1pY2FsbHkgcHJvdmlzaW9u ZWQgdXNlciB0byBncm91cCBtYXBwaW5ncyBpbiB0aGUgZWxlbWVudHMgb2YgcHJvY2VkdXJlLg0K LSBKdWVyZ2VuOiBJIHRoaW5rIGl0IGRvZXNuJ3QgYmVsb25nIGhlcmUuDQogIEFuZHk6IEl0IGlz IGEgcGFydCBvZiBhY2Nlc3MgY29udHJvbCwgb25jZSB5b3UgYXJlIGF1dGhlbnRpY2F0ZWQsIHdo YXQgZ3JvdXBzIGFyZSB5b3UgYSBtZW1iZXIgb2Y/DQoNCiAgSXQgaXMgdW5jbGVhciB5ZXQgd2hl dGhlciBvciBob3cgdG8gcmVwcmVzZW50IG9wZXJhdGlvbmFsIHN0YXRlIHJlcHJlc2VudGluZyB1 c2VyIHRvIGdyb3VwIG1hcHBpbmdzLg0KICBKdWVyZ2VuOiBDYW4geW91IHJlcGhyYXNlIHdoYXQg d2UgYXJlIHRhbGtpbmcgYWJvdXQ/IElzIHRoZSB1c2VyLXRvLWdyb3VwIGEgc2VwYXJhdGUgbGlz dD8NCiAgQW5keTogWWVzLiBHcm91cHMgb25seSBhZmZlY3QgYXV0aG9yaXphdGlvbi4NCg0KICAt IFdoYXQgdG8gZG8gYWJvdXQgY29weS1jb25maWcgc2lkZSBlZmZlY3RzPw0KICAgIElmIGEgdXNl ciB3aXRoIHBhcnRpYWwgYWNjZXNzIHVzZXMgY29weS1jb25maWcsIHRoZSB1c2VyIGdldHMgdGhl IGNvbmZpZyBzaGUgaXMgYWxsb3dlZCB0byByZWFkLiBJZiBzb21lIHJvb3QgdXNlciBkb2VzIGFu IDxjb3B5LWNvbmZpZz4gd2l0aCB0aGlzIGNvbmZpZywgYWxsIG5vdCBpbmNsdWRlZCBvYmplY3Rz IGFyZSBkaXNjYXJkZWQuIA0KDQotIEJlcnQ6IFdoZW4gc29tZWJvZHkgY29waWVzIHRoZSBjb25m aWcgYW5kIGRvZXNuJ3QgZ2V0IGl0IGFsbCwgdGhlbiB0aGUgc2VydmVyIHNob3VsZCB0ZWxsIHRo ZSBjbGllbnQuDQogIEFuZHk6IFRoaXMgaXMgYSBjYXNlIGZvciBSUEMgd2FybmluZy4NCiAgV2Vz IEhhcmRha2VyOiA8Y29weS1jb25maWc+IG9ubHkgbWFrZXMgc2Vuc2UgYXMgYSByb290LW9ubHkg YWN0aW9uLg0KICBBbmR5IGFncmVlcy4NCiAgQmVydDogSXMgdGhhdCB3aGF0IHdlIHdhbnQgdG8g ZG8/IFNob3VsZCBpdCBiZSBzdGF0ZWQgaW4gY29weS1jb25maWcgZGVzY3JpcHRpb24/DQogIEFu ZHk6IEl0IGRvZXMgc2F5IGl0J3MgYWxsIG9yIG5vdGhpbmcuDQogIE1hcnRpbiBCavZya2x1bmQg KGphYmJlcikgYWdyZWVzIHdpdGggV2VzLg0KICBBbmR5OiBJJ2xsIHdyaXRlIHNvbWUgdGV4dCBh Ym91dCBpdC4NCg0KICAgQWZ0ZXIgZGlzY3Vzc2lvbiwgaXQgd2FzIGNvbmNsdWRlZCB0aGF0IHRo ZSBiYXNpYyBhcHByb2FjaCBpbiA0NzQxYmlzIGFuZCBuYWNtIGlzIGZpbmUsIHBlcmhhcHMgZG9j dW1lbnRhdGlvbiBjYW4gc3RpbGwgYmUgaW1wcm92ZWQuDQoNCiAgLSBTaG91bGQgd2UgYWRkIGFu IDxhY2Nlc3MtZGVuaWVkPiBub3RpZmljYXRpb24/DQoNCi0gV2VzOiBJIHBlcnNvbmFsbHkgZG9u J3QgY2FyZSBidXQgc29tZSBwZW9wbGUgd2FudCB0byBrbm93IHRoYXQuDQogIERhbjogV2UgaGF2 ZSBzdWNoIG5vdGlmaWNhdGlvbiBpbiBTTk1QLg0KICBNYXJ0aW46IEl0IGlzIG5vdCBuZWVkZWQs IHdlIGRvbid0IGhhdmUgaXQgaW4gU05NUCwgdGhlcmUgaXMgb25seSBvbmUgcmVwb3J0aW5nIGF1 dGguIGZhaWx1cmVzLg0KDQogIFRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgbXVjaCBpbnRlcmVz dC4gSWYgYW55b25lIGZlZWxzIHN0cm9uZ2x5IGFib3V0IGl0LCBhIGNvbmNyZXRlIHByb3Bvc2Fs IHNob3VsZCBiZSBicm91Z2h0IHRvIHRoZSBtYWlsaW5nIGxpc3QuDQoNCg0KVzNDIFhNTCBhY2Nl c3MgY29udHJvbA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgVGhlcmUgYXJlIGdlbmVyaWMgWE1M IGFjY2VzcyBjb250cm9sIHByb3Bvc2FscywgdGhlIFdHIG1pZ2h0IHdhbnQgdG8gZmluZCBvdXQg d2hldGhlciB0aGV5IGFyZSBhcHBsaWNhYmxlIGFuZCBkb2N1bWVudCAocGVyaGFwcyBwYXJ0IG9m IHRoZSBkb2N1bWVudCB3cml0ZXVwKSB0aGUgY29uY2x1c2lvbi4NCiAgICBBQiBhbmQgSlMgbWFk ZSB0aGUgcG9pbnQgdGhhdCBhIE5FVENPTkYgZGF0YWJhc2UgaXMgbm90IFhNTCwgTkVUQ09ORiB1 c2VzIFhNTCBvbmx5IGFzIGEgc2VyaWFsaXphdGlvbiBmb3JtYXQuIA0KICAgIEJlcnQ6IFdlIHNo b3VsZCBiZSBhdCBsZWFzdCBiZSBhd2FyZSBvZiB0aGlzIGRvY3VtZW50IHRvIGJlIGFibGUgdG8g YW5zd2VyIHF1ZXN0aW9ucy4NCiAgICBKUyB0b29rIGFuIGFjdGlvbiBpdGVtIHRvIHBvc3QgcG9p bnRlcnMgdG8gZ2VuZXJpYyBYTUwgYWNjZXNzIGNvbnRyb2wgd29yayB0byB0aGUgV0cgbWFpbGlu ZyBsaXN0Lg0KDQogIC0gTW9kdWxlIGlkZW50aWZpY2F0aW9uIChpc3N1ZSAxLiBpbiB0aGUgSUQp DQoNCi0gV2VzOiBXaHkgYXJlIHdlIGNyZWF0aW5nIGV4Y2VwdGlvbj8gSXQncyBhIHVzZXIgaW50 ZXJmYWNlIGlzc3VlLg0KICBNYXJ0aW46IEluIGZhdm9yIG9mIG1vZHVsZSBuYW1lLCBpdCBoYXMg dG8gYmUgaHVtYW4gcmVhZGFibGUsIHRoZSBOQUNNIGRhdGEgaXMgcGFydCBvZiBjb25maWcsIFhN TCBpcyBub3QuDQoNCiAgSlMgc3VnZ2VzdHMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNob2ljZSBp cyBjb25zaXN0ZW50IHdpdGggL25ldGNvbmYtc3RhdGUvc2NoZW1hcy9pZGVudGlmaWVyLg0KDQog IC0gUmVndWxhciBleHByZXNzaW9ucyAoaXNzdWUgMy4gaW4gdGhlIElEKQ0KDQogICAgTm9ib2R5 IHNlZW1zIHRvIGFzayBmb3IgaXQuDQogICAgQW5keTogSSBhbSBhZ2FpbnN0IHJlZ3VsYXIgZXhw cmVzc2lvbnMuDQoNCiAgLSBYUEFUSCBleHByZXNzaW9ucyAoaXNzdWUgNC4gaW4gdGhlIElEKQ0K DQogICAgTWFydGluOiBJIGFtIGFnYWluc3QgWFBhdGgsIEFDIGlzIHN1cHBvc2VkIHRvIGJlIHNp bXBsZS4gTm9ib2R5IHNlZW1zIHRvIGFzayBmb3IgaXQuIFRhaWwtZiBkb2VzIG5vdCBzdXBwb3J0 IGZ1bGwgWFBBVEguDQoNCiAgLSBhY2Nlc3MtZGVuaWVkIChpc3N1ZSA1LiBpbiB0aGUgSUQpDQoN CiAgICBBbHJlYWR5IGRpc2N1c3NlZC4NCg0KICAtIHBhdGggZXhwcmVzc2lvbnMgKGlzc3VlIDYu IGluIHRoZSBJRCkNCg0KICAgIE5lZWQgdG8gY2hlY2sgd2hhdCBZQU5HIHNheXMgYWJvdXQgaW5z dGFuY2UgaWRlbnRpZmllciBhbmQgcGF0aCBleHByZXNzaW9ucy4NCg0KICAtIGV4dGVybmFsIGFj Y2VzcyBjb250cm9sIChpc3N1ZSA3LiBpbiB0aGUgSUQpDQoNCiAgICBOb3QgYmVpbmcgZG9uZSBu b3cgc2luY2Ugd2UgZG8gbm90IHBsYW4gdG8gcmVwb3J0IG9wZXJhdGlvbmFsIHN0YXRlLg0KDQog IC0gbmFjbTpzZWN1cmUgYW5kIG5hY206dmVyeS1zZWN1cmUgKGlzc3VlIDguIGluIHRoZSBJRCkN Cg0KICAgIFRoaXMgaXMgZGVzaWduZWQgdG8gc2ltcGxpZnkgb3BlcmF0aW9uYWwgYWNjZXNzIGNv bnRyb2wgZGVwbG95bWVudHMuDQoNCiAgIFdlczogSXMgaXQgc28gdGhhdCBldmVuIGlmIHRoZSBn bG9iYWwgY29uZmlnIHNheXMgZXZlcnl0aGluZyBpcyBhY2Nlc3NpYmxlLCB0aGlzIHRhZyBtYWtl cyBjZXJ0YWluIGRhdGEgaGlkZGVuPw0KICAgQW5keTogWWVzLg0KICAgV2VzOiBEb2VzIGl0IGFw cGx5IHRvIHJvb3Q/DQogICBBbmR5OiBOby4NCiAgIFdlczogV2hvIGlzIHRoZSByb290Pw0KICAg QW5keTogVGhpcyBpcyBpbXBsaWNpdC4NCiAgIFdlczogSSBhbSBhbHNvIHdvcnJpZWQgYWJvdXQg Y29tcGxleGl0eS4NCiAgIEFuZHk6IFRoaXMgaXMgYmFzaWNhbGx5IGEgZm9ybWFsaXplZCBpbmZv cm1hdGlvbiB0aGF0IG5vcm1hbGx5IHJlc2lkZXMgaW4gYSBkZXNjcmlwdGlvbi4NCg0KICAgIEpT IG1lbnRpb25zIHRoYXQgdGhlcmUgd2lsbCBsaWtlbHkgYmUgbWFueSBkaXNjdXNzaW9ucyB3aGF0 IG11c3QgYmUgdGFnZ2VkIGFzIG5hY206c2VjdXJlIGFuZCBuYWNtOnZlcnktc2VjdXJlIGFjcm9z cyB3b3JraW5nIGdyb3Vwcy4NCg0KICAgIFdIIGFza3Mgd2hldGhlciBXR3Mgbm90IGJlIGJldHRl ciBhZHZpY2VkIHRvIHByb2R1Y2UgZGVmYXVsdCBBQ00gY29uZmlncyB0aGF0IGFjaGlldmUgdGhl IHNhbWUgdGhpbmc/IFRoaXMgd291bGQgcGVyaGFwcyBiZSBtb3JlIGZsZXhpYmxlLiBXZSBzaG91 bGQgdHJ5IHRvIGdldCBlYXJseSBzZWN1cml0eSBhZHZpY2Ugb24gdGhpcy4NCg0KICBXZXM6IFdo YXQncyB0aGUgZ29hbCBoZXJlPyBPcGVyYXRpb25hbCBlbnZpcm9ubWVudHMgaGF2ZSB2ZXJ5IGRp ZmZlcmVudCB2aWV3cG9pbnRzIG9uIHdoYXQgc2hvdWxkIGJlIHNlY3VyZS4NCi0gV2VzOiBUaGlz IGluZm9ybWF0aW9uIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gYSB3YXkgdGhhdCBzdGFuZHMgb3V0 LCBub3QganVzdCBhcyBzb21lIGF0dHJpYnV0ZXMgaGlkZGVuIGluIHRoZSBzdHJ1Y3R1cmUuDQot IEJlcnQ6IFRoaXMgaXMgYSB0b3BpYyB3aXRoIGEgbnVtYmVyIG9mIGFzcGVjdHMgdG8gY29uc2lk ZXIuDQotIE1hcnRpbjogVGhpcyBpcyBqdXN0IGEgKmRlZmF1bHQqIHNlY3VyaXR5LCBzaXRlcyBj YW4gY2hhbmdlIGl0Lg0KDQogIC0gZGVmYXVsdCBhY2Nlc3MgbGV2ZWwgKGlzc3VlIDkuIGluIHRo ZSBJRCkNCiAgICBXZXM6IEdlbmVyYWxseSB5b3UgY2FuIGRvIHdoYXRldmVyIHlvdSB3YW50Lg0K DQoqIE5FVENPTkYgU3lzdGVtIE5vdGlmaWNhdGlvbnMNCg0KICBBbmR5IHJldmlld3MgdGhlIGxh dGVzdCBjaGFuZ2VzLg0KICBKUyBsaWtlcyB0byBzdWdnZXN0IHNvbWUgcmVuYW1pbmcgdG8gYXZv aWQgc3lzdGVtIGFzIGEgdGVybSwgdGhlIG5vdGlmaWNhdGlvbnMgYXJlIG5ldGNvbmYgc2VydmVy IHNwZWNpZmljIGFuZCB3ZSBzaG91bGQgbWFrZSB0aGlzIGNsZWFyIGJ5IHNvbWUgZG9jdW1lbnQg cmVuYW1pbmcuDQotIE1hcnRpbjogSXMgdGhpcyBzeXN0ZW0gbm90aWZpY2F0aW9ucyBvdmVyIG5l dGNvbmYgb3IgbmV0Y29uZiBzZXJ2ZXIgbm90aWZpY2F0aW9ucz8NCiAgQW5keTogbmV0Y29uZiBz ZXJ2ZXIgbm90aWZpY2F0aW9ucy4NCi0gU29tZWJvZHkgZnJvbSBhdWRpZW5jZTogRG9lcyB0aGUg YXV0aGVudGljYXRpb24tZmFpbGVkIG5vdGlmaWNhdGlvbiBiZWxvbmcgaGVyZT8NCiAgQW5keTog Tm8sIHdlIGRvbid0IGhhdmUgaXQgaGVyZSBidXQgSSBkb24ndCBoYXZlIGEgcHJvYmxlbSBhZGRp bmcgaXQuDQogIEpTIG1lbnRpb25zIHRoYXQgdGhlcmUgaXMgaW4gcHJpbmNpcGxlIGEgZGlzdGlu Y3Rpb24gYmV0d2VlbiB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZCBzZXNzaW9uIGF1dGhvcml6YXRp b24uIFJBRElVUyBsaWtlcyB0byBkZWFsIHdpdGggdGhpcyBpbiBhIHNpbmdsZSBvcGVyYXRpb24s IGhvd2V2ZXIgU1NIIG1ha2VzIGl0IGhhcmQgdG8ga25vdyB3aGV0aGVyIGEgTkVUQ09ORiBzZXNz aW9uIGlzIGJlaW5nIHJlcXVlc3RlZCB3aGVuIHVzZXIgYXV0aGVudGljYXRpb24gaXMgdGFraW5n IHBsYWNlLiANCklmIHdlIGRlZmluZSBhbiAiYXV0aGVudGljYXRpb24iIGZhaWx1cmUgbm90aWZp Y2F0aW9uLCB3ZSBwcm9iYWJseSBuZWVkIHRvIGJlIGNsZWFyIHdoZXRoZXIgdGhhdCByZWFsbHkg bWVhbnMgImF1dGhlbnRpY2F0aW9uIGZhaWx1cmUiIG9yIGJvdGggYXV0aGVudGljYXRpb24gYW5k IHNlc3Npb24gYXV0aG9yaXphdGlvbiBmYWlsdXJlIi4NCg0KICBBbmR5OiBUaGUgb25seSBpbXBv cnRhbnQgcXVlc3Rpb24gd2UgaGF2ZSBpcyAiSXMgdGhlIHVzZXIgYWxsb3dlZCB0byB1c2UgdGhl IE5FVENPTkYgc2Vzc2lvbj8iLCB3aHkgYXJlIHlvdSBkaXZpZGluZyBpdCBpbnRvIHR3bz8NCiAg V2VzOiBSQURJVVMgb25seSBrbm93cyB5ZXMgYW5kIG5vLg0KDQpQcm9wb3NhbHMgZm9yIGZpeGlu ZyB0aGUgRW9NIGlzc3VlIChMYWRhIExob3RrYSkNCg0KICBMYWRhIHByZXNlbnRzIHRoZSBzbGlk ZXMgZGlzY3Vzc2luZyB0aGUgZnJhbWluZyBzb2x1dGlvbiBzcGFjZSBmb3IgdGhlIHVuZm9ydHVu YXRlIEVPTSBtYXJrZXIgcHJvYmxlbS4NCi0gQW5keTogSSBzdXBwb3J0IHRoZSAweDA0IG1hcmtl ciB0aGUgbW9zdCBzaW5jZSBpdCBkb2VzIG5vdCByZXF1aXJlIG11Y2ggY29kZSBjaGFuZ2VzLg0K LSBXZXM6IFRoZSBFb00gZXNjYXBpbmcgbWV0aG9kICgjMSkgZG9lc24ndCB3b3JrLCB0aGUgc2Vx dWVuY2UgIl1dPl1dPl1dPiIgd29uJ3QgYmUgcHJvcGVybHkgZXNjYXBlZC4gSGUgc2hvdWxkIHBv c3QgYSBjb3VudGVyIGV4YW1wbGUuIA0KDQogICBXaHkgZG8geW91IG5vdCBzaW1wbHkgbG9vayBm b3IgdGhlIGNsb3NpbmcgWE1MIHRhZz8gVGhpcyByZXF1aXJlcyB0byBwYXJzZSB0aGUgd2hvbGUg ZG9jdW1lbnQuDQotIEFuZHk6IFdoYXQgd2FzIHRoZSByZXNvbHV0aW9uIGFib3V0IGNsb3Npbmcg dGhlIHNlc3Npb24/IE15IHNvZnR3YXJlIGp1c3QgY2xvc2VzIHRoZSBzZXNzaW9uLiANCiAgSnVl cmdlbjogV2h5IGRvbid0IHlvdSB0ZWxsIHRoZSBjbGllbnQgd2hhdCdzIGhhcHBlbmVkPw0KICBC ZXJ0OiBJIGJlbGlldmUgdGhlIGNvbmNsdXNpb24gd2FzIHRvIHNlbmQgYW4gZXJyb3IgbWVzc2Fn ZSBhbmQgbm90IHRvIGNsb3NlIHRoZSBzZXNzaW9uLg0KDQogIFBhdWwoPykgZG9lcyBub3QgcmVj YWxsIHdoYXQgd2UgZG8gaWYgd2UgbG9vc2Ugc3luY2hyb25pemF0aW9uPw0KICBTb21lb25lIHNh eXMgdGhhdCBiZWluZyBjdXQmcGFzdGUgZnJpZW5kbHkgaXMgaW1wb3J0YW50Lg0KDQoqIE9wZW4g TWlrZSAtIENsb3NpbmcgU2Vzc2lvbnMNCg0KICBBQiBzYXlzIHRoYXQgaGUgc2ltcGx5IGNsb3Nl cyB0aGUgc2Vzc2lvbiBpZiB0aGUgZG9jdW1lbnQgZG9lcyBub3QgcGFyc2UuIEhlIGRvZXMgbm90 IHNlbmQgYW4gZXJyb3IuDQogIEFCIHNheXMgdGhhdCByaWdodCBub3cgdGhlIFdHIGNvbmNlbnN1 cyBzZWVtcyB0byBiZSB0byBzZW5kIGFuIGVycm9yIGFuZCB0byBsZWF2ZSBpdCBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYyB3aGV0aGVyIHRoZSBzZXNzaW9uIGlzIGNsb3NlZC4NCg== ------_=_NextPart_001_01CB8D8D.F8835500-- From bertietf@bwijnen.net Mon Nov 29 07:46: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 6A6613A6BD2 for ; Mon, 29 Nov 2010 07:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 OEedWYWoudhd for ; Mon, 29 Nov 2010 07:46:36 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 2907C3A6BCC for ; Mon, 29 Nov 2010 07:46:34 -0800 (PST) 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 1PN5x7-0004uf-V0 for netconf@ietf.org; Mon, 29 Nov 2010 16:47:43 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest95.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PN5x7-0004Oi-No for netconf@ietf.org; Mon, 29 Nov 2010 16:47:41 +0100 Message-ID: <4CF3CB1D.3060008@bwijnen.net> Date: Mon, 29 Nov 2010 16:47:41 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd474054609924446617bb8a99c70b8d49f X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd474054609924446617bb8a99c70b8d49f Subject: [Netconf] WG Last Call on one more change to RFC4742bis 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, 29 Nov 2010 15:46:37 -0000 Dear WG participants, This is a 2 week WG Last Call for WG has consensus on a late proposal to add proper/decent framing to the SSH transport layer. Please comment/respond before 14 December 2010 as you know, rfc4742bis has already been submitted to our AD for and to be published as a PS RFC, obsoleting rfc4742. At our IETF session in Beijing, there was more discussion on the EOM sequence and on possible solutions in a future version. That resulted in some hallway discussions to try and figure out if we could find a way to do proper framing now, while being backwards compatible with the rfc4742. Your WG chairs were only willing to consider this if we can find real WG consensus on such a change. We have had some offline mail discussions with most (in fact we think all) implementers of the code, and as a result, it seems there is a proposal on the table now that we as a WG can reach consensus on. The proposal is below, in the form of proposed TEXT edits to the latest draft-ietf-netconf-rfc4742bis-04.txt. We have asked our AD to hold that document for a short period of time, to see if we can indeed get consensus on the below. If we do, then we want to update the draft-ietf-netconf-rfc4742bis-04.txt document before our AD sends it to IETF Last Call. As you can see, the proposal makes it a little bit harder to do just an SSH-session and then do cut-and-paste input. We discussed this also, and the implementers now believe that the proposed solution for proper/decent framing is acceptable and that most implementation can/will provide a simple scripting front-end to allow for some form of cut-and-paste. Bert and Mehmet --------- Here follow the proposed text-edits to draft-ietf-netconf-rfc4742bis-04.txt OLD (in 3.1): S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S:4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> NEW: S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.1 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S:4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.1 C: C: C: C: ]]>]]> Delete this from 3.1: As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each XML document in the NETCONF exchange. This character sequence MUST NOT appear in an XML document. NEW (right after the first paragraph in Section 4.): 4.1. Framing protocol The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol. The message MUST be followed by the character sequence "]]>]]>". Upon reception of the message, the receiving peer's SSH Transport layer conceptually passes the message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked transfer mechanism (see Section 4.1.1) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message based mechanism (see Section 4.1.2) is used. 4.1.1. Chunked Framing Mechanism This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC 5234] rule Chunked-Message: Chunked-Message = 1*chunk end-of-chunks chunk = LF HASH chunk-size LF chunk-data chunk-size = 1*DIGIT1 0*DIGIT chunk-data = 1*OCTET end-of-chunks = LF HASH HASH LF DIGIT1 = %x31-39 DIGIT = %x30-39 HASH = %x23 LF = %x0A OCTET = %x00-FF The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295. As an example, the message: could be encoded as: #4 ## Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer. If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. 4.1.2. End-of-message Framing Mechanism This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise the :base:1.1 capability. When this mechanism is used, the special character sequence "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the "]]>]]>" characters to the Messages layer. OLD (section 4): To continue the example given above, a NETCONF over SSH session to retrieve a set of configuration information might look like this: C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S:rootsuperuser S:fredadmin S:barneyadmin S: S: S: S: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: #404 S: S: S: S: S:rootsuperuser S:fredadmin S:barneyadmin S: S: S: S: S: ## OLD (Section 5): C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]] NEW: C: #141 C: C: C: C: C: C: ## S: #140 S: S: S: S: S: S: ## OLD (Section 6): 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. NEW: RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. When both peers implement this specification, a proper framing protocol is used for the rest of the NETCONF session, to avoid injection attacks. From ietf@andybierman.com Mon Nov 29 08:12: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 40BA428C0F7 for ; Mon, 29 Nov 2010 08:12:31 -0800 (PST) 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=[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 mfQAMGsoPo0j for ; Mon, 29 Nov 2010 08:12:29 -0800 (PST) Received: from nm15.bullet.mail.ac4.yahoo.com (nm15.bullet.mail.ac4.yahoo.com [98.139.52.212]) by core3.amsl.com (Postfix) with SMTP id 996B33A6BCC for ; Mon, 29 Nov 2010 08:12:29 -0800 (PST) Received: from [98.139.52.194] by nm15.bullet.mail.ac4.yahoo.com with NNFMP; 29 Nov 2010 16:13:36 -0000 Received: from [98.139.52.165] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 29 Nov 2010 16:13:36 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 29 Nov 2010 16:13:36 -0000 X-Yahoo-Newman-Id: 543257.38815.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 8944 invoked from network); 29 Nov 2010 16:13:36 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.re3.yahoo.com with SMTP; 29 Nov 2010 08:13:33 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8v02VpoVM1no0esicBxohmBJsUqmI3UQLjlHzJzmJb7rnCk w_xpa5bfEztUwIlsWQOmkS5jL0bq1X.CxUEijvizVcpSLftcUlLeTzLFDLNX P8p7yk.Da8pQP.4.OfoqHmWJBA.YkMOaDH9lCfE.0NJhQyHbgx8w4X4eMX0r 1MUmDOMyWvioQ.M8FWjkhaMLU3VpcTrm3DAD3b8GFt8cae_0dLhvYJQQlA.h KP4sf0O4o5DMLrlb53jUl0NvQ._upa_HTMH.8gUWV65zJJHFSHBax5d4vJs3 ujcElUh47lrC2yIsT_fpvQ4BK0SaT1JfEHifYBa.uROwGiTLB4tyXz5RpkeR CNlCcy2NX8pkk_IPJj66HtXdA37OH0SpR06rTsLF29bEHI_K_FD_X27ww4gF MYmKEmuNpbT8PoSXFGh_zhkg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CF3D14E.1060509@andybierman.com> Date: Mon, 29 Nov 2010 08:14:06 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Bert \(IETF\) Wijnen" References: <4CF3CB1D.3060008@bwijnen.net> In-Reply-To: <4CF3CB1D.3060008@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 29 Nov 2010 16:12:31 -0000 On 11/29/2010 07:47 AM, Bert (IETF) Wijnen wrote: > Dear WG participants, > > This is a 2 week WG Last Call for WG has consensus on > a late proposal to add proper/decent framing to the > SSH transport layer. > > Please comment/respond before 14 December 2010 > This seems OK. The NEW examples for section 4 and 5 (at the end) have an extra NL in them after the last chunk and before the EOM (##). They should be the same as the example in 4.1. Andy > as you know, rfc4742bis has already been submitted to our AD > for and to be published as a PS RFC, obsoleting rfc4742. > > At our IETF session in Beijing, there was more discussion on > the EOM sequence and on possible solutions in a future version. > That resulted in some hallway discussions to try and figure out > if we could find a way to do proper framing now, while being > backwards compatible with the rfc4742. Your WG chairs were > only willing to consider this if we can find real WG consensus > on such a change. We have had some offline mail discussions > with most (in fact we think all) implementers of the code, and > as a result, it seems there is a proposal on the table now that > we as a WG can reach consensus on. The proposal is below, > in the form of proposed TEXT edits to the latest > draft-ietf-netconf-rfc4742bis-04.txt. We have asked our > AD to hold that document for a short period of time, to see > if we can indeed get consensus on the below. If we do, then > we want to update the draft-ietf-netconf-rfc4742bis-04.txt > document before our AD sends it to IETF Last Call. > > As you can see, the proposal makes it a little bit harder > to do just an SSH-session and then do cut-and-paste input. > We discussed this also, and the implementers now believe that > the proposed solution for proper/decent framing is acceptable > and that most implementation can/will provide a simple > scripting front-end to allow for some form of cut-and-paste. > > Bert and Mehmet > --------- > Here follow the proposed text-edits to > draft-ietf-netconf-rfc4742bis-04.txt > > OLD (in 3.1): > > S: > S: > S: > S: > S: urn:ietf:params:xml:ns:netconf:base:1.0 > S: > S: > S: urn:ietf:params:ns:netconf:capability:startup:1.0 > S: > S: > S:4 > S: > S: ]]>]]> > > C: > C: > C: > C: > C: urn:ietf:params:xml:ns:netconf:base:1.0 > C: > C: > C: > C: ]]>]]> > > NEW: > > S: > S: > S: > S: > S: urn:ietf:params:xml:ns:netconf:base:1.1 > S: > S: > S: urn:ietf:params:ns:netconf:capability:startup:1.0 > S: > S: > S:4 > S: > S: ]]>]]> > > C: > C: > C: > C: > C: urn:ietf:params:xml:ns:netconf:base:1.1 > C: > C: > C: > C: ]]>]]> > > > > Delete this from 3.1: > > As the previous example illustrates, a special character sequence, > ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF > server after each XML document in the NETCONF exchange. This > character sequence MUST NOT appear in an XML document. > > NEW (right after the first paragraph in Section 4.): > > 4.1. Framing protocol > > The previous version of this document defined the character sequence > "]]>]]>" as a message separator, under the assumption that it could > not be found in well-formed XML documents. However, this assumption > is not correct. It can legally appear in XML attributes, comments, > and processing instructions. In order to solve this problem, and at > the same time be compatible with existing implementations, this > document defines the following framing protocol. > > The message MUST be followed by the character sequence > "]]>]]>". Upon reception of the message, the receiving > peer's SSH Transport layer conceptually passes the > message to the Messages layer. If the :base:1.1 capability is > advertised by both peers, the chunked transfer mechanism (see > Section 4.1.1) is used for the remainder of the NETCONF > session. Otherwise, the old end-of-message based mechanism > (see Section 4.1.2) is used. > > 4.1.1. Chunked Framing Mechanism > > This mechanism encodes all NETCONF messages with a chunked > framing. Specifically, the message follows the ABNF [RFC 5234] > rule Chunked-Message: > > Chunked-Message = 1*chunk > end-of-chunks > > chunk = LF HASH chunk-size LF > chunk-data > chunk-size = 1*DIGIT1 0*DIGIT > chunk-data = 1*OCTET > > end-of-chunks = LF HASH HASH LF > > DIGIT1 = %x31-39 > DIGIT = %x30-39 > HASH = %x23 > LF = %x0A > OCTET = %x00-FF > > The chunk-size field is a string of decimal digits indicating the > number of octets in chunk-data. Leading zeros are prohibited, and > the maximum allowed chunk-size value is 4294967295. > > As an example, the message: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > could be encoded as: > > #4 > #18 > message-id="102" > > #79 > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > ## > > Conceptually, the SSH Transport layer encodes messages sent by the > Messages layer, and decodes messages received on the SSH channel > before passing them to the Messages layer. > > If an error occurs during the decoding process, the peer MUST > terminate the NETCONF session by closing the corresponding SSH > channel. > > 4.1.2. End-of-message Framing Mechanism > > This mechanism exists for backwards compatibility with > implementations of previous versions of this document. It is only > used when the remote peer does not advertise the :base:1.1 > capability. > > When this mechanism is used, the special character sequence > "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF > server after each message (XML document) in the NETCONF exchange. > Conceptually, the SSH Transport layer passes any data found in > between the "]]>]]>" characters to the Messages layer. > > > > OLD (section 4): > > To continue the example given above, a NETCONF over SSH session to > retrieve a set of configuration information might look like this: > > C: > C: C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > C: > C: > C: > C: > C: > C: > C: > C: ]]>]]> > > S: > S: S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > S: > S: > S:rootsuperuser > S:fredadmin > S:barneyadmin > S: > S: > S: > S: ]]>]]> > > NEW: > > The following example shows a capability exchange. Data sent by the > NETCONF client are marked with "C:" and data sent by the NETCONF > server are marked with "S:". > > C: #271 > C: > C: C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > C: > C: > C: > C: > C: > C: > C: > C: > C: ## > > S: #404 > S: > S: S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > S: > S: > S:rootsuperuser > S:fredadmin > S:barneyadmin > S: > S: > S: > S: > S: ## > > OLD (Section 5): > > C: > C: C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > C: > C: > C: ]]>]]> > > S: > S: S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > S: > S: > S: ]]>]] > > NEW: > > C: #141 > C: > C: C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > C: > C: > C: > C: ## > > S: #140 > S: > S: S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > S: > S: > S: > S: ## > > OLD (Section 6): > > 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. > > NEW: > > RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in > any well-formed XML document, which turned out to be mistaken. The > EOM sequence can cause operational problems and open space for > attacks if sent deliberately in RPC messages. It is however > believed that the associated threat is not very high. This > document still uses the EOM sequence for the initial > message to avoid incompatibility with existing implementations. > When both peers implement this specification, a proper framing > protocol is used for the rest of the NETCONF session, to avoid > injection attacks. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From ietf@andybierman.com Mon Nov 29 08:23: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 464FA28C153 for ; Mon, 29 Nov 2010 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 d94LJx0nd2mY for ; Mon, 29 Nov 2010 08:23:40 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id E0DEA3A6C16 for ; Mon, 29 Nov 2010 08:23:40 -0800 (PST) Received: (qmail 84355 invoked from network); 29 Nov 2010 16:20:17 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2010 08:20:14 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: fxOxKMcVM1kyy8xVk8q6t8zha._HdxRmzkmC8_PtMUQOi5V fodEHEdRce3GE1HuIx3tMugLczjxJmcItUmAjfbD_AOdLdkF5tW0GlsJADDH NNp7O60lOSxHVOlQ.VK3pLNo6aCtt5g9GQpYV_IPimUvGR39qGWITliaPe6f KnN2FxzU5cKynoWprE4FaDCknji.ILbOJY8llLoCb1xXzxVjK5vgEKvLD11_ 4mgVziqYstDOlhJazwAkw.9mW5PlLt2MaxLl_nkA_k1bT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CF3D2E0.3090407@andybierman.com> Date: Mon, 29 Nov 2010 08:20:48 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Bert \(IETF\) Wijnen" References: <4CF3CB1D.3060008@bwijnen.net> <4CF3D14E.1060509@andybierman.com> In-Reply-To: <4CF3D14E.1060509@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 29 Nov 2010 16:23:42 -0000 On 11/29/2010 08:14 AM, Andy Bierman wrote: > On 11/29/2010 07:47 AM, Bert (IETF) Wijnen wrote: >> Dear WG participants, >> >> This is a 2 week WG Last Call for WG has consensus on >> a late proposal to add proper/decent framing to the >> SSH transport layer. >> >> Please comment/respond before 14 December 2010 >> > > This seems OK. > The NEW examples for section 4 and 5 (at the end) > have an extra NL in them after the last chunk and before > the EOM (##). They should be the same as the example in 4.1. > oops -- got it backwards but the examples are confusing. The example in 4.1.1.1 does not show the old encoding so we cannot tell if was followed by a new line or not. In the examples that have OLD and NEW encoding, it is clear that the rpc end tag is followed by a new line so the extra line in the new encoding is correct. Andy > > Andy > >> as you know, rfc4742bis has already been submitted to our AD >> for and to be published as a PS RFC, obsoleting rfc4742. >> >> At our IETF session in Beijing, there was more discussion on >> the EOM sequence and on possible solutions in a future version. >> That resulted in some hallway discussions to try and figure out >> if we could find a way to do proper framing now, while being >> backwards compatible with the rfc4742. Your WG chairs were >> only willing to consider this if we can find real WG consensus >> on such a change. We have had some offline mail discussions >> with most (in fact we think all) implementers of the code, and >> as a result, it seems there is a proposal on the table now that >> we as a WG can reach consensus on. The proposal is below, >> in the form of proposed TEXT edits to the latest >> draft-ietf-netconf-rfc4742bis-04.txt. We have asked our >> AD to hold that document for a short period of time, to see >> if we can indeed get consensus on the below. If we do, then >> we want to update the draft-ietf-netconf-rfc4742bis-04.txt >> document before our AD sends it to IETF Last Call. >> >> As you can see, the proposal makes it a little bit harder >> to do just an SSH-session and then do cut-and-paste input. >> We discussed this also, and the implementers now believe that >> the proposed solution for proper/decent framing is acceptable >> and that most implementation can/will provide a simple >> scripting front-end to allow for some form of cut-and-paste. >> >> Bert and Mehmet >> --------- >> Here follow the proposed text-edits to >> draft-ietf-netconf-rfc4742bis-04.txt >> >> OLD (in 3.1): >> >> S: >> S: >> S: >> S: >> S: urn:ietf:params:xml:ns:netconf:base:1.0 >> S: >> S: >> S: urn:ietf:params:ns:netconf:capability:startup:1.0 >> S: >> S: >> S:4 >> S: >> S: ]]>]]> >> >> C: >> C: >> C: >> C: >> C: urn:ietf:params:xml:ns:netconf:base:1.0 >> C: >> C: >> C: >> C: ]]>]]> >> >> NEW: >> >> S: >> S: >> S: >> S: >> S: urn:ietf:params:xml:ns:netconf:base:1.1 >> S: >> S: >> S: urn:ietf:params:ns:netconf:capability:startup:1.0 >> S: >> S: >> S:4 >> S: >> S: ]]>]]> >> >> C: >> C: >> C: >> C: >> C: urn:ietf:params:xml:ns:netconf:base:1.1 >> C: >> C: >> C: >> C: ]]>]]> >> >> >> >> Delete this from 3.1: >> >> As the previous example illustrates, a special character sequence, >> ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF >> server after each XML document in the NETCONF exchange. This >> character sequence MUST NOT appear in an XML document. >> >> NEW (right after the first paragraph in Section 4.): >> >> 4.1. Framing protocol >> >> The previous version of this document defined the character sequence >> "]]>]]>" as a message separator, under the assumption that it could >> not be found in well-formed XML documents. However, this assumption >> is not correct. It can legally appear in XML attributes, comments, >> and processing instructions. In order to solve this problem, and at >> the same time be compatible with existing implementations, this >> document defines the following framing protocol. >> >> The message MUST be followed by the character sequence >> "]]>]]>". Upon reception of the message, the receiving >> peer's SSH Transport layer conceptually passes the >> message to the Messages layer. If the :base:1.1 capability is >> advertised by both peers, the chunked transfer mechanism (see >> Section 4.1.1) is used for the remainder of the NETCONF >> session. Otherwise, the old end-of-message based mechanism >> (see Section 4.1.2) is used. >> >> 4.1.1. Chunked Framing Mechanism >> >> This mechanism encodes all NETCONF messages with a chunked >> framing. Specifically, the message follows the ABNF [RFC 5234] >> rule Chunked-Message: >> >> Chunked-Message = 1*chunk >> end-of-chunks >> >> chunk = LF HASH chunk-size LF >> chunk-data >> chunk-size = 1*DIGIT1 0*DIGIT >> chunk-data = 1*OCTET >> >> end-of-chunks = LF HASH HASH LF >> >> DIGIT1 = %x31-39 >> DIGIT = %x30-39 >> HASH = %x23 >> LF = %x0A >> OCTET = %x00-FF >> >> The chunk-size field is a string of decimal digits indicating the >> number of octets in chunk-data. Leading zeros are prohibited, and >> the maximum allowed chunk-size value is 4294967295. >> >> As an example, the message: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> could be encoded as: >> >> #4 >> > #18 >> message-id="102" >> >> #79 >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> ## >> >> Conceptually, the SSH Transport layer encodes messages sent by the >> Messages layer, and decodes messages received on the SSH channel >> before passing them to the Messages layer. >> >> If an error occurs during the decoding process, the peer MUST >> terminate the NETCONF session by closing the corresponding SSH >> channel. >> >> 4.1.2. End-of-message Framing Mechanism >> >> This mechanism exists for backwards compatibility with >> implementations of previous versions of this document. It is only >> used when the remote peer does not advertise the :base:1.1 >> capability. >> >> When this mechanism is used, the special character sequence >> "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF >> server after each message (XML document) in the NETCONF exchange. >> Conceptually, the SSH Transport layer passes any data found in >> between the "]]>]]>" characters to the Messages layer. >> >> >> >> OLD (section 4): >> >> To continue the example given above, a NETCONF over SSH session to >> retrieve a set of configuration information might look like this: >> >> C: >> C:> C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> C: >> C: >> C: >> C: >> C: >> C: >> C: >> C: ]]>]]> >> >> S: >> S:> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> S: >> S: >> S:rootsuperuser >> S:fredadmin >> S:barneyadmin >> S: >> S: >> S: >> S: ]]>]]> >> >> NEW: >> >> The following example shows a capability exchange. Data sent by the >> NETCONF client are marked with "C:" and data sent by the NETCONF >> server are marked with "S:". >> >> C: #271 >> C: >> C:> C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> C: >> C: >> C: >> C: >> C: >> C: >> C: >> C: >> C: ## >> >> S: #404 >> S: >> S:> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> S: >> S: >> S:rootsuperuser >> S:fredadmin >> S:barneyadmin >> S: >> S: >> S: >> S: >> S: ## >> >> OLD (Section 5): >> >> C: >> C:> C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> C: >> C: >> C: ]]>]]> >> >> S: >> S:> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> S: >> S: >> S: ]]>]] >> >> NEW: >> >> C: #141 >> C: >> C:> C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> C: >> C: >> C: >> C: ## >> >> S: #140 >> S: >> S:> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> S: >> S: >> S: >> S: ## >> >> OLD (Section 6): >> >> 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. >> >> NEW: >> >> RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in >> any well-formed XML document, which turned out to be mistaken. The >> EOM sequence can cause operational problems and open space for >> attacks if sent deliberately in RPC messages. It is however >> believed that the associated threat is not very high. This >> document still uses the EOM sequence for the initial >> message to avoid incompatibility with existing implementations. >> When both peers implement this specification, a proper framing >> protocol is used for the rest of the NETCONF session, to avoid >> injection attacks. >> >> >> _______________________________________________ >> 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 bwijnen@ripe.net Tue Nov 30 01:13: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 853673A6B38 for ; Tue, 30 Nov 2010 01:13:25 -0800 (PST) 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=[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 6ps618-EuppF for ; Tue, 30 Nov 2010 01:13:24 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 79E713A6AEB for ; Tue, 30 Nov 2010 01:13:24 -0800 (PST) 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 1PNMIC-0005d7-5L for netconf@ietf.org; Tue, 30 Nov 2010 10:14:33 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PNMIC-0004AA-0t for netconf@ietf.org; Tue, 30 Nov 2010 10:14:32 +0100 Message-ID: <4CF4C077.1090609@ripe.net> Date: Tue, 30 Nov 2010 10:14:31 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ec70324275eaaad07035438c3eaf627ed X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ec70324275eaaad07035438c3eaf627ed Subject: [Netconf] Regarding that WG last call for changes to 4742bis 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, 30 Nov 2010 09:13:25 -0000 My mailer client (Thunderbird 3.1.6) has removed the blanks before every occurrence of the "<" character. (I have not found yet how to fix it). So the EDITS that I posted in my WGLC email are not 100% correct because of missing blanks. I have asked Martin to post the proper TEXT EDITS. Pls check the edits once Martin posts them and pls review and let us know if you agree or disagree with the proposed changes/edits. If you disagree, pls make a short statement as to why you disagree. Bert From mbj@tail-f.com Tue Nov 30 03:57: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 8758828C105 for ; Tue, 30 Nov 2010 03:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 29n-rNH8dBd2 for ; Tue, 30 Nov 2010 03:57:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E5E353A6BFD for ; Tue, 30 Nov 2010 03:57:45 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 809EC616001; Tue, 30 Nov 2010 12:58:55 +0100 (CET) Date: Tue, 30 Nov 2010 12:58:54 +0100 (CET) Message-Id: <20101130.125854.197191090.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4CF3CB1D.3060008@bwijnen.net> References: <4CF3CB1D.3060008@bwijnen.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] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 11:57:47 -0000 Hi, It seems some white-spaces got messed up somewhere in transit from me to Bert to the ML, so here's a slightly updated version of the diffs: /martin OLD (in 3.1): The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C: " and data sent by the NETCONF server are marked with "S: ". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.1 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.1 C: C: C: C: ]]>]]> Delete this from 3.1: As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each XML document in the NETCONF exchange. This character sequence MUST NOT appear in an XML document. NEW (right after the first paragraph in Section 4.): 4.1. Framing protocol The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol. The message MUST be followed by the character sequence "]]>]]>". Upon reception of the message, the receiving peer's SSH Transport layer conceptually passes the message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked transfer mechanism (see Section 4.1.1) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message based mechanism (see Section 4.1.2) is used. 4.1.1. Chunked Framing Mechanism This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC 5234] rule Chunked-Message: Chunked-Message = 1*chunk end-of-chunks chunk = LF HASH chunk-size LF chunk-data chunk-size = 1*DIGIT1 0*DIGIT chunk-data = 1*OCTET end-of-chunks = LF HASH HASH LF DIGIT1 = %x31-39 DIGIT = %x30-39 HASH = %x23 LF = %x0A OCTET = %x00-FF The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295. As an example, the message: could be encoded as: #4 ## Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer. If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. 4.1.2. End-of-message Framing Mechanism This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise the :base:1.1 capability. When this mechanism is used, the special character sequence "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the "]]>]]>" characters to the Messages layer. OLD (section 4): To continue the example given above, a NETCONF over SSH session to retrieve a set of configuration information might look like this: C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C: " and data sent by the NETCONF server are marked with "S: ". C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: #404 S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: S: ## OLD (Section 5): C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]] NEW: C: #141 C: C: C: C: C: C: ## S: #140 S: S: S: S: S: S: ## OLD (Section 6): 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. NEW: RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. When both peers implement this specification, a proper framing protocol is used for the rest of the NETCONF session, to avoid injection attacks. From mbj@tail-f.com Tue Nov 30 04:06: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 1889328C114 for ; Tue, 30 Nov 2010 04:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 GwnZRMhZ1jvl for ; Tue, 30 Nov 2010 04:06:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5D0E63A6C04 for ; Tue, 30 Nov 2010 04:06:14 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 16EAD616002; Tue, 30 Nov 2010 13:07:25 +0100 (CET) Date: Tue, 30 Nov 2010 13:07:24 +0100 (CET) Message-Id: <20101130.130724.177355977.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4CF3CB1D.3060008@bwijnen.net> References: <4CF3CB1D.3060008@bwijnen.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] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 12:06:16 -0000 Hi again, I accidentally hit send before the text was ready. Here is the new text. /martin OLD (in 3.1): The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C: " and data sent by the NETCONF server are marked with "S: ". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.1 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.1 C: C: C: C: ]]>]]> Delete this from 3.1: As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each XML document in the NETCONF exchange. This character sequence MUST NOT appear in an XML document. NEW (right after the first paragraph in Section 4.): 4.1. Framing protocol The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol. The message MUST be followed by the character sequence "]]>]]>". Upon reception of the message, the receiving peer's SSH Transport layer conceptually passes the message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked transfer mechanism (see Section 4.1.1) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message based mechanism (see Section 4.1.2) is used. 4.1.1. Chunked Framing Mechanism This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC 5234] rule Chunked-Message: Chunked-Message = 1*chunk end-of-chunks chunk = LF HASH chunk-size LF chunk-data chunk-size = 1*DIGIT1 0*DIGIT chunk-data = 1*OCTET end-of-chunks = LF HASH HASH LF DIGIT1 = %x31-39 DIGIT = %x30-39 HASH = %x23 LF = %x0A OCTET = %x00-FF The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295. As an example, the message: could be encoded as: #4 ## Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer. If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. 4.1.2. End-of-message Framing Mechanism This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise the :base:1.1 capability. When this mechanism is used, the special character sequence "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the "]]>]]>" characters to the Messages layer. OLD (section 4): C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> NEW: C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: #404 S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: S: ## OLD (Section 5): C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]] NEW: C: #141 C: C: C: C: C: C: ## S: #140 S: S: S: S: S: S: ## OLD (Section 6): 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. NEW: RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. When both peers implement this specification, a proper framing protocol is used for the rest of the NETCONF session, to avoid injection attacks. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue Nov 30 07:25: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 CEA0A3A6C74 for ; Tue, 30 Nov 2010 07:25:20 -0800 (PST) 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 RINhL2cffLTO for ; Tue, 30 Nov 2010 07:25:20 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 970993A6C7C for ; Tue, 30 Nov 2010 07:25:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTPUXoyJ3/jbZTcsVaqNNeAAi4Bl1fGtT@postini.com; Tue, 30 Nov 2010 07:26:31 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 30 Nov 2010 07:23:25 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oAUFNOU49552; Tue, 30 Nov 2010 07:23:25 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oAUF1nWs051047; Tue, 30 Nov 2010 15:01:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201011301501.oAUF1nWs051047@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20101130.130724.177355977.mbj@tail-f.com> Date: Tue, 30 Nov 2010 10:01:49 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 15:25:20 -0000 Martin Bjorklund writes: >I accidentally hit send before the text was ready. Here is the new >text. Absolutely, completely, and in all other ways digging it. Thanks, Phil From kwatsen@juniper.net Tue Nov 30 11:03: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 1095828C0D9 for ; Tue, 30 Nov 2010 11:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 oeSfzE3XjrR0 for ; Tue, 30 Nov 2010 11:03:15 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 7F9FA3A6B9F for ; Tue, 30 Nov 2010 11:03:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTPVKtEpTxTjqqIyhMGTBdaEo8/Ue7B3h@postini.com; Tue, 30 Nov 2010 11:04:27 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 30 Nov 2010 11:03:06 -0800 From: Kent Watsen To: Martin Bjorklund , "bertietf@bwijnen.net" Date: Tue, 30 Nov 2010 11:03:03 -0800 Thread-Topic: [Netconf] WG Last Call on one more change to RFC4742bis Thread-Index: AcuQhysNGKpvDjYfRzqR+BMJra+cQAAL7yVw Message-ID: <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> References: <4CF3CB1D.3060008@bwijnen.net> <20101130.130724.177355977.mbj@tail-f.com> In-Reply-To: <20101130.130724.177355977.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 19:03:17 -0000 I very much like the chunked strategy being in 4742bis, just a few nits: 1. In section 4.1.1, would following be more clear? Chunked-Message =3D 1*chunk end-of-chunks chunk =3D LF "#" chunk-size LF chunk-data chunk-size =3D %x00000000-FFFFFFFF chunk-data =3D 1*OCTET end-of-chunks =3D LF "##" LF The three mechanisms I'm using to collapse this are: 1. leverage OCTET and LF already being defined in RFC 5234 2. inline the HASH definition as a "#" character 3. define chunk-size using a 4-byte hex value 2. update to section 4.1.2 "It is only used when the remote peer does not advertise the :base:1.1 c= apability." Should the language match that used in 4.1 about the :base:1.1 capabilit= y being advertised by both peers? I understand that it's assumed that the imple= menter is presumably already advertising ":base:1.1, so it's really just the re= mote side that matters, but it took me a few seconds to realize that, which sugges= ts that the the text could be clarified 3. in the examples in sections 4 and 5, is there a missing LF at the beginn= ing of each message? For instance, should it be C: C: #271 C: instead of: C: #271 C: Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Tuesday, November 30, 2010 7:07 AM To: bertietf@bwijnen.net Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis Hi again, I accidentally hit send before the text was ready. Here is the new text. /martin OLD (in 3.1): The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C: " and data sent by the NETCONF server are marked with "S: ". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.1 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.1 C: C: C: C: ]]>]]> Delete this from 3.1: As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each XML document in the NETCONF exchange. This character sequence MUST NOT appear in an XML document. NEW (right after the first paragraph in Section 4.): 4.1. Framing protocol The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol. The message MUST be followed by the character sequence "]]>]]>". Upon reception of the message, the receiving peer's SSH Transport layer conceptually passes the message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked transfer mechanism (see Section 4.1.1) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message based mechanism (see Section 4.1.2) is used. 4.1.1. Chunked Framing Mechanism This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC 5234] rule Chunked-Message: Chunked-Message =3D 1*chunk end-of-chunks chunk =3D LF HASH chunk-size LF chunk-data chunk-size =3D 1*DIGIT1 0*DIGIT chunk-data =3D 1*OCTET end-of-chunks =3D LF HASH HASH LF DIGIT1 =3D %x31-39 DIGIT =3D %x30-39 HASH =3D %x23 LF =3D %x0A OCTET =3D %x00-FF The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295. As an example, the message: could be encoded as: #4 ## Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer. If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. 4.1.2. End-of-message Framing Mechanism This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise the :base:1.1 capability. When this mechanism is used, the special character sequence "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the "]]>]]>" characters to the Messages layer. OLD (section 4): C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> NEW: C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: #404 S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: S: ## OLD (Section 5): C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]] NEW: C: #141 C: C: C: C: C: C: ## S: #140 S: S: S: S: S: S: ## OLD (Section 6): 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. NEW: RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. When both peers implement this specification, a proper framing protocol is used for the rest of the NETCONF session, to avoid injection attacks. _______________________________________________ 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 biermana@Brocade.com Tue Nov 30 12:17: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 555773A6BDA for ; Tue, 30 Nov 2010 12:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-0.401, 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 wRhYua-+eCMq for ; Tue, 30 Nov 2010 12:17:18 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id E55753A6C23 for ; Tue, 30 Nov 2010 12:17:18 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oAUKHs3j011906; Tue, 30 Nov 2010 12:18:28 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id sw85tr00p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Nov 2010 12:18:28 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 30 Nov 2010 12:19:31 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 30 Nov 2010 12:18:27 -0800 From: Andy Bierman To: Kent Watsen , Martin Bjorklund , "bertietf@bwijnen.net" Date: Tue, 30 Nov 2010 12:18:26 -0800 Thread-Topic: [Netconf] WG Last Call on one more change to RFC4742bis Thread-Index: AcuQhysNGKpvDjYfRzqR+BMJra+cQAAL7yVwAAUt+pA= Message-ID: References: <4CF3CB1D.3060008@bwijnen.net> <20101130.130724.177355977.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-30_11:2010-11-30, 2010-11-30, 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-1010190000 definitions=main-1011300125 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 20:17:20 -0000 Hi, We do not want to allow leading zeros. We do not want to use hex encoding. I like the original proposal posted by Martin better than this rewrite. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Tuesday, November 30, 2010 11:03 AM To: Martin Bjorklund; bertietf@bwijnen.net Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis I very much like the chunked strategy being in 4742bis, just a few nits: 1. In section 4.1.1, would following be more clear? Chunked-Message =3D 1*chunk end-of-chunks chunk =3D LF "#" chunk-size LF chunk-data chunk-size =3D %x00000000-FFFFFFFF chunk-data =3D 1*OCTET end-of-chunks =3D LF "##" LF The three mechanisms I'm using to collapse this are: 1. leverage OCTET and LF already being defined in RFC 5234 2. inline the HASH definition as a "#" character 3. define chunk-size using a 4-byte hex value 2. update to section 4.1.2 "It is only used when the remote peer does not advertise the :base:1.1 c= apability." Should the language match that used in 4.1 about the :base:1.1 capabilit= y being advertised by both peers? I understand that it's assumed that the imple= menter is presumably already advertising ":base:1.1, so it's really just the re= mote side that matters, but it took me a few seconds to realize that, which sugges= ts that the the text could be clarified 3. in the examples in sections 4 and 5, is there a missing LF at the beginn= ing of each message? For instance, should it be C: C: #271 C: instead of: C: #271 C: Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Tuesday, November 30, 2010 7:07 AM To: bertietf@bwijnen.net Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis Hi again, I accidentally hit send before the text was ready. Here is the new text. /martin OLD (in 3.1): The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C: " and data sent by the NETCONF server are marked with "S: ". S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.1 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.1 C: C: C: C: ]]>]]> Delete this from 3.1: As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each XML document in the NETCONF exchange. This character sequence MUST NOT appear in an XML document. NEW (right after the first paragraph in Section 4.): 4.1. Framing protocol The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol. The message MUST be followed by the character sequence "]]>]]>". Upon reception of the message, the receiving peer's SSH Transport layer conceptually passes the message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked transfer mechanism (see Section 4.1.1) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message based mechanism (see Section 4.1.2) is used. 4.1.1. Chunked Framing Mechanism This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC 5234] rule Chunked-Message: Chunked-Message =3D 1*chunk end-of-chunks chunk =3D LF HASH chunk-size LF chunk-data chunk-size =3D 1*DIGIT1 0*DIGIT chunk-data =3D 1*OCTET end-of-chunks =3D LF HASH HASH LF DIGIT1 =3D %x31-39 DIGIT =3D %x30-39 HASH =3D %x23 LF =3D %x0A OCTET =3D %x00-FF The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295. As an example, the message: could be encoded as: #4 ## Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer. If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. 4.1.2. End-of-message Framing Mechanism This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise the :base:1.1 capability. When this mechanism is used, the special character sequence "]]>]]>", MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the "]]>]]>" characters to the Messages layer. OLD (section 4): C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> NEW: C: #271 C: C: C: C: C: C: C: C: C: C: C: ## S: #404 S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: S: ## OLD (Section 5): C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]] NEW: C: #141 C: C: C: C: C: C: ## S: #140 S: S: S: S: S: S: ## OLD (Section 6): 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. NEW: RFC 4742 assumes that the EOM sequence "]]>]]>" cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. When both peers implement this specification, a proper framing protocol is used for the rest of the NETCONF session, to avoid injection attacks. _______________________________________________ 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 mbj@tail-f.com Tue Nov 30 12:24: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 A5ABF3A6BDA for ; Tue, 30 Nov 2010 12:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 X+zbp8XgMeva for ; Tue, 30 Nov 2010 12:24:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 60B423A6B44 for ; Tue, 30 Nov 2010 12:24:29 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2C137616001; Tue, 30 Nov 2010 21:25:40 +0100 (CET) Date: Tue, 30 Nov 2010 21:25:37 +0100 (CET) Message-Id: <20101130.212537.163045157.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> References: <4CF3CB1D.3060008@bwijnen.net> <20101130.130724.177355977.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 20:24:30 -0000 Hi, Kent Watsen wrote: > > I very much like the chunked strategy being in 4742bis, just a few nits: > > > 1. In section 4.1.1, would following be more clear? > > Chunked-Message = 1*chunk end-of-chunks > chunk = LF "#" chunk-size LF chunk-data > chunk-size = %x00000000-FFFFFFFF > chunk-data = 1*OCTET > end-of-chunks = LF "##" LF > > The three mechanisms I'm using to collapse this are: > 1. leverage OCTET and LF already being defined in RFC 5234 I don't think it is legal to just use the definitions from Appendix B of RFC 5234. They must be copied. > 2. inline the HASH definition as a "#" character This is a matter of taste, it doesn't change the protocol. I don't have a strong opinion. > 3. define chunk-size using a 4-byte hex value This is not what we had in mind. We wanted the size to be encoded using decimal digits as a string, e.g. the size 42 would be encoded as the string "42", not as the single byte 42. > 3. in the examples in sections 4 and 5, is there a missing LF at the beginning > of each message? For > instance, should it be > > C: > C: #271 > C: > > instead of: > > C: #271 > C: Yes this is correct. /martin From kwatsen@juniper.net Tue Nov 30 13:03: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 F30F93A6C37 for ; Tue, 30 Nov 2010 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gTkBwKkp76fj for ; Tue, 30 Nov 2010 13:03:54 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id BACBF3A6C2A for ; Tue, 30 Nov 2010 13:03:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTPVm+atQnaN07j89lRE//g5n+xEehiZx@postini.com; Tue, 30 Nov 2010 13:05:06 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 30 Nov 2010 13:02:43 -0800 From: Kent Watsen To: Martin Bjorklund Date: Tue, 30 Nov 2010 13:02:42 -0800 Thread-Topic: [Netconf] WG Last Call on one more change to RFC4742bis Thread-Index: AcuQzML66szCpp8mTiOsp1YTiYD7ngAAg3wA Message-ID: <84600D05C20FF943918238042D7670FD374405E1E1@EMBX01-HQ.jnpr.net> References: <4CF3CB1D.3060008@bwijnen.net> <20101130.130724.177355977.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD374405DFD9@EMBX01-HQ.jnpr.net> <20101130.212537.163045157.mbj@tail-f.com> In-Reply-To: <20101130.212537.163045157.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call on one more change to RFC4742bis 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, 30 Nov 2010 21:03:55 -0000 > I don't think it is legal to just use the definitions from Appendix B > of RFC 5234. They must be copied. I wasn't sure either, I checked RFC 5234 and didn't find a statement saying= they had to be copied but I do see other RFCs doing it, so I guess it's st= andard practice to copy the core rules > This is a matter of taste, it doesn't change the protocol. I don't > have a strong opinion. It only mattered so long as we didn't copy the Core Rules; so long as we do= , then any attempt to compress the syntax is lost > This is not what we had in mind. We wanted the size to be encoded > using decimal digits as a string, e.g. the size 42 would be encoded as > the string "42", not as the single byte 42. Ah, good point, thanks. > Yes this is correct. Whew, at least I made one helpful comment ;)