From bertietf@bwijnen.net Tue Mar 1 06:54:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3444B3A67C1; Tue, 1 Mar 2011 06:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 v5o8jV3v4WfY; Tue, 1 Mar 2011 06:54:31 -0800 (PST) Received: from postlady.ripe.net (unknown [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 571A43A67E9; Tue, 1 Mar 2011 06:54:30 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PuQz2-0006Ln-6O; Tue, 01 Mar 2011 15:55:29 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PuQz1-00059a-Vg; Tue, 01 Mar 2011 15:55:28 +0100 Message-ID: <4D6D08DF.9000502@bwijnen.net> Date: Tue, 01 Mar 2011 15:55:27 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lars >> 'Lars Eggert'" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a6e2f09baf44f4c2c313c9954ded0d1f Cc: "draft-ietf-netconf-4741bis@tools.ietf.org" , Netconf , "netconf-chairs@tools.ietf.org" , The IESG Subject: Re: [Netconf] FW: Lars Eggert's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:54:35 -0000 Lars, I find the text that you requires a bit heavy. I would claim, that any document that describes a transport (NETCONF or OTHER) must indeed comply with RFC2914. Such has been the case for many years. And RFC2914 is there to make sure all such documents indeed do address congestion control issues. I do not see why RFC4741bis would have to REPEAT the 2914 language. Whatever new NETCONF transport document ever will come out, it will have to pass the requirements of RFC2914, no? If you (or better the IETF) is ever going to revise RFC2914, would we then also have to revise our text again? So why are you asking this? Bert On 3/1/11 2:21 PM, Romascanu, Dan (Dan) wrote: > Hi, > > Please address the issue raised by Lars in his DISCUSS. > > Thanks and Regards, > > Dan > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: Tuesday, March 01, 2011 3:01 PM > To: The IESG > Cc: netconf-chairs@tools.ietf.org; > draft-ietf-netconf-4741bis@tools.ietf.org > Subject: Lars Eggert's Discuss on draft-ietf-netconf-4741bis-09: (with > DISCUSS) > > Lars Eggert has entered the following ballot position for > draft-ietf-netconf-4741bis-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2 should have a requirement that NETCONF transport that are to > be used over the Internet MUST implement congestion control, in > accordance with RFC2914. It can also simply note that all NETCONF > transports that use TCP (such as the SSH transport) automatically > fulfill this requirement. > > (This really is a no-brainer. I just want to prevent a future argument > when someone wants to do a "lightweight" NETCONF transport over UDP...) > > > > From mehmet.ersue@nsn.com Tue Mar 1 08:08:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDE93A67A8 for ; Tue, 1 Mar 2011 08:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTv-D4124bMg for ; Tue, 1 Mar 2011 08:08:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id E22073A6997 for ; Tue, 1 Mar 2011 08:08:24 -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 p21G9KDX011420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Mar 2011 17:09:20 +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 p21G9Hhc028313 for ; Tue, 1 Mar 2011 17:09:19 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 17:09:16 +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, 1 Mar 2011 17:09:15 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B56A24@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Thread-Index: AcvXljnURMOJEwOuTVuDCR2OaI5dTAAjX44g From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 01 Mar 2011 16:09:16.0677 (UTC) FILETIME=[03A8AB50:01CBD82B] Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:08:33 -0000 Hi All, attached is the DISCUSS David Harrington entered on draft-ietf-netconf-rfc4742bis-07. We discussed the issue with the username in the NETCONF WG intensively=20 (see the 4742bis discussion in http://www.ietf.org/proceedings/78/minutes/netconf.txt). Naming policies might differ between administrative domains and=20 identities represented as usernames mean different things in=20 different operating systems. Following the statement in RFC 5592 the WG decided that the=20 method to obtain the username for the NETCONF Server from SSH=20 should be implementation-dependant. I agree, that such an explanation is missing in the current draft. I would suggest to add following text to draft-ietf-netconf-rfc4742bis-07: OLD: How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent. NEW: There is no standard way for an application running on an SSH server=20 to determine a user name for the current session. It may be necessary to use a mapping algorithm to transform an SSH identity to a user.=20 How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent. Any transformations applied to the authenticated user name by the SSH server are outside the scope of this document. Please comment. If you disagree please send a concrete text proposal. Cheers,=20 Mehmet=20 -----Original Message----- From: ext David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, February 28, 2011 11:23 PM To: The IESG Cc: netconf-chairs@tools.ietf.org; draft-ietf-netconf-rfc4742bis@tools.ietf.org Subject: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) David Harrington has entered the following ballot position for draft-ietf-netconf-rfc4742bis-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) 4741bis says: "The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. The access permissions of a given client, identified by its NETCONF username, are part of the configuration of the NETCONF server. These permissions MUST be enforced during the remainder of the NETCONF session. The details how access control is configured is outside the scope of this document." 4742bis says: "How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent." This is not an explanation. Assuming an operator must specify access control rights for a user in the configuration o fthe server, it is important that the operator understands what the netconf username(s) will be. That is presumably why it is important for the Netconf transport protocol specification to explain the algorithm for deriving the username. RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal with similar issues, including constraints about not changing the username associated with a session, allowing "user@host" style naming, etc. Maybe those are not needed for netconf, but the above "implementation-dependent" explanations seems woefully inadequate. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) The IANA section does not specify that the assigned port is a TCP port. should it? From j.schoenwaelder@jacobs-university.de Tue Mar 1 09:14:39 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703033A69FA for ; Tue, 1 Mar 2011 09:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.038, 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 BxVgIKBmKvlj for ; Tue, 1 Mar 2011 09:14:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4E4183A69B2 for ; Tue, 1 Mar 2011 09:14:38 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FFF4C0013; Tue, 1 Mar 2011 18:15:41 +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 qjBe5SnEkBDj; Tue, 1 Mar 2011 18:15: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 BD835C0011; Tue, 1 Mar 2011 18:15:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A143C16D556B; Tue, 1 Mar 2011 18:15:35 +0100 (CET) Date: Tue, 1 Mar 2011 18:15:35 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20110301171533.GA12216@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A6401B56A24@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B56A24@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) 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, 01 Mar 2011 17:14:39 -0000 On Tue, Mar 01, 2011 at 05:09:15PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > I agree, that such an explanation is missing in the current draft. > I would suggest to add following text to > draft-ietf-netconf-rfc4742bis-07: > > OLD: > How the NETCONF Server extracts the SSH user name from the SSH layer > is implementation-dependent. > > NEW: > There is no standard way for an application running on an SSH server > to determine a user name for the current session. It may be necessary > > to use a mapping algorithm to transform an SSH identity to a user. > > How the NETCONF Server extracts the SSH user name from the SSH layer > is implementation-dependent. Any transformations applied to the > authenticated user name by the SSH server are outside the scope of > this document. I would even shorten the text as follows: There is no standard way for an application running on an SSH server to determine a user name for the current session. How the NETCONF Server extracts the user name from the SSH layer is therefore implementation-dependent. Any transformations applied to the authenticated user name by the SSH layer are outside the scope of this document. My reasoning is that any transformations really happen before the NETCONF server even gets to see a user name, at least this was my understanding when we discussed this in the WG meeting. /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 Tue Mar 1 09:49:41 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43ECD3A69FC for ; Tue, 1 Mar 2011 09:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.606, 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 jIgL915j6svJ for ; Tue, 1 Mar 2011 09:49:40 -0800 (PST) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id B95743A68CC for ; Tue, 1 Mar 2011 09:49:39 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr08.btconnect.com with SMTP id BWI94826; Tue, 01 Mar 2011 17:50:39 +0000 (GMT) Message-ID: <014801cbd830$2ca60a20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A6401B56A24@DEMUEXC006.nsn-intra.net> <20110301171533.GA12216@elstar.local> Date: Tue, 1 Mar 2011 17:46:07 +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.4D6D31EF.00B0, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4D6D31EF.02C0,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:49:41 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Ersue, Mehmet (NSN - DE/Munich)" Cc: "Netconf" Sent: Tuesday, March 01, 2011 6:15 PM > On Tue, Mar 01, 2011 at 05:09:15PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > I agree, that such an explanation is missing in the current draft. > > I would suggest to add following text to > > draft-ietf-netconf-rfc4742bis-07: > > > > OLD: > > How the NETCONF Server extracts the SSH user name from the SSH layer > > is implementation-dependent. > > > > NEW: > > There is no standard way for an application running on an SSH server > > to determine a user name for the current session. It may be necessary > > > > to use a mapping algorithm to transform an SSH identity to a user. > > > > How the NETCONF Server extracts the SSH user name from the SSH layer > > is implementation-dependent. Any transformations applied to the > > authenticated user name by the SSH server are outside the scope of > > this document. > > I would even shorten the text as follows: > > There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. Any transformations applied to > the authenticated user name by the SSH layer are outside the scope > of this document. > > My reasoning is that any transformations really happen before the > NETCONF server even gets to see a user name, at least this was my > understanding when we discussed this in the WG meeting. I prefer Juergen's formulation, especially as it gets rid of 'SSH identity' which I think wrong. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue Mar 1 12:30:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DCF3A6A8B for ; Tue, 1 Mar 2011 12:30:18 -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 MmCwMzaWgayk for ; Tue, 1 Mar 2011 12:30:17 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id CA1DD3A68A4 for ; Tue, 1 Mar 2011 12:30:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTW1XlrXkI3ebz3G6wQl+AOhm/6CWIlwG@postini.com; Tue, 01 Mar 2011 12:31:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Mar 2011 12:08:49 -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 p21K9Xv35800; Tue, 1 Mar 2011 12:09:33 -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 p21Jjcfr032304; Tue, 1 Mar 2011 19:45:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103011945.p21Jjcfr032304@idle.juniper.net> To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B56A24@DEMUEXC006.nsn-intra.net> Date: Tue, 1 Mar 2011 14:45:38 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:30:18 -0000 >From: ext David Harrington [mailto:ietfdbh@comcast.net] >RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal >with similar issues, including constraints about not changing the >username associated with a session, allowing "user@host" style naming, >etc. The idea of "user@host" is completely local to the client. The SSH server has no clue that this is going on. I'm a bit shocked that this is an issue for SNMP, but admittedly haven't read 5592. >Maybe those are not needed for netconf, but the above >"implementation-dependent" explanations seems woefully inadequate. Sure, but it is the truth. That's definitely worth something ;^) In particular, the interesting case is the use of RADIUS to accept a user name (and password) but to return (to the SSH server) a distinct "local" user name that is used for local privs. For example, I can say "ssh test@junos" and the JUNOS box will be presented with the user name "test" (having no clue that I am really "phil", as mentioned above). The SSH server then presents this user name ("test") to the RADIUS server for authentication. The RADIUS server can return the local user "operator", which is the account present in /etc/master.passwd (where "test" need not be present in /etc/master.passwd). At this point, I am permitted to login as "operator". The behavior of the system toward the original user name ("test") is completely dependent on the SSH/RADIUS/login/PAM/etc implementation. In a unix-based system, the original user name is returned by getlogin(), but this is not something we are looking to standardize. In other systems, the entire idea of "users" is not defined. You get only a "Password:" prompt for a normal login, and the SSH server implementation completely ignores the user name. On others, you can use RADIUS, but all users are mapped to a single local user, regardless of what RADIUS returns. I'm not sure what text changes are needed, but the brutal truth remains that the behavior toward the original user name is implementation dependent. Thanks, Phil From bertietf@bwijnen.net Tue Mar 1 14:47:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D8F3A6908; Tue, 1 Mar 2011 14:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtNE10TEYvaA; Tue, 1 Mar 2011 14:47:11 -0800 (PST) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id 59FC83A6AB7; Tue, 1 Mar 2011 14:47:09 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PuYMW-00053h-4z; Tue, 01 Mar 2011 23:48:12 +0100 Message-ID: <532E2B721FB94531A4C751B0E9366BB4@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Russ Housley" , "The IESG" , References: <20110301222311.8199.68621.idtracker@localhost> In-Reply-To: <20110301222311.8199.68621.idtracker@localhost> Date: Tue, 1 Mar 2011 23:48:07 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 X-Mailman-Approved-At: Tue, 01 Mar 2011 14:58:19 -0800 Cc: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] Russ Housley's No Objection on draft-ietf-netconf-4741bis-09: (withCOMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 01 Mar 2011 22:47:12 -0000 If this becomes a common theme (that we forget to add the sentence), then I suggest that the xml2rfc tool does this automagically, from the same tag from which it generates the "Obsoletes:" label at the top of the front page. We will add the sentence. Bert ----- Original Message ----- From: "Russ Housley" To: "The IESG" Cc: ; Sent: Tuesday, March 01, 2011 11:23 PM Subject: Russ Housley's No Objection on draft-ietf-netconf-4741bis-09: (withCOMMENT) Russ Housley has entered the following ballot position for draft-ietf-netconf-4741bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please add a sentence to the Abstract that indicates that this document obsoletes RFC 4741. From bertietf@bwijnen.net Wed Mar 2 00:14:08 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8543A6A89 for ; Wed, 2 Mar 2011 00:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SYTUIwgQJqc for ; Wed, 2 Mar 2011 00:14:07 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id D4B863A69FB for ; Wed, 2 Mar 2011 00:14:06 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PuhDB-0006F4-C6 for netconf@ietf.org; Wed, 02 Mar 2011 09:15:10 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PuhDA-0005lO-Vj for netconf@ietf.org; Wed, 02 Mar 2011 09:15:09 +0100 Message-ID: <4D6DFC8C.2060506@bwijnen.net> Date: Wed, 02 Mar 2011 09:15:08 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ae81df809c9586ba250c7f1701b8feff Subject: [Netconf] Fwd: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:14:08 -0000 Can the editors/authors of the document take a look at the below please. Bert -------- Original Message -------- Subject: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Date: Tue, 01 Mar 2011 15:05:55 -0800 From: David Harrington To: The IESG CC: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org David Harrington has entered the following ballot position for draft-ietf-netconf-4741bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8? 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol? 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) copyright in yang module needs updating. 2) appendix F doesn't mention dropping the local file requirement for URLs, 3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0. 4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability. 5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control. From lars.eggert@nokia.com Tue Mar 1 23:55:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5093A6A43; Tue, 1 Mar 2011 23:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.268 X-Spam-Level: X-Spam-Status: No, score=-103.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, 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 CPbX3aD8qieR; Tue, 1 Mar 2011 23:55:18 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 08DA83A699F; Tue, 1 Mar 2011 23:55:17 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p227uHiA015327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 09:56:18 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-20-770305698; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D6D08DF.9000502@bwijnen.net> Date: Wed, 2 Mar 2011 09:56:09 +0200 Message-Id: References: <4D6D08DF.9000502@bwijnen.net> To: Bert (IETF) Wijnen X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 02 Mar 2011 09:56:14 +0200 (EET) X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 02 Mar 2011 00:16:58 -0800 Cc: "draft-ietf-netconf-4741bis@tools.ietf.org" , Netconf , "netconf-chairs@tools.ietf.org" , The IESG Subject: Re: [Netconf] Lars Eggert's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:55:18 -0000 --Apple-Mail-20-770305698 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-3-1, at 16:55, Bert (IETF) Wijnen wrote: > I find the text that you requires a bit heavy. I would claim, that any = document that describes > a transport (NETCONF or OTHER) must indeed comply with RFC2914. Such = has been the case for > many years. And RFC2914 is there to make sure all such documents = indeed do address > congestion control issues. >=20 > I do not see why RFC4741bis would have to REPEAT the 2914 language. > Whatever new NETCONF transport document ever will come out, it will = have to pass > the requirements of RFC2914, no? >=20 > If you (or better the IETF) is ever going to revise RFC2914, would we = then also have > to revise our text again? >=20 > So why are you asking this? as I said in the discuss, my only motivation is to prevent a potential = future argument for new NETCONF transport types. You are of course right that 2914 applies anyway. I simply thought a = reminder of that would make sense here. I'll change this from a discuss to a comment. Lars= --Apple-Mail-20-770305698 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwMjA3NTYwOVowIwYJKoZIhvcNAQkE MRYEFBe65NfIRX7blu6tzP2dAy/gz9zcMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AAFW01kvExHXmGm8MSq0wQtnHu+3INjtoxUQeJRAZnC7eMeL9czuWzu1XGBb2z9vvpupQR3HmXO8 /uIRRkX1l1srf4RVr8iZYyDQ+S3LXX6mMByWRVFqM8veT45EwOcR3FcqcuMUK5dLS2KeCybXd3Rc bwljhB2HmCfQ3wOatXTdygdd6Xn/qAx/lR7p+F+l1atXDsvznxU/hSs9qU4cWZ3rbs0OysYR1io7 yxZ1r1pzU1WElkisoUiA8J3w19RBJqLW0Q7XkGjzGjwi6PSilMrW7cdtC4cv4UaJU+TkhzmDmqfd NFhb2jzi2PplpbZXhVNN5TsfWjjRetU8XaBa4kMAAAAAAAA= --Apple-Mail-20-770305698-- From mehmet.ersue@nsn.com Wed Mar 2 00:56:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBD43A67F8 for ; Wed, 2 Mar 2011 00:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpyOQ-mMpS6C for ; Wed, 2 Mar 2011 00:56:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 601033A67EF for ; Wed, 2 Mar 2011 00:56:41 -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 p228vdFx018624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 09:57:40 +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 p228vcFc028087; Wed, 2 Mar 2011 09:57:39 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 09:57:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 09:57:25 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B56DE8@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Thread-Index: AcvXljnURMOJEwOuTVuDCR2OaI5dTAAjNFZwAA02O7AAA23HQAAUjDDQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , "Juergen Schoenwaelder" , "Andy Bierman" , "Netconf" X-OriginalArrivalTime: 02 Mar 2011 08:57:31.0520 (UTC) FILETIME=[DD652800:01CBD8B7] Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:56:43 -0000 FYI Cheers,=20 Mehmet=20 -----Original Message----- From: ext David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Wednesday, March 02, 2011 12:20 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: 'The IESG'; draft-ietf-netconf-rfc4742bis@tools.ietf.org; 'ext Romascanu, Dan (Dan)'; bertietf@bwijnen.net Subject: RE: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Hi, I just posted a DISCUSS againat 4741bis for a related issue.=20 I think username needs to meet some constraints to make it usable for the foreseeable uses, such as specifying an access policy for a specific username. Compare tmSecurityName from RFC3411 and RFC5590, which constrain the size, the character set, and the expected human readability. The algorithm must also produce a predictable value for use by human operators, given knowledge of the authentication parameters. I think there is also an issue of the uniqueness of username. If you have multiple transports supported in a NC implementation, must the usernames from, say, the SSH transport be unique only amongst the usernames generated by the SSH transport, or does the username need to also be unique across the TLS, SOAP, and BEEP transports as well? If it will be used by an access control mechanism, it will be important to know what parameters must be specified to uniquelyt identify a "user", such as in VACM, where we need to know the securityname AND the security model that generates the securityName. As with RFC5592, I agree that how you convert the authenticated identity from SSH depends on the SSH implementation, since the identity used in SSH (and other protocols) can vary dramatically depending on the underlying authentication mechanism. The discuss for 4742bis is the total lack of the explanation REQUIRED by 4741bis.=20 dbh=20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 > Sent: Tuesday, March 01, 2011 4:39 PM > To: ext David Harrington > Cc: The IESG; draft-ietf-netconf-rfc4742bis@tools.ietf.org;=20 > ext Romascanu, Dan (Dan); bertietf@bwijnen.net > Subject: FW: David Harrington's Discuss on=20 > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) >=20 > Hi Dave, >=20 > we discussed the issue with the username in the NETCONF WG=20 > intensively=20 > (see the 4742bis discussion in > http://www.ietf.org/proceedings/78/minutes/netconf.txt). >=20 > Naming policies might differ between administrative domains and=20 > identities represented as usernames mean different things in=20 > different operating systems. Following the statement in RFC 5592=20 > we decided that the method to obtain the username for the NETCONF=20 > Server from SSH should be implementation-dependant. >=20 > However, I agree that such an explanation is missing in the draft. >=20 > We discussed it again in the NETCONF ML and would like to suggest=20 > following text change.=20 >=20 > OLD: > How the NETCONF Server extracts the SSH user name from the=20 > SSH layer > is implementation-dependent. >=20 > NEW: > There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. Any transformations applied to > the authenticated user name by the SSH layer are outside the scope > of this document. >=20 >=20 > Would this text be sufficient for you? >=20 > Thank you for your support. >=20 > Regards, > Mehmet > (document shepherd) >=20 > -----Original Message----- > From: ext David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, February 28, 2011 11:23 PM > To: The IESG > Cc: netconf-chairs@tools.ietf.org; > draft-ietf-netconf-rfc4742bis@tools.ietf.org > Subject: David Harrington's Discuss on=20 > draft-ietf-netconf-rfc4742bis-07: > (withDISCUSS and COMMENT) >=20 > David Harrington has entered the following ballot position for > draft-ietf-netconf-rfc4742bis-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free=20 > to cut this > introductory paragraph, however.) >=20 > Please refer to=20 > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) 4741bis says: "The authentication process MUST result in an > authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The algorithm used to derive the username is > transport protocol specific and in addition specific to the > authentication mechanism used by the transport protocol. NETCONF > transport protocols therefore MUST explain how a NETCONF=20 > username is > derived from the authentication mechanisms supported by=20 > the transport > protocol. >=20 > The access permissions of a given client, identified by its NETCONF > username, are part of the configuration of the NETCONF=20 > server. These > permissions MUST be enforced during the remainder of the NETCONF > session. The details how access control is configured is=20 > outside the > scope of this document." >=20 > 4742bis says: "How the NETCONF Server extracts the SSH user name from > the SSH layer > is implementation-dependent." >=20 > This is not an explanation. Assuming an operator must specify access > control rights for a user in the configuration o fthe server, it is > important that the operator understands what the netconf username(s) > will be. That is presumably why it is important for the Netconf > transport protocol specification to explain the algorithm for deriving > the username. >=20 > RFC5592 defines an SSH subsystem for use with SNMP, and has=20 > had to deal > with similar issues, including constraints about not changing the > username associated with a session, allowing "user@host" style naming, > etc. > Maybe those are not needed for netconf, but the above > "implementation-dependent" explanations seems woefully inadequate. >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) The IANA section does not specify that the assigned port is a TCP > port. should it? >=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Mar 2 02:50:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3CE3A6778 for ; Wed, 2 Mar 2011 02:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 g7+J2I57yziW for ; Wed, 2 Mar 2011 02:50: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 785ED3A672F for ; Wed, 2 Mar 2011 02:50:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0751DC000E; Wed, 2 Mar 2011 11:51:07 +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 iXM6NTYa9X+p; Wed, 2 Mar 2011 11:51:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3A49C0009; Wed, 2 Mar 2011 11:51:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9000316D6DA6; Wed, 2 Mar 2011 11:51:01 +0100 (CET) Date: Wed, 2 Mar 2011 11:51:01 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20110302105101.GA14882@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , Andy Bierman , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A6401B56DE8@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B56DE8@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) 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, 02 Mar 2011 10:50:04 -0000 On Wed, Mar 02, 2011 at 09:57:25AM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > FYI > > Cheers, > Mehmet > > -----Original Message----- > From: ext David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, March 02, 2011 12:20 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: 'The IESG'; draft-ietf-netconf-rfc4742bis@tools.ietf.org; 'ext > Romascanu, Dan (Dan)'; bertietf@bwijnen.net > Subject: RE: David Harrington's Discuss on > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) > > Hi, > > I just posted a DISCUSS againat 4741bis for a related issue. > > I think username needs to meet some constraints to make it usable for > the foreseeable uses, such as specifying an access policy for a > specific username. Compare tmSecurityName from RFC3411 and RFC5590, > which constrain the size, the character set, and the expected human > readability. The algorithm must also produce a predictable value for > use by human operators, given knowledge of the authentication > parameters. I very much disagree. tmSecurityName faces size constraints because the SNMP notion of a securityName faces size restrictions and poses SNMP specific constraints on the character set. NETCONF does not suffer form this since it supports UTF8 and does not have string size constraints due to table indexing constraints. It is thus much more natural to use the security name as it is delivered by the secure transport. This is how everybody is using SSH. Telling operators they can't use all user names say SSH allows is simply a broken idea. With SNMP, we had to do this because SNMP is have all these constraints. I like to hear an operator telling us that the user name SSH delivers is not predictable. There are tons of existing command line interfaces for routers and bridges using SSH. They seem to work in practice. So where is the problem? > I think there is also an issue of the uniqueness of username. If you > have multiple transports supported in a NC implementation, must the > usernames from, say, the SSH transport be unique only amongst the > usernames generated by the SSH transport, or does the username need to > also be unique across the TLS, SOAP, and BEEP transports as well? If > it will be used by an access control mechanism, it will be important > to know what parameters must be specified to uniquelyt identify a > "user", such as in VACM, where we need to know the securityname AND > the security model that generates the securityName. 4741bis requires that a transport delivers a user name. Thats all and similar to how things are done with secure transports in SNMP land. Whether the ACM likes to scope the user name by the transport or not is a issue of the ACM design, which is an open work item and out of scope of 4741bis. > As with RFC5592, I agree that how you convert the authenticated > identity from SSH depends on the SSH implementation, since the > identity used in SSH (and other protocols) can vary dramatically > depending on the underlying authentication mechanism. > > The discuss for 4742bis is the total lack of the explanation REQUIRED > by 4741bis. So you think the proposed new text (see below) is not sufficient? > There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. Any transformations applied to > the authenticated user name by the SSH layer are outside the scope > of this document. I do not see what is missing. /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 Mar 2 06:38:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C85F3A6811; Wed, 2 Mar 2011 06:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.96 X-Spam-Level: X-Spam-Status: No, score=-105.96 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj87RJXXet61; Wed, 2 Mar 2011 06:38:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B64033A67D7; Wed, 2 Mar 2011 06:38:18 -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 p22EcsZc027749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 15:38:54 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p22EcsUn009162; Wed, 2 Mar 2011 15:38:54 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 15:38:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBD8E7.8CF71872" Date: Wed, 2 Mar 2011 15:38:50 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 Thread-Index: AcvYvoYkYw9+HAzCSb2daaK20EkCoAAF+ddAAALRCaA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 02 Mar 2011 14:38:53.0451 (UTC) FILETIME=[8D93CDB0:01CBD8E7] Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Mar 2011 14:38:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD8E7.8CF71872 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBD8E7.8CF71872" ------_=_NextPart_002_01CBD8E7.8CF71872 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sean, I detected your DISCUSS in the draft tracker (see below). However,=20 we, the WG chairs, did not get any alarm email. We were wondering=20 whether sending an alarm should be the default case for the IESG tool. DISCUSS #1: > #1) You state a max for chunk-size in 4.2 but I think you need a MUST for what > to do if a client or server sends something out-of-range (<=3D0 or >2^32-1).=20 > The idea is to get implementers not to leave buffer overrun vulnerabilities around. > (Same thing for what to do if chunk-size does contain leading zeros, or is > negative perhaps.)=20 Concerning the errors during the decoding process, which for sure includes=20 the case "chunk-size out-of-range", the draft says: OLD: "If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel." I think it is OK to add explicitly that the session is closed if an invalid-chunk size or=20 invalid chunk-size value is received.=20 NEW: "If the chunk-size and the chunk-size value respectively are invalid or an error=20 occurs during the decoding process, the peer MUST terminate the NETCONF=20 session by closing the corresponding SSH channel." > That may not be quite the same as saying "MUST terminate" at the very end of=20 > 4.2 if someone didn't consider the chunk-size part of the > decoding process.=20 > Lastly, as a bit of a mad corner-case, if I send a chunk that's 2^32-2 long (which=20 > is allowed) and then another chunk that's 10 bytes, but both are the same XML=20 > element, i.e. the " "" then is a server or client expected to be able to handle the overall =20 > element that's 2^32+8 bytes long?=20 > Maybe just add text that implementations SHOULD include an upper-limit that ensures > they're not vulnerable to buffer overruns or something. I think 4742bis document, as the NETCONF transport layer, shouldn't have to handle=20 with NETCONF message size (which is the size of the element). But I agree=20 that the document should state that the implementation needs to check for it to=20 "ensure they're not vulnerable to buffer overruns". (including the text for the first part above) OLD: If an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. NEW: "If the chunk-size or the chunk-size value is invalid or an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. Implementations MUST ensure they are not vulnerable for a buffer overrun." Would this be sufficient for you to clear your DISCUSS? DISCUSS #2: > #2) There's a mix of upper and lower case in the security considerations was > this purposely done? Specifically, it says "should" only be used with > confidentiality. Maybe "SHOULD" is better there? Also why isn't this a MUST? This is actually just an explanation about the requirement for NETCONF. The hard=20 requirement statement is in 4741bis. However, you are right 4742bis shouldn't=20 downgrade the requirement in 4741bis and should use "required" or something equal. OLD:=20 "So, NETCONF should only be used over communications channels that provide=20 strong encryption for data privacy." NEW: "So, NETCONF requires communications channels that provide strong encryption=20 for data privacy." Would this be sufficient for you to clear your DISCUSS? Comment #1: > #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be > a "MUST"? This is in the area of and a MUST statement in 4741bis. Comment #2)=20 > Sec 4.2: Would any XML decoding error cause termination as stated at > the end of 4.2? E.g. some unknown xmlns value or something? Interpreting the XML document content is not done in the transport layer (4742bis). 4741bis deals with this. There are a number of different error responses if the XML=20 message can't be understood or the XML message is not well-formed.=20 takes care of it. 4741bis says: "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an message that is not well-formed XML or not encoded in UTF-8, it SHOULD reply with a "malformed-message" error. If a reply cannot be sent for any reason, the server MUST close the session." Regards, Mehmet (document shepherd) ------------------=20 Discuss (2011-03-01) <>=20 #1) You state a max for chunk-size in 4.2 but I think you need a MUST for what to do if a client or server sends something out-of-range (<=3D0 or >2^32-1). The idea is to get implementers not to leave buffer overrun vulnerabilities around. (Same thing for what to do if chunk-size does contain leading zeros, or is negative perhaps.) That may not be quite the same as saying "MUST terminate" at the very end of 4.2 if someone didn't consider the chunk-size part of the decoding process. Lastly, as a bit of a mad corner-case, if I send a chunk that's 2^32-2 long (which is allowed) and then another chunk that's 10 bytes, but both are the same XML element, i.e. the "" then is a server or client expected to be able to handle the overall element that's 2^32+8 bytes long? Maybe just add text that implementations SHOULD include an upper-limit that ensures they're not vulnerable to buffer overruns or something. #2) There's a mix of upper and lower case in the security considerations was this purposely done? Specifically, it says "should" only be used with confidentiality. Maybe "SHOULD" is better there? Also why isn't this a MUST? Comment (2011-03-01) <>=20 #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be a "MUST"? #2) Sec 4.2: Would any XML decoding error cause termination as stated at the end of 4.2? E.g. some unknown xmlns value or something? Cheers,=20 Mehmet=20 ------_=_NextPart_002_01CBD8E7.8CF71872 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sean Turner's DISCUSS and COMMENT on = draft-ietf-netconf-rfc4742bis-07

Hi Sean,

I detected your DISCUSS in the draft tracker (see = below). However,

we, the WG chairs, did not get any alarm email. We were = wondering

whether sending an alarm should be the default case for = the IESG tool.

DISCUSS #1:

> #1) You state a max for chunk-size in 4.2 but I = think you need a MUST for what

> to do if a client or server sends something = out-of-range (<=3D0 or >2^32-1).

> The idea is to get implementers not to leave = buffer overrun vulnerabilities around.

> (Same thing for what to do if chunk-size does = contain leading zeros, or is

> negative perhaps.)

Concerning the errors during the decoding process, = which for sure includes

the case “chunk-size out-of-range”, the = draft says:

OLD:

   “If an error occurs during the = decoding process, the peer MUST

   terminate the NETCONF session by closing = the corresponding SSH

   channel.”

I think it is OK to add explicitly that the session is closed = if an invalid-chunk size or

invalid chunk-size value is received. =

NEW:

   “If the = chunk-size and the chunk-size value respectively are invalid or an error

    occurs during the decoding process, the peer = MUST terminate the NETCONF =

    session by closing the corresponding SSH = channel.”

> That may not be quite the same as saying = "MUST terminate" at the very end of

> 4.2 if someone didn't consider the chunk-size part = of the

> decoding process.

> Lastly, as a bit of a mad corner-case, if I send a = chunk that's 2^32-2 long (which

> is allowed) and then another chunk that's 10 = bytes, but both are the same XML

> element, i.e. the "<rpc..." is in the = 1st chunk and the 2nd chunk contains the closing

> "</rpc>" then is a server or = client expected to be able to handle the overall <rpc> =

> element that's 2^32+8 bytes long? =

> Maybe just add text that implementations SHOULD = include an upper-limit that ensures

> they're not vulnerable to buffer overruns or = something.

I think 4742bis document, as the NETCONF transport = layer, shouldn't have to handle

with NETCONF message size (which is the size of the = <rpc> element). But I agree

that the document should state that the implementation = needs to check for it to

“ensure they're not vulnerable to buffer = overruns”.

(including the text for the first part = above)

OLD:

   If an error occurs during the decoding = process, the peer MUST

   terminate the NETCONF session by closing = the corresponding SSH

   channel.

NEW:

    "If the chunk-size or the = chunk-size value is invalid or an error

     occurs during the decoding = process, the peer MUST terminate the

     NETCONF session by closing the = corresponding SSH channel.

     Implementations MUST ensure = they are not vulnerable for a buffer

     = overrun."

Would this be sufficient for you to clear your = DISCUSS?

DISCUSS #2:

> #2) There's a mix of upper and lower case in the = security considerations was

> this purposely done?  Specifically, it says = "should" only be used with

> confidentiality. Maybe "SHOULD" is = better there?  Also why isn't this a MUST?

This is actually just an explanation about the = requirement for NETCONF. The hard

requirement statement is in 4741bis. However, you are = right 4742bis shouldn’t

downgrade the requirement in 4741bis and = should use “required” or something equal.

OLD:

   “So, NETCONF should only be used over communications channels that = provide =

    strong encryption for data = privacy.”

NEW:

   “So, NETCONF requires communications channels that provide strong = encryption =

   for data privacy.”

Would this be sufficient for you to clear your DISCUSS?


Comment #1:

> #1) Sec 3.1: 2nd para, 1st sentence: Should the = "must" in the first paragraph be

> a "MUST"?

This is in the area of and a MUST statement in = 4741bis.

Comment #2)

> Sec 4.2: Would any XML decoding error cause = termination as stated at

> the end of 4.2? E.g. some unknown xmlns value or = something?

Interpreting the XML document content is not done in = the transport layer (4742bis).

4741bis deals with this. = There are a number of different error responses if the XML =

message can't be understood or the XML message is not = well-formed.

takes care of it.

4741bis says:

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

   peer receives an <rpc> = message that is not well-formed XML or not

   encoded in UTF-8, it SHOULD reply with a = "malformed-message" error.

   If a reply cannot be sent for any reason, the server = MUST close the

   session.”

Regards,

Mehmet

(document shepherd)

------------------

Discuss = (2011-03-01)=20 3D"Picture

#1) You state a max for chunk-size in 4.2 = but I think you need a MUST for what

to = do if a client or server sends something out-of-range (<=3D0 or = >2^32-1). The

idea is to get implementers not to leave buffer overrun = vulnerabilities around.

(Same thing for what to do if chunk-size does contain leading = zeros, or is

negative perhaps.) That may not be quite the same as saying = "MUST terminate" at

the very end of 4.2 if someone didn't consider the chunk-size part = of the

decoding process. Lastly, as a bit of a mad corner-case, if I send = a chunk

that's 2^32-2 long (which is allowed) and then another chunk that's = 10 bytes,

but both are the same XML element, i.e. the "<rpc..." = is in the 1st chunk and

the 2nd chunk contains the closing "</rpc>" then is = a server or client expected

to = be able to handle the overall <rpc> element that's 2^32+8 bytes = long? Maybe

just add text that implementations SHOULD include an upper-limit = that ensures

they're not vulnerable to buffer overruns or = something.

#2) There's a mix of upper and lower case in the security = considerations was

this purposely done?  Specifically, it says "should" = only be used with

confidentiality. Maybe "SHOULD" is better there?  = Also why isn't this a MUST?

Comment = (2011-03-01)=20 3D"Picture

#1) Sec 3.1: 2nd para, 1st sentence: = Should the "must" in the first paragraph be

a = "MUST"?

#2) Sec 4.2: Would any XML decoding error cause termination as = stated at

the end of 4.2? E.g. some unknown xmlns value or = something?

Cheers,
Mehmet

------_=_NextPart_002_01CBD8E7.8CF71872-- ------_=_NextPart_001_01CBD8E7.8CF71872 Content-Type: image/bmp; name="ole0.bmp" Content-Transfer-Encoding: base64 Content-Description: Picture (Device Independent Bitmap) Content-Location: No%20AttachName Qk26AQAAAAAAAPoAAAAoAAAADgAAAAwAAAABAAgAAAAAAAAAAAAAAAAAAAAAADEAAAAAAAAAzc3N AOOJaADc3d0A3d3dANLS0gDT0tIA4uLiANbX1wDj5OMAzMzMANnZ2ADd3NwA39/gAKBHJgDR0dEA 4OHhAOHh4QCukogA7Go6ANbW1gD29vYA29vbAM/Q0ADQ0NAA4ODgANXV1QCzdF0ArpOIAOTl5QDl 5eUA19fWANna2gDa2toA3t3eAM/PzwDb3NsA39/fANPU1ADU1NQA4OHgAP///wCgmpcA4IhoAM7O zgDb29oA3t7eANPT0wDk4+MA2NjYACgoKCgoKCgoKCgoKCgoAAAoKCgoKA0NKCgoKCgoKAAAKCgo KCgNFBoNEigoKCgAACgoKCgoKA0IGw0SKCgoAAAoKAENDQ0BDAsbGgEoKAAAKAEbCAgICAsLCyYb ASgAACgNCAgICwsLJiYmCQ0oAAAoDQgICAsLCyYmJgkNKAAAKA0ICAsLCyYmJgkJDSgAACgBKQgL CwsmJhYJGwEoAAAoKAENDQ0NDQ0NDQEoKAAAKCgoKCgoKCgoKCgoKCgAAA== ------_=_NextPart_001_01CBD8E7.8CF71872 Content-Type: image/bmp; name="ole1.bmp" Content-Transfer-Encoding: base64 Content-Description: Picture (Device Independent Bitmap) Content-Location: No%20AttachName-1 Qk26AQAAAAAAAPoAAAAoAAAADgAAAAwAAAABAAgAAAAAAAAAAAAAAAAAAAAAADEAAAAAAAAAzc3N AOOJaADc3d0A3d3dANLS0gDT0tIA4uLiANbX1wDj5OMAzMzMANnZ2ADd3NwA39/gAKBHJgDR0dEA 4OHhAOHh4QCukogA7Go6ANbW1gD29vYA29vbAM/Q0ADQ0NAA4ODgANXV1QCzdF0ArpOIAOTl5QDl 5eUA19fWANna2gDa2toA3t3eAM/PzwDb3NsA39/fANPU1ADU1NQA4OHgAP///wCgmpcA4IhoAM7O zgDb29oA3t7eANPT0wDk4+MA2NjYACgoKCgoKCgoKCgoKCgoAAAoKCgoKA0NKCgoKCgoKAAAKCgo KCgNFBoNEigoKCgAACgoKCgoKA0IGw0SKCgoAAAoKAENDQ0BDAsbGgEoKAAAKAEbCAgICAsLCyYb ASgAACgNCAgICwsLJiYmCQ0oAAAoDQgICAsLCyYmJgkNKAAAKA0ICAsLCyYmJgkJDSgAACgBKQgL CwsmJhYJGwEoAAAoKAENDQ0NDQ0NDQEoKAAAKCgoKCgoKCgoKCgoKCgAAA== ------_=_NextPart_001_01CBD8E7.8CF71872-- From turners@ieca.com Wed Mar 2 06:54:36 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674553A67A1 for ; Wed, 2 Mar 2011 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 eYcIQCy4AVqP for ; Wed, 2 Mar 2011 06:54:35 -0800 (PST) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by core3.amsl.com (Postfix) with SMTP id EF7C13A67D7 for ; Wed, 2 Mar 2011 06:54:34 -0800 (PST) Received: from [98.139.212.153] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2011 14:55:36 -0000 Received: from [98.139.212.204] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2011 14:55:36 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 02 Mar 2011 14:55:36 -0000 X-Yahoo-Newman-Id: 533493.75323.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 49428 invoked from network); 2 Mar 2011 14:55:35 -0000 Received: from thunderfish.local (turners@96.231.126.188 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 02 Mar 2011 06:55:35 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 3WTUIFIVM1l1AqpwXRDQV4GYRElMYtzZ5mH.AuyXUn9qrOn 4BlTKo1yDmL7s5mEBLbTFkAGeqc.AQFPA0dgEBncL3bacmwGkDsHyJBeAoNa Ss0z2TfMP8p3RM8pu2NJy0TKUXUxqgWhTOxqDT0QCrgBwtpIGME0ge8_Fsg0 YmCjYn_TQx0n14riTXWjvMDbLBQoQIdS1txelmRW84F0kKUIlDOWTtudrH.u Fyo4oqiwerdeg8VjqU123kSC2T.uOLP9sX1SW._vQQILAl45lpR8Yuvw70YE ig.3_FHrKaGuvovD9ke5G1xfrkoyHH9zoF7DpZyFdflu5EdS6C8D.z_DiD5Y F8FNyJGwZowLWwkE20g1Y5JnFp2gXdIrQnd6g3M203Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6E5A66.8080302@ieca.com> Date: Wed, 02 Mar 2011 09:55:34 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 02 Mar 2011 07:15:19 -0800 Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Mar 2011 14:54:36 -0000 Mehmet, Responses inline. spt On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Sean, > > I detected your DISCUSS in the draft tracker (see below). However, > > we, the WG chairs, did not get any alarm email. We were wondering > > whether sending an alarm should be the default case for the IESG tool. I think the problem was on my end. After we enter positions we can hit save or save and send. I guess I only hit save. > DISCUSS #1: > >> #1) You state a max for chunk-size in 4.2 but I think you need a MUST > for what > >> to do if a client or server sends something out-of-range (<=0 or > >2^32-1). > >> The idea is to get implementers not to leave buffer overrun > vulnerabilities around. > >> (Same thing for what to do if chunk-size does contain leading zeros, or is > >> negative perhaps.) > > Concerning the errors during the decoding process, which for sure includes > > the case “chunk-size out-of-range”, the draft says: > > OLD: > > “If an error occurs during the decoding process, the peer MUST > > terminate the NETCONF session by closing the corresponding SSH > > channel.” > > I think it is OK toaddexplicitlythat the session is closed if an > invalid-chunk size or > > invalid chunk-size value is received. > > NEW: > > “If the chunk-sizeandthe chunk-size valuerespectively areinvalid or an error > > occurs during the decoding process, the peer MUST terminate the NETCONF > > session by closing the corresponding SSH channel.” > >> That may not be quite the same as saying "MUST terminate" at the very > end of That would work for me. >> 4.2 if someone didn't consider the chunk-size part of the > >> decoding process. > >> Lastly, as a bit of a mad corner-case, if I send a chunk that's 2^32-2 > long (which > >> is allowed) and then another chunk that's 10 bytes, but both are the > same XML > >> element, i.e. the " contains the closing > >> "" then is a server or client expected to be able to handle the > overall > >> element that's 2^32+8 bytes long? > >> Maybe just add text that implementations SHOULD include an upper-limit > that ensures > >> they're not vulnerable to buffer overruns or something. > > I think 4742bis document, as the NETCONF transport layer, shouldn't have > to handle > > with NETCONF message size (which is the size of the element). But > I agree > > that the document should state that the implementation needs to check > for it to > > “ensure they're not vulnerable to buffer overruns”. > > (including the text for the first part above) > > OLD: > > If an error occurs during the decoding process, the peer MUST > > terminate the NETCONF session by closing the corresponding SSH > > channel. > > NEW: > > "If the chunk-size or the chunk-size value is invalid or an error > > occurs during the decoding process, the peer MUST terminate the > > NETCONF session by closing the corresponding SSH channel. > > Implementations MUST ensure they are not vulnerable for a buffer > > overrun." > > Would this be sufficient for you to clear your DISCUSS? Yes. > DISCUSS #2: > >> #2) There's a mix of upper and lower case in the security > considerations was > >> this purposely done? Specifically, it says "should" only be used with > >> confidentiality. Maybe "SHOULD" is better there? Also why isn't this a > MUST? > > This is actually just an explanation about the requirement for NETCONF. > The hard > > requirement statement is in 4741bis. However, you are right 4742bis > shouldn’t > > downgrade the requirement in 4741bis and shoulduse“required” > orsomethingequal. > > OLD: > > “So, NETCONF should only be used overcommunications channels that provide > > strong encryption for data privacy.” > > NEW: > > “So, NETCONFrequirescommunications channels that provide strong encryption > > for data privacy.” > > Would this be sufficient for youto clear your DISCUSS? Yes > Comment #1: > >> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first > paragraph be > >> a "MUST"? > > This is in the area of and a MUST statement in 4741bis. > > Comment #2) > >> Sec 4.2: Would any XML decoding error cause termination as stated at > >> the end of 4.2? E.g. some unknown xmlns value or something? > > Interpreting the XML document content is not done in the transport layer > (4742bis). > > 4741bis deals with this. There are a number of different error responses > if the XML > > message can't be understood or the XML message is not well-formed. > > takes care of it. > > 4741bis says: > > “All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > > peer receives an message that is not well-formed XML or not > > encoded in UTF-8, it SHOULD reply with a "malformed-message" error. > > If a reply cannot be sent for any reason, the server MUST close the > > session.” > > Regards, > > Mehmet > > (document shepherd) > > ------------------ > > *******Discuss (2011-03-01)*Picture (Device Independent Bitmap) > > #1) You state a max for chunk-size in 4.2 but I think you need a MUST > for what > > to do if a client or server sends something out-of-range (<=0 or > >2^32-1). The > > idea is to get implementers not to leave buffer overrun vulnerabilities > around. > > (Same thing for what to do if chunk-size does contain leading zeros, or is > > negative perhaps.) That may not be quite the same as saying "MUST > terminate" at > > the very end of 4.2 if someone didn't consider the chunk-size part of the > > decoding process. Lastly, as a bit of a mad corner-case, if I send a chunk > > that's 2^32-2 long (which is allowed) and then another chunk that's 10 > bytes, > > but both are the same XML element, i.e. the " chunk and > > the 2nd chunk contains the closing "" then is a server or client > expected > > to be able to handle the overall element that's 2^32+8 bytes long? > Maybe > > just add text that implementations SHOULD include an upper-limit that > ensures > > they're not vulnerable to buffer overruns or something. > > #2) There's a mix of upper and lower case in the security considerations was > > this purposely done? Specifically, it says "should" only be used with > > confidentiality. Maybe "SHOULD" is better there? Also why isn't this a MUST? > > *******Comment (2011-03-01)*Picture (Device Independent Bitmap) > > #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first > paragraph be > > a "MUST"? > > #2) Sec 4.2: Would any XML decoding error cause termination as stated at > > the end of 4.2? E.g. some unknown xmlns value or something? > > Cheers, > Mehmet > From phil@juniper.net Wed Mar 2 08:37:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A123A6831 for ; Wed, 2 Mar 2011 08:37:43 -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 8C0asPMYIVNU for ; Wed, 2 Mar 2011 08:37:41 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 9DE433A681E for ; Wed, 2 Mar 2011 08:37:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTW5ykqC441P7QQBCnMLiSLZ3X54tSVJn@postini.com; Wed, 02 Mar 2011 08:38:47 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 2 Mar 2011 08:04:40 -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 p22G5Pv26574; Wed, 2 Mar 2011 08:05: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 p22Ff9ij039041; Wed, 2 Mar 2011 15:41:35 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103021541.p22Ff9ij039041@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20110302105101.GA14882@elstar.local> Date: Wed, 2 Mar 2011 10:41:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Andy Bierman , Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:37:43 -0000 Juergen Schoenwaelder writes: >Telling operators they >can't use all user names say SSH allows is simply a broken idea. Amen. Making legitimate SSH user names illegal in NETCONF will mean that vendors choose between allowing their customers to continue to use odd user names and to enforce the NETCONF constraint at a cost to their customers. That's an easy choice. So many initial NETCONF implementations will enforce these constraints until customers complain, at which time the constraints will simply be removed. This will definitely not help interoperability, deployment, or happiness. And it helps teach people to ignore the constraints in the RFC, where they really do not need any help. Thanks, Phil From mehmet.ersue@nsn.com Wed Mar 2 12:21:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4EE3A6834; Wed, 2 Mar 2011 12:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z4MrPVOSw58; Wed, 2 Mar 2011 12:21:07 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5D7473A6823; Wed, 2 Mar 2011 12:21:01 -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 p22KLwCL005107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 21:21:58 +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 p22KLuZ1001328; Wed, 2 Mar 2011 21:21:58 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 21:21:36 +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, 2 Mar 2011 21:21:33 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B574CA@DEMUEXC006.nsn-intra.net> In-Reply-To: <4D6E5A66.8080302@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 Thread-Index: AcvY6ehxIf7DzVJxQ+ikuqCBVMr45gAIGV6g References: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> <4D6E5A66.8080302@ieca.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Sean Turner" X-OriginalArrivalTime: 02 Mar 2011 20:21:36.0866 (UTC) FILETIME=[6E53EC20:01CBD917] Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Mar 2011 20:21:09 -0000 Dear Sean, I interpreted your answer that your DISCUSS have been addressed. Is this correct? If yes, can you please clear your DISCUSS. If no, what can I do more? Thank you. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Sean Turner [mailto:turners@ieca.com] > Sent: Wednesday, March 02, 2011 3:56 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: The IESG; ext Romascanu, Dan (Dan); bertietf@bwijnen.net; draft- > ietf-netconf-rfc4742bis@tools.ietf.org; draft-ietf-netconf- > 4741bis@tools.ietf.org; Netconf > Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf- > rfc4742bis-07 >=20 > Mehmet, >=20 > Responses inline. >=20 > spt >=20 > On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Sean, > > > > I detected your DISCUSS in the draft tracker (see below). However, > > > > we, the WG chairs, did not get any alarm email. We were wondering > > > > whether sending an alarm should be the default case for the IESG > tool. >=20 > I think the problem was on my end. After we enter positions we can hit > save or save and send. I guess I only hit save. >=20 > > DISCUSS #1: > > > >> #1) You state a max for chunk-size in 4.2 but I think you need a > MUST > > for what > > > >> to do if a client or server sends something out-of-range (<=3D0 or > > >2^32-1). > > > >> The idea is to get implementers not to leave buffer overrun > > vulnerabilities around. > > > >> (Same thing for what to do if chunk-size does contain leading > zeros, or is > > > >> negative perhaps.) > > > > Concerning the errors during the decoding process, which for sure > includes > > > > the case "chunk-size out-of-range", the draft says: > > > > OLD: > > > > "If an error occurs during the decoding process, the peer MUST > > > > terminate the NETCONF session by closing the corresponding SSH > > > > channel." > > > > I think it is OK toaddexplicitlythat the session is closed if an > > invalid-chunk size or > > > > invalid chunk-size value is received. > > > > NEW: > > > > "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or > an error > > > > occurs during the decoding process, the peer MUST terminate the > NETCONF > > > > session by closing the corresponding SSH channel." > > > >> That may not be quite the same as saying "MUST terminate" at the > very > > end of >=20 > That would work for me. >=20 > >> 4.2 if someone didn't consider the chunk-size part of the > > > >> decoding process. > > > >> Lastly, as a bit of a mad corner-case, if I send a chunk that's > 2^32-2 > > long (which > > > >> is allowed) and then another chunk that's 10 bytes, but both are > the > > same XML > > > >> element, i.e. the " > contains the closing > > > >> "" then is a server or client expected to be able to handle > the > > overall > > > >> element that's 2^32+8 bytes long? > > > >> Maybe just add text that implementations SHOULD include an upper- > limit > > that ensures > > > >> they're not vulnerable to buffer overruns or something. > > > > I think 4742bis document, as the NETCONF transport layer, shouldn't > have > > to handle > > > > with NETCONF message size (which is the size of the element). > But > > I agree > > > > that the document should state that the implementation needs to check > > for it to > > > > "ensure they're not vulnerable to buffer overruns". > > > > (including the text for the first part above) > > > > OLD: > > > > If an error occurs during the decoding process, the peer MUST > > > > terminate the NETCONF session by closing the corresponding SSH > > > > channel. > > > > NEW: > > > > "If the chunk-size or the chunk-size value is invalid or an error > > > > occurs during the decoding process, the peer MUST terminate the > > > > NETCONF session by closing the corresponding SSH channel. > > > > Implementations MUST ensure they are not vulnerable for a buffer > > > > overrun." > > > > Would this be sufficient for you to clear your DISCUSS? >=20 > Yes. >=20 > > DISCUSS #2: > > > >> #2) There's a mix of upper and lower case in the security > > considerations was > > > >> this purposely done? Specifically, it says "should" only be used > with > > > >> confidentiality. Maybe "SHOULD" is better there? Also why isn't > this a > > MUST? > > > > This is actually just an explanation about the requirement for > NETCONF. > > The hard > > > > requirement statement is in 4741bis. However, you are right 4742bis > > shouldn't > > > > downgrade the requirement in 4741bis and shoulduse"required" > > orsomethingequal. > > > > OLD: > > > > "So, NETCONF should only be used overcommunications channels that > provide > > > > strong encryption for data privacy." > > > > NEW: > > > > "So, NETCONFrequirescommunications channels that provide strong > encryption > > > > for data privacy." > > > > Would this be sufficient for youto clear your DISCUSS? >=20 > Yes >=20 > > Comment #1: > > > >> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first > > paragraph be > > > >> a "MUST"? > > > > This is in the area of and a MUST statement in 4741bis. > > > > Comment #2) > > > >> Sec 4.2: Would any XML decoding error cause termination as stated > at > > > >> the end of 4.2? E.g. some unknown xmlns value or something? > > > > Interpreting the XML document content is not done in the transport > layer > > (4742bis). > > > > 4741bis deals with this. There are a number of different error > responses > > if the XML > > > > message can't be understood or the XML message is not well-formed. > > > > takes care of it. > > > > 4741bis says: > > > > "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > > > > peer receives an message that is not well-formed XML or not > > > > encoded in UTF-8, it SHOULD reply with a "malformed-message" error. > > > > If a reply cannot be sent for any reason, the server MUST close the > > > > session." > > > > Regards, > > > > Mehmet > > > > (document shepherd) > > > > ------------------ > > > > *******Discuss (2011-03-01)*Picture (Device Independent Bitmap) > > > > #1) You state a max for chunk-size in 4.2 but I think you need a MUST > > for what > > > > to do if a client or server sends something out-of-range (<=3D0 or > > >2^32-1). The > > > > idea is to get implementers not to leave buffer overrun > vulnerabilities > > around. > > > > (Same thing for what to do if chunk-size does contain leading zeros, > or is > > > > negative perhaps.) That may not be quite the same as saying "MUST > > terminate" at > > > > the very end of 4.2 if someone didn't consider the chunk-size part of > the > > > > decoding process. Lastly, as a bit of a mad corner-case, if I send a > chunk > > > > that's 2^32-2 long (which is allowed) and then another chunk that's > 10 > > bytes, > > > > but both are the same XML element, i.e. the " > chunk and > > > > the 2nd chunk contains the closing "" then is a server or > client > > expected > > > > to be able to handle the overall element that's 2^32+8 bytes > long? > > Maybe > > > > just add text that implementations SHOULD include an upper-limit that > > ensures > > > > they're not vulnerable to buffer overruns or something. > > > > #2) There's a mix of upper and lower case in the security > considerations was > > > > this purposely done? Specifically, it says "should" only be used with > > > > confidentiality. Maybe "SHOULD" is better there? Also why isn't this > a MUST? > > > > *******Comment (2011-03-01)*Picture (Device Independent Bitmap) > > > > #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first > > paragraph be > > > > a "MUST"? > > > > #2) Sec 4.2: Would any XML decoding error cause termination as stated > at > > > > the end of 4.2? E.g. some unknown xmlns value or something? > > > > Cheers, > > Mehmet > > From turners@ieca.com Wed Mar 2 13:43:38 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1903A68D1 for ; Wed, 2 Mar 2011 13:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 CyX2C67Jc3mx for ; Wed, 2 Mar 2011 13:43:37 -0800 (PST) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by core3.amsl.com (Postfix) with SMTP id 5A4633A68CB for ; Wed, 2 Mar 2011 13:43:37 -0800 (PST) Received: from [98.139.91.62] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2011 21:44:41 -0000 Received: from [98.139.91.10] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2011 21:44:41 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 02 Mar 2011 21:44:41 -0000 X-Yahoo-Newman-Id: 729854.52831.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 75755 invoked from network); 2 Mar 2011 21:44:41 -0000 Received: from thunderfish.local (turners@96.241.2.32 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 02 Mar 2011 13:44:40 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 0OjngqQVM1lgRYFZI4GEYwms7dXXRhC7PRgaVHROLbuUo5h P2HB1mFGg9WaemdELApYxxVrodUg_Oij3Yz6s339AZbnn7WEtid2NhsqzBiD gNRXXfwmPe_Ua9_IuaXYkH45Qc1.TDUkQuqHpa6MsCN3bubX3rVYExQonGAL TS_7ewtDHrZChDSAa.bGOs_DxReWaMMUzHY5vT2Zy_q4fMxKCqcpDUnJmXia LWF5seBNd70JbUtyrTHyU8Peg_GqS8ONztGbpR2PQFm559sRMkxmN23YEy3u vpifKjZwu6z3vfEgY1WfsAutXSGI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6EBA46.5030905@ieca.com> Date: Wed, 02 Mar 2011 16:44:38 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> <4D6E5A66.8080302@ieca.com> <80A0822C5E9A4440A5117C2F4CD36A6401B574CA@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B574CA@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Mar 2011 21:43:38 -0000 Mehemt, Normally, IESG members hold their discusses until either a) a new draft is posted that incorporates the agreed changes or b) an RFC editor's note is included in the IESG evaluation tab (by your AD). If either of these happen, then I'll clear. It's most a double check that you incorporate what you said you would (not picking on you we do this to just about everybody). spt On 3/2/11 3:21 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Sean, > > I interpreted your answer that your DISCUSS have been addressed. > Is this correct? > > If yes, can you please clear your DISCUSS. > If no, what can I do more? > > Thank you. > > Cheers, > Mehmet > > >> -----Original Message----- >> From: ext Sean Turner [mailto:turners@ieca.com] >> Sent: Wednesday, March 02, 2011 3:56 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: The IESG; ext Romascanu, Dan (Dan); bertietf@bwijnen.net; draft- >> ietf-netconf-rfc4742bis@tools.ietf.org; draft-ietf-netconf- >> 4741bis@tools.ietf.org; Netconf >> Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf- >> rfc4742bis-07 >> >> Mehmet, >> >> Responses inline. >> >> spt >> >> On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Hi Sean, >>> >>> I detected your DISCUSS in the draft tracker (see below). However, >>> >>> we, the WG chairs, did not get any alarm email. We were wondering >>> >>> whether sending an alarm should be the default case for the IESG >> tool. >> >> I think the problem was on my end. After we enter positions we can > hit >> save or save and send. I guess I only hit save. >> >>> DISCUSS #1: >>> >>>> #1) You state a max for chunk-size in 4.2 but I think you need a >> MUST >>> for what >>> >>>> to do if a client or server sends something out-of-range (<=0 or >>> >2^32-1). >>> >>>> The idea is to get implementers not to leave buffer overrun >>> vulnerabilities around. >>> >>>> (Same thing for what to do if chunk-size does contain leading >> zeros, or is >>> >>>> negative perhaps.) >>> >>> Concerning the errors during the decoding process, which for sure >> includes >>> >>> the case "chunk-size out-of-range", the draft says: >>> >>> OLD: >>> >>> "If an error occurs during the decoding process, the peer MUST >>> >>> terminate the NETCONF session by closing the corresponding SSH >>> >>> channel." >>> >>> I think it is OK toaddexplicitlythat the session is closed if an >>> invalid-chunk size or >>> >>> invalid chunk-size value is received. >>> >>> NEW: >>> >>> "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or >> an error >>> >>> occurs during the decoding process, the peer MUST terminate the >> NETCONF >>> >>> session by closing the corresponding SSH channel." >>> >>>> That may not be quite the same as saying "MUST terminate" at the >> very >>> end of >> >> That would work for me. >> >>>> 4.2 if someone didn't consider the chunk-size part of the >>> >>>> decoding process. >>> >>>> Lastly, as a bit of a mad corner-case, if I send a chunk that's >> 2^32-2 >>> long (which >>> >>>> is allowed) and then another chunk that's 10 bytes, but both are >> the >>> same XML >>> >>>> element, i.e. the ">> contains the closing >>> >>>> "" then is a server or client expected to be able to handle >> the >>> overall >>> >>>> element that's 2^32+8 bytes long? >>> >>>> Maybe just add text that implementations SHOULD include an upper- >> limit >>> that ensures >>> >>>> they're not vulnerable to buffer overruns or something. >>> >>> I think 4742bis document, as the NETCONF transport layer, shouldn't >> have >>> to handle >>> >>> with NETCONF message size (which is the size of the element). >> But >>> I agree >>> >>> that the document should state that the implementation needs to > check >>> for it to >>> >>> "ensure they're not vulnerable to buffer overruns". >>> >>> (including the text for the first part above) >>> >>> OLD: >>> >>> If an error occurs during the decoding process, the peer MUST >>> >>> terminate the NETCONF session by closing the corresponding SSH >>> >>> channel. >>> >>> NEW: >>> >>> "If the chunk-size or the chunk-size value is invalid or an error >>> >>> occurs during the decoding process, the peer MUST terminate the >>> >>> NETCONF session by closing the corresponding SSH channel. >>> >>> Implementations MUST ensure they are not vulnerable for a buffer >>> >>> overrun." >>> >>> Would this be sufficient for you to clear your DISCUSS? >> >> Yes. >> >>> DISCUSS #2: >>> >>>> #2) There's a mix of upper and lower case in the security >>> considerations was >>> >>>> this purposely done? Specifically, it says "should" only be used >> with >>> >>>> confidentiality. Maybe "SHOULD" is better there? Also why isn't >> this a >>> MUST? >>> >>> This is actually just an explanation about the requirement for >> NETCONF. >>> The hard >>> >>> requirement statement is in 4741bis. However, you are right 4742bis >>> shouldn't >>> >>> downgrade the requirement in 4741bis and shoulduse"required" >>> orsomethingequal. >>> >>> OLD: >>> >>> "So, NETCONF should only be used overcommunications channels that >> provide >>> >>> strong encryption for data privacy." >>> >>> NEW: >>> >>> "So, NETCONFrequirescommunications channels that provide strong >> encryption >>> >>> for data privacy." >>> >>> Would this be sufficient for youto clear your DISCUSS? >> >> Yes >> >>> Comment #1: >>> >>>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the > first >>> paragraph be >>> >>>> a "MUST"? >>> >>> This is in the area of and a MUST statement in 4741bis. >>> >>> Comment #2) >>> >>>> Sec 4.2: Would any XML decoding error cause termination as stated >> at >>> >>>> the end of 4.2? E.g. some unknown xmlns value or something? >>> >>> Interpreting the XML document content is not done in the transport >> layer >>> (4742bis). >>> >>> 4741bis deals with this. There are a number of different error >> responses >>> if the XML >>> >>> message can't be understood or the XML message is not well-formed. >>> >>> takes care of it. >>> >>> 4741bis says: >>> >>> "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If > a >>> >>> peer receives an message that is not well-formed XML or not >>> >>> encoded in UTF-8, it SHOULD reply with a "malformed-message" error. >>> >>> If a reply cannot be sent for any reason, the server MUST close the >>> >>> session." >>> >>> Regards, >>> >>> Mehmet >>> >>> (document shepherd) >>> >>> ------------------ >>> >>> *******Discuss (2011-03-01)*Picture (Device Independent Bitmap) >>> >>> #1) You state a max for chunk-size in 4.2 but I think you need a > MUST >>> for what >>> >>> to do if a client or server sends something out-of-range (<=0 or >>> >2^32-1). The >>> >>> idea is to get implementers not to leave buffer overrun >> vulnerabilities >>> around. >>> >>> (Same thing for what to do if chunk-size does contain leading zeros, >> or is >>> >>> negative perhaps.) That may not be quite the same as saying "MUST >>> terminate" at >>> >>> the very end of 4.2 if someone didn't consider the chunk-size part > of >> the >>> >>> decoding process. Lastly, as a bit of a mad corner-case, if I send a >> chunk >>> >>> that's 2^32-2 long (which is allowed) and then another chunk that's >> 10 >>> bytes, >>> >>> but both are the same XML element, i.e. the ">> chunk and >>> >>> the 2nd chunk contains the closing "" then is a server or >> client >>> expected >>> >>> to be able to handle the overall element that's 2^32+8 bytes >> long? >>> Maybe >>> >>> just add text that implementations SHOULD include an upper-limit > that >>> ensures >>> >>> they're not vulnerable to buffer overruns or something. >>> >>> #2) There's a mix of upper and lower case in the security >> considerations was >>> >>> this purposely done? Specifically, it says "should" only be used > with >>> >>> confidentiality. Maybe "SHOULD" is better there? Also why isn't this >> a MUST? >>> >>> *******Comment (2011-03-01)*Picture (Device Independent Bitmap) >>> >>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first >>> paragraph be >>> >>> a "MUST"? >>> >>> #2) Sec 4.2: Would any XML decoding error cause termination as > stated >> at >>> >>> the end of 4.2? E.g. some unknown xmlns value or something? >>> >>> Cheers, >>> Mehmet >>> > From mehmet.ersue@nsn.com Wed Mar 2 14:03:34 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2698F3A68B5; Wed, 2 Mar 2011 14:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzMW5CEs7Q5U; Wed, 2 Mar 2011 14:03:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AD2CC3A67D9; Wed, 2 Mar 2011 14:03:28 -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 p22M4RAW014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 23:04:27 +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 p22M4Phu005751; Wed, 2 Mar 2011 23:04:27 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 23:04:25 +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, 2 Mar 2011 23:04:23 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B574E2@DEMUEXC006.nsn-intra.net> In-Reply-To: <4D6EBA46.5030905@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 Thread-Index: AcvZIw2Jy4CmY0p2Rl2DRyR4tkXVtAAAn7qw References: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> <4D6E5A66.8080302@ieca.com> <80A0822C5E9A4440A5117C2F4CD36A6401B574CA@DEMUEXC006.nsn-intra.net> <4D6EBA46.5030905@ieca.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Sean Turner" X-OriginalArrivalTime: 02 Mar 2011 22:04:25.0749 (UTC) FILETIME=[CB44C450:01CBD925] Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Mar 2011 22:03:34 -0000 Dear Sean, thank you for your support. The RFC Editor's note is on the way. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Sean Turner [mailto:turners@ieca.com] > Sent: Wednesday, March 02, 2011 10:45 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: The IESG; ext Romascanu, Dan (Dan); bertietf@bwijnen.net; draft- > ietf-netconf-rfc4742bis@tools.ietf.org; draft-ietf-netconf- > 4741bis@tools.ietf.org; Netconf > Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf- > rfc4742bis-07 >=20 > Mehemt, >=20 > Normally, IESG members hold their discusses until either a) a new draft > is posted that incorporates the agreed changes or b) an RFC editor's > note is included in the IESG evaluation tab (by your AD). If either of > these happen, then I'll clear. It's most a double check that you > incorporate what you said you would (not picking on you we do this to > just about everybody). >=20 > spt >=20 > On 3/2/11 3:21 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear Sean, > > > > I interpreted your answer that your DISCUSS have been addressed. > > Is this correct? > > > > If yes, can you please clear your DISCUSS. > > If no, what can I do more? > > > > Thank you. > > > > Cheers, > > Mehmet > > > > > >> -----Original Message----- > >> From: ext Sean Turner [mailto:turners@ieca.com] > >> Sent: Wednesday, March 02, 2011 3:56 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: The IESG; ext Romascanu, Dan (Dan); bertietf@bwijnen.net; draft- > >> ietf-netconf-rfc4742bis@tools.ietf.org; draft-ietf-netconf- > >> 4741bis@tools.ietf.org; Netconf > >> Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf- > netconf- > >> rfc4742bis-07 > >> > >> Mehmet, > >> > >> Responses inline. > >> > >> spt > >> > >> On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > >>> Hi Sean, > >>> > >>> I detected your DISCUSS in the draft tracker (see below). However, > >>> > >>> we, the WG chairs, did not get any alarm email. We were wondering > >>> > >>> whether sending an alarm should be the default case for the IESG > >> tool. > >> > >> I think the problem was on my end. After we enter positions we can > > hit > >> save or save and send. I guess I only hit save. > >> > >>> DISCUSS #1: > >>> > >>>> #1) You state a max for chunk-size in 4.2 but I think you need a > >> MUST > >>> for what > >>> > >>>> to do if a client or server sends something out-of-range (<=3D0 or > >>> >2^32-1). > >>> > >>>> The idea is to get implementers not to leave buffer overrun > >>> vulnerabilities around. > >>> > >>>> (Same thing for what to do if chunk-size does contain leading > >> zeros, or is > >>> > >>>> negative perhaps.) > >>> > >>> Concerning the errors during the decoding process, which for sure > >> includes > >>> > >>> the case "chunk-size out-of-range", the draft says: > >>> > >>> OLD: > >>> > >>> "If an error occurs during the decoding process, the peer MUST > >>> > >>> terminate the NETCONF session by closing the corresponding SSH > >>> > >>> channel." > >>> > >>> I think it is OK toaddexplicitlythat the session is closed if an > >>> invalid-chunk size or > >>> > >>> invalid chunk-size value is received. > >>> > >>> NEW: > >>> > >>> "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or > >> an error > >>> > >>> occurs during the decoding process, the peer MUST terminate the > >> NETCONF > >>> > >>> session by closing the corresponding SSH channel." > >>> > >>>> That may not be quite the same as saying "MUST terminate" at the > >> very > >>> end of > >> > >> That would work for me. > >> > >>>> 4.2 if someone didn't consider the chunk-size part of the > >>> > >>>> decoding process. > >>> > >>>> Lastly, as a bit of a mad corner-case, if I send a chunk that's > >> 2^32-2 > >>> long (which > >>> > >>>> is allowed) and then another chunk that's 10 bytes, but both are > >> the > >>> same XML > >>> > >>>> element, i.e. the " chunk > >>> contains the closing > >>> > >>>> "" then is a server or client expected to be able to > handle > >> the > >>> overall > >>> > >>>> element that's 2^32+8 bytes long? > >>> > >>>> Maybe just add text that implementations SHOULD include an > upper- > >> limit > >>> that ensures > >>> > >>>> they're not vulnerable to buffer overruns or something. > >>> > >>> I think 4742bis document, as the NETCONF transport layer, shouldn't > >> have > >>> to handle > >>> > >>> with NETCONF message size (which is the size of the element). > >> But > >>> I agree > >>> > >>> that the document should state that the implementation needs to > > check > >>> for it to > >>> > >>> "ensure they're not vulnerable to buffer overruns". > >>> > >>> (including the text for the first part above) > >>> > >>> OLD: > >>> > >>> If an error occurs during the decoding process, the peer MUST > >>> > >>> terminate the NETCONF session by closing the corresponding SSH > >>> > >>> channel. > >>> > >>> NEW: > >>> > >>> "If the chunk-size or the chunk-size value is invalid or an error > >>> > >>> occurs during the decoding process, the peer MUST terminate the > >>> > >>> NETCONF session by closing the corresponding SSH channel. > >>> > >>> Implementations MUST ensure they are not vulnerable for a buffer > >>> > >>> overrun." > >>> > >>> Would this be sufficient for you to clear your DISCUSS? > >> > >> Yes. > >> > >>> DISCUSS #2: > >>> > >>>> #2) There's a mix of upper and lower case in the security > >>> considerations was > >>> > >>>> this purposely done? Specifically, it says "should" only be used > >> with > >>> > >>>> confidentiality. Maybe "SHOULD" is better there? Also why isn't > >> this a > >>> MUST? > >>> > >>> This is actually just an explanation about the requirement for > >> NETCONF. > >>> The hard > >>> > >>> requirement statement is in 4741bis. However, you are right 4742bis > >>> shouldn't > >>> > >>> downgrade the requirement in 4741bis and shoulduse"required" > >>> orsomethingequal. > >>> > >>> OLD: > >>> > >>> "So, NETCONF should only be used overcommunications channels that > >> provide > >>> > >>> strong encryption for data privacy." > >>> > >>> NEW: > >>> > >>> "So, NETCONFrequirescommunications channels that provide strong > >> encryption > >>> > >>> for data privacy." > >>> > >>> Would this be sufficient for youto clear your DISCUSS? > >> > >> Yes > >> > >>> Comment #1: > >>> > >>>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the > > first > >>> paragraph be > >>> > >>>> a "MUST"? > >>> > >>> This is in the area of and a MUST statement in 4741bis. > >>> > >>> Comment #2) > >>> > >>>> Sec 4.2: Would any XML decoding error cause termination as > stated > >> at > >>> > >>>> the end of 4.2? E.g. some unknown xmlns value or something? > >>> > >>> Interpreting the XML document content is not done in the transport > >> layer > >>> (4742bis). > >>> > >>> 4741bis deals with this. There are a number of different error > >> responses > >>> if the XML > >>> > >>> message can't be understood or the XML message is not well-formed. > >>> > >>> takes care of it. > >>> > >>> 4741bis says: > >>> > >>> "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If > > a > >>> > >>> peer receives an message that is not well-formed XML or not > >>> > >>> encoded in UTF-8, it SHOULD reply with a "malformed-message" error. > >>> > >>> If a reply cannot be sent for any reason, the server MUST close the > >>> > >>> session." > >>> > >>> Regards, > >>> > >>> Mehmet > >>> > >>> (document shepherd) > >>> > >>> ------------------ > >>> > >>> *******Discuss (2011-03-01)*Picture (Device Independent Bitmap) > >>> > >>> #1) You state a max for chunk-size in 4.2 but I think you need a > > MUST > >>> for what > >>> > >>> to do if a client or server sends something out-of-range (<=3D0 or > >>> >2^32-1). The > >>> > >>> idea is to get implementers not to leave buffer overrun > >> vulnerabilities > >>> around. > >>> > >>> (Same thing for what to do if chunk-size does contain leading > zeros, > >> or is > >>> > >>> negative perhaps.) That may not be quite the same as saying "MUST > >>> terminate" at > >>> > >>> the very end of 4.2 if someone didn't consider the chunk-size part > > of > >> the > >>> > >>> decoding process. Lastly, as a bit of a mad corner-case, if I send > a > >> chunk > >>> > >>> that's 2^32-2 long (which is allowed) and then another chunk that's > >> 10 > >>> bytes, > >>> > >>> but both are the same XML element, i.e. the " >>> chunk and > >>> > >>> the 2nd chunk contains the closing "" then is a server or > >> client > >>> expected > >>> > >>> to be able to handle the overall element that's 2^32+8 bytes > >> long? > >>> Maybe > >>> > >>> just add text that implementations SHOULD include an upper-limit > > that > >>> ensures > >>> > >>> they're not vulnerable to buffer overruns or something. > >>> > >>> #2) There's a mix of upper and lower case in the security > >> considerations was > >>> > >>> this purposely done? Specifically, it says "should" only be used > > with > >>> > >>> confidentiality. Maybe "SHOULD" is better there? Also why isn't > this > >> a MUST? > >>> > >>> *******Comment (2011-03-01)*Picture (Device Independent Bitmap) > >>> > >>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first > >>> paragraph be > >>> > >>> a "MUST"? > >>> > >>> #2) Sec 4.2: Would any XML decoding error cause termination as > > stated > >> at > >>> > >>> the end of 4.2? E.g. some unknown xmlns value or something? > >>> > >>> Cheers, > >>> Mehmet > >>> > > From bertietf@bwijnen.net Thu Mar 3 00:26:17 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4690D3A6981 for ; Thu, 3 Mar 2011 00:26:17 -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 o9pYVGtRgvmr for ; Thu, 3 Mar 2011 00:26:16 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id E1CD23A694D for ; Thu, 3 Mar 2011 00:26:11 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv3sS-00023L-AB for netconf@ietf.org; Thu, 03 Mar 2011 09:27:17 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv3sS-0006Ew-61 for netconf@ietf.org; Thu, 03 Mar 2011 09:27:16 +0100 Message-ID: <4D6F50E4.2080403@bwijnen.net> Date: Thu, 03 Mar 2011 09:27:16 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d5b46f8a1af6bc6dd11f24eacc2ed075 Subject: [Netconf] Fwd: Adrian Farrel's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:26:17 -0000 I wonder if we actually need those 2 comment lines on page 93 // the namespace for NETCONF XML definitions has not changed // this value is pre-determined by RFC 4741 And otherwise, is that definition not also in the 4741bis document, so we can refer to a section in our 4741bis doc? Bert Document Shepherd -------- Original Message -------- Subject: Adrian Farrel's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) Date: Wed, 02 Mar 2011 09:53:57 -0800 From: Adrian Farrel To: The IESG CC: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Adrian Farrel has entered the following ballot position for draft-ietf-netconf-4741bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am entering a No Objection position on the basis of the Yes ballots fromt the Ops ADs. Appendix C seems to claim that "this value is pre-determined by RFC 4741" but since 4741 is now obsoleted (by this document) you should find some new text. From j.schoenwaelder@jacobs-university.de Thu Mar 3 00:30:05 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320723A6990 for ; Thu, 3 Mar 2011 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Ca82fVp5RWzL for ; Thu, 3 Mar 2011 00: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 E39BE3A694D for ; Thu, 3 Mar 2011 00:30:03 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E80FAC001F; Thu, 3 Mar 2011 09:31:10 +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 4Q6Pn4U8fMwF; Thu, 3 Mar 2011 09:31: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 50D92C001A; Thu, 3 Mar 2011 09:31:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CECBC16D9340; Thu, 3 Mar 2011 09:31:05 +0100 (CET) Date: Thu, 3 Mar 2011 09:31:05 +0100 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20110303083105.GA19449@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , netconf References: <4D6F50E4.2080403@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6F50E4.2080403@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] Fwd: Adrian Farrel's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) 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, 03 Mar 2011 08:30:05 -0000 On Thu, Mar 03, 2011 at 09:27:16AM +0100, Bert (IETF) Wijnen wrote: > I wonder if we actually need those 2 comment lines on page 93 > // the namespace for NETCONF XML definitions has not changed > // this value is pre-determined by RFC 4741 > > And otherwise, is that definition not also in the 4741bis document, so we > can refer to a section in our 4741bis doc? Comments by definition can be removed, except that you loose additional explanations. In this case, a reader might wonder why the namespace is 1.0 and the comment tries to convey (likely in an imperfect way) that this is not an error but by intention. That said, I am happy to accept any IESG advice on 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 bertietf@bwijnen.net Thu Mar 3 00:37:30 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2817D3A698D for ; Thu, 3 Mar 2011 00:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 LJyj5Cjib1kd for ; Thu, 3 Mar 2011 00:37:29 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id ED2673A6988 for ; Thu, 3 Mar 2011 00:37:28 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv43O-0002ME-DU for netconf@ietf.org; Thu, 03 Mar 2011 09:38:35 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv43N-00071q-Qv for netconf@ietf.org; Thu, 03 Mar 2011 09:38:33 +0100 Message-ID: <4D6F5389.1000500@bwijnen.net> Date: Thu, 03 Mar 2011 09:38:33 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf References: <4D6F50E4.2080403@bwijnen.net> <20110303083105.GA19449@elstar.local> In-Reply-To: <20110303083105.GA19449@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd420e5b0628633b0b18f11df830b48ab11 Subject: Re: [Netconf] Fwd: Adrian Farrel's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:37:30 -0000 On 3/3/11 9:31 AM, Juergen Schoenwaelder wrote: >> I wonder if we actually need those 2 comment lines on page 93 >> > // the namespace for NETCONF XML definitions has not changed >> > // this value is pre-determined by RFC 4741 >> > >> > And otherwise, is that definition not also in the 4741bis document, so we >> > can refer to a section in our 4741bis doc? > Comments by definition can be removed, except that you loose > additional explanations. In this case, a reader might wonder why the > namespace is 1.0 and the comment tries to convey (likely in an > imperfect way) that this is not an error but by intention. That said, > I am happy to accept any IESG advice on this.;-) > > /js I can see however, that someone might think that rfc4741 is a normative reference because the above text is in a normative appendix. Maybe this might help:? // the namespace for NETCONF XML definitions has not changed // so this value is still the same as it was in RFC 4741 Bert From bertietf@bwijnen.net Thu Mar 3 02:23:56 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D210B3A69A2 for ; Thu, 3 Mar 2011 02:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 vQIQ6D2Y5Km4 for ; Thu, 3 Mar 2011 02:23:55 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 71E683A68E3 for ; Thu, 3 Mar 2011 02:23:54 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv5iB-00069y-HF for netconf@ietf.org; Thu, 03 Mar 2011 11:24:59 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv5iB-00052s-Dw for netconf@ietf.org; Thu, 03 Mar 2011 11:24:47 +0100 Message-ID: <4D6F6C6F.8080803@bwijnen.net> Date: Thu, 03 Mar 2011 11:24:47 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd492e807fe5524cc974aae570ba44724cd Subject: [Netconf] Fwd: Tim Polk's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 10:23:56 -0000 FYI and comment -------- Original Message -------- Subject: Tim Polk's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) Date: Wed, 02 Mar 2011 18:34:24 -0800 From: Tim Polk To: The IESG CC: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Tim Polk has entered the following ballot position for draft-ietf-netconf-4741bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) 2.2. paragraph 1 - last sentence is awkward. In general connections are encrypted "in" an algorithm (e.g., AES) or "using" a protocol (e.g., TLS). Suggest: s/encrypted in TLS [16] or SSH [14]/encrypted using TLS [16] or SSH [14]/ (2) 3.1. Namespace Should this text reference the namespace base:1.1 instead of base:1.0 ?? (3) The example in 6.2.2 Attribute Match Expressions references containment nodes and selection nodes, which are described in 6.2.3 and 6.2.4, respectively. It might be cleaner to reorder as 6.2.2 Containment Nodes, 6.2.3 Selection Nodes, and 6.2.4 Attribute Match Expressions so that concepts are introduced sequentially (4) Section 8.1 The following sentence implies that clients can attack other sessions by guessing session-ids: A server receiving a element MUST close the NETCONF session. I believe the intent was as follows: A server receiving a element that includes a element MUST ignore the session-id and close the NETCONF session. If that is the intent, I suggest the latter wording. (5) Section 9. Security Considerations, paragraph five states: Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces. The clause "and without integrity checking" is not relevant to eavesdropping attacks. Suggest: s/classic eavesdropping attacks/classic eavesdropping and false data injection attacks/ From bertietf@bwijnen.net Thu Mar 3 02:24:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4603A69B1 for ; Thu, 3 Mar 2011 02:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THSGOSzVU6HF for ; Thu, 3 Mar 2011 02:24:43 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id B93153A69A7 for ; Thu, 3 Mar 2011 02:24:42 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv5j8-0006C3-Ps for netconf@ietf.org; Thu, 03 Mar 2011 11:25:49 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv5j8-000570-Ak for netconf@ietf.org; Thu, 03 Mar 2011 11:25:46 +0100 Message-ID: <4D6F6CAA.30107@bwijnen.net> Date: Thu, 03 Mar 2011 11:25:46 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e74cec94b7c8018f5dae7a42f1a86a95 Subject: [Netconf] Fwd: Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 10:24:44 -0000 FYI and comment -------- Original Message -------- Subject: Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) Date: Wed, 02 Mar 2011 16:20:34 -0800 From: Peter Saint-Andre To: The IESG CC: netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Peter Saint-Andre has entered the following ballot position for draft-ietf-netconf-4741bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. DTDs are forbidden (presumably you mean internal or external DTD subsets in accordance with section 2.8 of the XML specification). What about comments, processing instructions, and internal or external entity references? 2. In Section 6.2.5, 'for which the element is equal to "fred"' is more precisely expressed as 'for which XML character data of the element is equal to "fred"'. (The same text occurs in Section 6.4.5.) 3. Section 6.4.3 states: In a real data model, the would not likely be returned with the list of users for a particular host or network. Why not? 4. In Section 7.5, is the server allowed to terminate a lock for reasons other than session closure? If not, it appears than an entity could maintain a lock indefinitely. 5. In Appendix B, it seems that some of the enumerated datatypes could be changed from xs:string to something more restrictive, such as xs:NMTOKEN (e.g., error types, error tags, error severity, edit operation type). From alexey.melnikov@isode.com Thu Mar 3 03:09:24 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F19D3A677E; Thu, 3 Mar 2011 03:09:24 -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 hyS2JBxso1jm; Thu, 3 Mar 2011 03:09:22 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 580453A659B; Thu, 3 Mar 2011 03:09:22 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 3 Mar 2011 11:10:28 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D6F76FE.5000801@isode.com> Date: Thu, 03 Mar 2011 11:09:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A6401B572F8@DEMUEXC006.nsn-intra.net> <4D6E5A66.8080302@ieca.com> <80A0822C5E9A4440A5117C2F4CD36A6401B574CA@DEMUEXC006.nsn-intra.net> <4D6EBA46.5030905@ieca.com> In-Reply-To: <4D6EBA46.5030905@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2011 03:17:49 -0800 Cc: Netconf , draft-ietf-netconf-4741bis@tools.ietf.org, Sean Turner , draft-ietf-netconf-rfc4742bis@tools.ietf.org, The IESG Subject: Re: [Netconf] Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf-rfc4742bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 Mar 2011 11:09:24 -0000 Sean Turner wrote: > Mehemt, > > Normally, IESG members hold their discusses until either a) a new > draft is posted that incorporates the agreed changes or b) an RFC > editor's note is included in the IESG evaluation tab (by your AD). If > either of these happen, then I'll clear. It's most a double check > that you incorporate what you said you would (not picking on you we do > this to just about everybody). +1. (Not speaking specifically of your case) And I've seen multiple occasions when some changes were agreed on and then not applied. > spt > > On 3/2/11 3:21 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > >> Dear Sean, >> >> I interpreted your answer that your DISCUSS have been addressed. >> Is this correct? >> >> If yes, can you please clear your DISCUSS. >> If no, what can I do more? >> >> Thank you. >> >> Cheers, >> Mehmet >> >> >>> -----Original Message----- >>> From: ext Sean Turner [mailto:turners@ieca.com] >>> Sent: Wednesday, March 02, 2011 3:56 PM >>> To: Ersue, Mehmet (NSN - DE/Munich) >>> Cc: The IESG; ext Romascanu, Dan (Dan); bertietf@bwijnen.net; draft- >>> ietf-netconf-rfc4742bis@tools.ietf.org; draft-ietf-netconf- >>> 4741bis@tools.ietf.org; Netconf >>> Subject: Re: Sean Turner's DISCUSS and COMMENT on draft-ietf-netconf- >>> rfc4742bis-07 >>> >>> Mehmet, >>> >>> Responses inline. >>> >>> spt >>> >>> On 3/2/11 9:38 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >>> >>>> Hi Sean, >>>> >>>> I detected your DISCUSS in the draft tracker (see below). However, >>>> >>>> we, the WG chairs, did not get any alarm email. We were wondering >>>> >>>> whether sending an alarm should be the default case for the IESG >>> >>> tool. >>> >>> I think the problem was on my end. After we enter positions we can >> >> hit >> >>> save or save and send. I guess I only hit save. >>> >>>> DISCUSS #1: >>>> >>>>> #1) You state a max for chunk-size in 4.2 but I think you need a >>>> >>> MUST >>> >>>> for what >>>> >>>>> to do if a client or server sends something out-of-range (<=0 or >>>> >>>> >2^32-1). >>>> >>>>> The idea is to get implementers not to leave buffer overrun >>>> >>>> vulnerabilities around. >>>> >>>>> (Same thing for what to do if chunk-size does contain leading >>>> >>> zeros, or is >>> >>>> >>>>> negative perhaps.) >>>> >>>> >>>> Concerning the errors during the decoding process, which for sure >>> >>> includes >>> >>>> >>>> the case "chunk-size out-of-range", the draft says: >>>> >>>> OLD: >>>> >>>> "If an error occurs during the decoding process, the peer MUST >>>> >>>> terminate the NETCONF session by closing the corresponding SSH >>>> >>>> channel." >>>> >>>> I think it is OK toaddexplicitlythat the session is closed if an >>>> invalid-chunk size or >>>> >>>> invalid chunk-size value is received. >>>> >>>> NEW: >>>> >>>> "If the chunk-sizeandthe chunk-size valuerespectively areinvalid or >>> >>> an error >>> >>>> >>>> occurs during the decoding process, the peer MUST terminate the >>> >>> NETCONF >>> >>>> >>>> session by closing the corresponding SSH channel." >>>> >>>>> That may not be quite the same as saying "MUST terminate" at the >>>> >>> very >>> >>>> end of >>> >>> >>> That would work for me. >>> >>>>> 4.2 if someone didn't consider the chunk-size part of the >>>> >>>> >>>>> decoding process. >>>> >>>> >>>>> Lastly, as a bit of a mad corner-case, if I send a chunk that's >>>> >>> 2^32-2 >>> >>>> long (which >>>> >>>>> is allowed) and then another chunk that's 10 bytes, but both are >>>> >>> the >>> >>>> same XML >>>> >>>>> element, i.e. the ">>> >>>> contains the closing >>>> >>>>> "" then is a server or client expected to be able to handle >>>> >>> the >>> >>>> overall >>>> >>>>> element that's 2^32+8 bytes long? >>>> >>>> >>>>> Maybe just add text that implementations SHOULD include an upper- >>>> >>> limit >>> >>>> that ensures >>>> >>>>> they're not vulnerable to buffer overruns or something. >>>> >>>> >>>> I think 4742bis document, as the NETCONF transport layer, shouldn't >>> >>> have >>> >>>> to handle >>>> >>>> with NETCONF message size (which is the size of the element). >>> >>> But >>> >>>> I agree >>>> >>>> that the document should state that the implementation needs to >>> >> check >> >>>> for it to >>>> >>>> "ensure they're not vulnerable to buffer overruns". >>>> >>>> (including the text for the first part above) >>>> >>>> OLD: >>>> >>>> If an error occurs during the decoding process, the peer MUST >>>> >>>> terminate the NETCONF session by closing the corresponding SSH >>>> >>>> channel. >>>> >>>> NEW: >>>> >>>> "If the chunk-size or the chunk-size value is invalid or an error >>>> >>>> occurs during the decoding process, the peer MUST terminate the >>>> >>>> NETCONF session by closing the corresponding SSH channel. >>>> >>>> Implementations MUST ensure they are not vulnerable for a buffer >>>> >>>> overrun." >>>> >>>> Would this be sufficient for you to clear your DISCUSS? >>> >>> >>> Yes. >>> >>>> DISCUSS #2: >>>> >>>>> #2) There's a mix of upper and lower case in the security >>>> >>>> considerations was >>>> >>>>> this purposely done? Specifically, it says "should" only be used >>>> >>> with >>> >>>> >>>>> confidentiality. Maybe "SHOULD" is better there? Also why isn't >>>> >>> this a >>> >>>> MUST? >>>> >>>> This is actually just an explanation about the requirement for >>> >>> NETCONF. >>> >>>> The hard >>>> >>>> requirement statement is in 4741bis. However, you are right 4742bis >>>> shouldn't >>>> >>>> downgrade the requirement in 4741bis and shoulduse"required" >>>> orsomethingequal. >>>> >>>> OLD: >>>> >>>> "So, NETCONF should only be used overcommunications channels that >>> >>> provide >>> >>>> >>>> strong encryption for data privacy." >>>> >>>> NEW: >>>> >>>> "So, NETCONFrequirescommunications channels that provide strong >>> >>> encryption >>> >>>> >>>> for data privacy." >>>> >>>> Would this be sufficient for youto clear your DISCUSS? >>> >>> >>> Yes >>> >>>> Comment #1: >>>> >>>>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the >>>> >> first >> >>>> paragraph be >>>> >>>>> a "MUST"? >>>> >>>> >>>> This is in the area of and a MUST statement in 4741bis. >>>> >>>> Comment #2) >>>> >>>>> Sec 4.2: Would any XML decoding error cause termination as stated >>>> >>> at >>> >>>> >>>>> the end of 4.2? E.g. some unknown xmlns value or something? >>>> >>>> >>>> Interpreting the XML document content is not done in the transport >>> >>> layer >>> >>>> (4742bis). >>>> >>>> 4741bis deals with this. There are a number of different error >>> >>> responses >>> >>>> if the XML >>>> >>>> message can't be understood or the XML message is not well-formed. >>>> >>>> takes care of it. >>>> >>>> 4741bis says: >>>> >>>> "All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If >>> >> a >> >>>> >>>> peer receives an message that is not well-formed XML or not >>>> >>>> encoded in UTF-8, it SHOULD reply with a "malformed-message" error. >>>> >>>> If a reply cannot be sent for any reason, the server MUST close the >>>> >>>> session." >>>> >>>> Regards, >>>> >>>> Mehmet >>>> >>>> (document shepherd) >>>> >>>> ------------------ >>>> >>>> *******Discuss (2011-03-01)*Picture (Device Independent Bitmap) >>>> >>>> #1) You state a max for chunk-size in 4.2 but I think you need a >>> >> MUST >> >>>> for what >>>> >>>> to do if a client or server sends something out-of-range (<=0 or >>>> >2^32-1). The >>>> >>>> idea is to get implementers not to leave buffer overrun >>> >>> vulnerabilities >>> >>>> around. >>>> >>>> (Same thing for what to do if chunk-size does contain leading zeros, >>> >>> or is >>> >>>> >>>> negative perhaps.) That may not be quite the same as saying "MUST >>>> terminate" at >>>> >>>> the very end of 4.2 if someone didn't consider the chunk-size part >>> >> of >> >>> the >>> >>>> >>>> decoding process. Lastly, as a bit of a mad corner-case, if I send a >>> >>> chunk >>> >>>> >>>> that's 2^32-2 long (which is allowed) and then another chunk that's >>> >>> 10 >>> >>>> bytes, >>>> >>>> but both are the same XML element, i.e. the ">>> chunk and >>>> >>>> the 2nd chunk contains the closing "" then is a server or >>> >>> client >>> >>>> expected >>>> >>>> to be able to handle the overall element that's 2^32+8 bytes >>> >>> long? >>> >>>> Maybe >>>> >>>> just add text that implementations SHOULD include an upper-limit >>> >> that >> >>>> ensures >>>> >>>> they're not vulnerable to buffer overruns or something. >>>> >>>> #2) There's a mix of upper and lower case in the security >>> >>> considerations was >>> >>>> >>>> this purposely done? Specifically, it says "should" only be used >>> >> with >> >>>> >>>> confidentiality. Maybe "SHOULD" is better there? Also why isn't this >>> >>> a MUST? >>> >>>> >>>> *******Comment (2011-03-01)*Picture (Device Independent Bitmap) >>>> >>>> #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first >>>> paragraph be >>>> >>>> a "MUST"? >>>> >>>> #2) Sec 4.2: Would any XML decoding error cause termination as >>> >> stated >> >>> at >>> >>>> >>>> the end of 4.2? E.g. some unknown xmlns value or something? >>>> >>>> Cheers, >>>> Mehmet >>>> >> -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From bertietf@bwijnen.net Thu Mar 3 03:32:27 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDDB3A69BD for ; Thu, 3 Mar 2011 03:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ZrV2RBC5+HGd for ; Thu, 3 Mar 2011 03:32:26 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id BDB593A69A8 for ; Thu, 3 Mar 2011 03:32:23 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv6mc-0003TU-Sn; Thu, 03 Mar 2011 12:33:28 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv6mb-0002Ck-N4; Thu, 03 Mar 2011 12:33:25 +0100 Message-ID: <4D6F7C85.2030905@bwijnen.net> Date: Thu, 03 Mar 2011 12:33:25 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Harrington , netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43815780f24fcb34227bf162c5cd44556 Subject: [Netconf] Fwd: Re: FW: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 11:32:27 -0000 Forwarding this to DBH and netconf list, so everyone knows. Bert WIjnen Document Shpeherd -------- Original Message -------- Subject: Re: FW: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (withDISCUSS and COMMENT) Date: Thu, 3 Mar 2011 00:29:55 +0100 From: Juergen Schoenwaelder Reply-To: Juergen Schoenwaelder To: Ersue, Mehmet (NSN - DE/Munich) CC: draft-ietf-netconf-4741bis@tools.ietf.org, bertietf@bwijnen.net, "ext Romascanu, Dan (Dan)" , margaretw42@gmail.com > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8? NETCONF content by default is UTF8. > 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol? NETCONF uses what the secure transport natively delivers. Since there are not size or character set constraints in NETCONF, this just works fine and follows the model that works on a large number of deployed CLIs. > 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service? 600 secs is the default if a timeout is not specified: A confirmed commit operation MUST be reverted if a confirming commit is not issued within 600 seconds (10 minutes). The confirming commit is a commit operation without the parameter. The timeout period can be adjusted with the parameter. If this text is not clear enough, we can change this to: A confirmed commit operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a commit operation without the parameter. The timeout period can be adjusted with the parameter. Setting the timeout to 0 secs likely causes an almost immediate rollback. Is this a denial of service risk? Well, if an attacker manages to commit configs, then he likely can do more interesting harm that this attempt to eat some rollback CPU cycles. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Mar 3 05:24:44 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477EB3A67DB; Thu, 3 Mar 2011 05:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 Vm-QGpxGVN7d; Thu, 3 Mar 2011 05:24:43 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 5B0ED3A6964; Thu, 3 Mar 2011 05:24:41 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pv8XG-0005G9-M6; Thu, 03 Mar 2011 14:25:44 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pv8XG-0002lp-9U; Thu, 03 Mar 2011 14:25:42 +0100 Message-ID: <4D6F96D6.30804@bwijnen.net> Date: Thu, 03 Mar 2011 14:25:42 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Harrington References: <20110301230555.15990.2719.idtracker@localhost> In-Reply-To: <20110301230555.15990.2719.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41e7fb968967d5d8abd7917cf4e8c934c Cc: netconf , The IESG , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:24:44 -0000 Responses/comments to your DISCUSS points by Juergen. Pls respond/comment with cc: to WG mailing list, so we all get a clear understanding of your (remaining) concerns and so we can try to get to convergence. Bert Wijnen Document SHepherd > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files > or databases, should it be human-readable? ascii? utf-8? NETCONF content by default is UTF8. > 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the > corresponding identifier in the secure transport protocol? NETCONF uses what the secure transport natively delivers. Since there are not size or character set constraints in NETCONF, this just works fine and follows the model that works on a large number of deployed CLIs. > 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at > 600? Can a low timeout cause a denial of service? 600 secs is the default if a timeout is not specified: A confirmed commit operation MUST be reverted if a confirming commit is not issued within 600 seconds (10 minutes). The confirming commit is a commit operation without the parameter. The timeout period can be adjusted with the parameter. If this text is not clear enough, we can change this to: A confirmed commit operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a commit operation without the parameter. The timeout period can be adjusted with the parameter. Setting the timeout to 0 secs likely causes an almost immediate rollback. Is this a denial of service risk? Well, if an attacker manages to commit configs, then he likely can do more interesting harm that this attempt to eat some rollback CPU cycles. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 On 3/2/11 12:05 AM, David Harrington wrote: > David Harrington has entered the following ballot position for > draft-ietf-netconf-4741bis-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8? > > 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol? > > 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) copyright in yang module needs updating. > > 2) appendix F doesn't mention dropping the local file requirement for URLs, > > 3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0. > > 4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability. > > 5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control. > > > > From mehmet.ersue@nsn.com Thu Mar 3 05:40:13 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E594D3A67DB for ; Thu, 3 Mar 2011 05:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILKLKAGjFBiE for ; Thu, 3 Mar 2011 05:40:13 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id E39E93A67BD for ; Thu, 3 Mar 2011 05:40:12 -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 p23DfDv6006543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 14:41:13 +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 p23DfDMr017728; Thu, 3 Mar 2011 14:41:13 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 14:41:09 +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: Thu, 3 Mar 2011 14:41:07 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B92808@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text Changes for 4742bis v07 before the IESG Chat Thread-Index: AcvZqKYjlEL81tpuSzaJEdgo9fIx1w== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 03 Mar 2011 13:41:09.0865 (UTC) FILETIME=[A7884590:01CBD9A8] Subject: [Netconf] Proposed Text Changes for 4742bis v07 before the IESG Chat X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 Mar 2011 13:40:14 -0000 Hi All, please find at the link below the proposed text changes for 4742bis v07 as=20 discussed with the IESG members. Most of the IESG members already agreed to clear their DISCUSS. Others will hopefully do it during the IESG chat. https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/writeup/=20 Cheers,=20 Mehmet=20 From mehmet.ersue@nsn.com Thu Mar 3 08:07:01 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF7E3A69A1 for ; Thu, 3 Mar 2011 08:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vWBe7t8fIaK for ; Thu, 3 Mar 2011 08:06:59 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BC43D3A6821 for ; Thu, 3 Mar 2011 08:06:56 -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 p23G83EU024687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Mar 2011 17:08:03 +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 p23G7wNh005685 for ; Thu, 3 Mar 2011 17:08:03 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 17:08:02 +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: Thu, 3 Mar 2011 17:08:01 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401B929D8@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Thread-Index: AcvXljnURMOJEwOuTVuDCR2OaI5dTAAjNFZwAA02O7AAA23HQABLGLPAAAhiquAAAdH/4AAAfp3g From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 03 Mar 2011 16:08:02.0779 (UTC) FILETIME=[2C703AB0:01CBD9BD] Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:07:01 -0000 Hi All, I assume this is the only remaining DISCUSS. Any comments? Pls also check the mail below from=20 David Harrington. Mehmet=20 -----Original Message----- From: Ersue, Mehmet (NSN - DE/Munich)=20 Sent: Thursday, March 03, 2011 5:04 PM To: 'ext David Harrington' Cc: draft-ietf-netconf-rfc4742bis@tools.ietf.org; 'ext Romascanu, Dan (Dan)'; bertietf@bwijnen.net; 'The IESG' Subject: RE: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Hi David, I think we need to differentiate between NETCONF message layer=20 and transport layer. I also think the SSH transport document should not define how=20 a username should look like nor define any transformation=20 algorithm from format A to format X. SSH transport is kept simple for what it transports and does=20 also not interpret any XML content. SSH transport depends at the end on what it gets from underlying=20 SSH implementation. I believe to define any constraints on the username is more=20 appropriate to do in the NETCONF base document rather than=20 in 4742bis. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, March 03, 2011 4:33 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: draft-ietf-netconf-rfc4742bis@tools.ietf.org; 'ext Romascanu, Dan > (Dan)'; bertietf@bwijnen.net; 'The IESG' > Subject: RE: David Harrington's Discuss on draft-ietf-netconf- > rfc4742bis-07: (withDISCUSS and COMMENT) >=20 > Hi Mehmet, >=20 > this looks good as far as it goes. >=20 > However, this does not adress these issues: >=20 > 1) the username is used externally to netconf, e.g. in a config file > for some access control method. username is not just used *inside* > netconf. While the default for netconf is utf-8, and the "user name" > field in SSH is utf-8, it is implementation-dependent what the SSH > implementation provides to applications. It could be good to specify > that netconf username MUST be utf-8, for interoperability reasons. If > what the SSH implementation (for example) provides is not utf-8, then > the netconf SSH-transport implementation SHOULD convert it to utf-8. > If the SSH implementation provides an identity already in utf-8, this > is a no-op. >=20 > 2) But the problem is bigger than just utf-8. the username is used > externally to netconf, e.g. in a config file for some access control > method. username is not just used *inside* netconf. At some point, you > need to do comparisons between what the transport provides for an > identity, and an access control database representation of identities. > For example, from draft-ietf-netconf-access-control: > 3. Check all the entries for ones that contain a name> entry that matches the user name for the session making > the request. Add to these groups the set of groups provided > by > the transport layer. >=20 > How will you define a matching algorithm that is interoperable across > implementations? Does the match algorithm include internationalized > names? control characters? How long is the username allowed to be? How > large a buffer MUST be supported to handle whatever username is > provided by a transport? What if an SSH implementation decides to > simply pass the application a complete X509 certificate representing > the identity - should netconf implementations be expected to handle > that? Maybe you want to use the username in scripts; Must the > characters in username be printable? >=20 > Since you are not specifying an access control mechanism at this > point, you are relying on existing system access controls to work. > Assuming a CLI-based approach, possibly with scripting and/or a config > file, you proibably want username to be in a format that is likely to > be acceptable to the existing mechanism (or future standardized > mechanisms). I recommend some constraints (and I would be satisfied > with RECOMMENDS/SHOULD). >=20 > By not specifying any constraints on username, you are forcing all > other parts of the system that use username (including all future > netconf access control standards) to deal with a completely wide-open > set of requirements to accommodate whatever the SSH implementation > gives you. >=20 > 3) You still haven't dealt with the uniqueness question. What if the > SSH transport returns username=3D"dbh" for David B Harrington, and the > TLS transport returns username=3D"dbh" for Dwight B Harrison? How will > you accommodate both in an access control rule set? >=20 > dbh >=20 > > -----Original Message----- > > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > > Sent: Thursday, March 03, 2011 7:11 AM > > To: ext David Harrington > > Cc: draft-ietf-netconf-rfc4742bis@tools.ietf.org; ext > > Romascanu, Dan (Dan); bertietf@bwijnen.net > > Subject: RE: David Harrington's Discuss on > > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) > > > > Hi David, > > > > we copied now following change to the RFC Editors note: > > > > See > > https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis > > /writeup/. > > > > Thanks & Regards, > > Mehmet > > (document shepherd) > > > > > > 2. Section 3. > > > > OLD: > > How the NETCONF Server extracts the SSH user name from the > > SSH layer > > is implementation-dependent. > > > > NEW: > > There is no standard way for an application running on an SSH > > server to determine a user name for the current session. How > the > > NETCONF Server extracts the user name from the SSH layer is > > therefore implementation-dependent. Any transformations applied > to > > the authenticated user name by the SSH layer are outside the > scope > > of this document. > > > > > > Cheers, > > Mehmet > > > > > > > -----Original Message----- > > > From: ext David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Wednesday, March 02, 2011 12:20 AM > > > To: Ersue, Mehmet (NSN - DE/Munich) > > > Cc: 'The IESG'; draft-ietf-netconf-rfc4742bis@tools.ietf.org; 'ext > > > Romascanu, Dan (Dan)'; bertietf@bwijnen.net > > > Subject: RE: David Harrington's Discuss on draft-ietf-netconf- > > > rfc4742bis-07: (withDISCUSS and COMMENT) > > > > > > Hi, > > > > > > I just posted a DISCUSS againat 4741bis for a related issue. > > > > > > I think username needs to meet some constraints to make it > > usable for > > > the foreseeable uses, such as specifying an access policy for a > > > specific username. Compare tmSecurityName from RFC3411 and > RFC5590, > > > which constrain the size, the character set, and the expected > human > > > readability. The algorithm must also produce a predictable value > for > > > use by human operators, given knowledge of the authentication > > > parameters. > > > > > > I think there is also an issue of the uniqueness of username. If > you > > > have multiple transports supported in a NC implementation, must > the > > > usernames from, say, the SSH transport be unique only amongst the > > > usernames generated by the SSH transport, or does the > > username need to > > > also be unique across the TLS, SOAP, and BEEP transports as well? > If > > > it will be used by an access control mechanism, it will be > important > > > to know what parameters must be specified to uniquelyt identify a > > > "user", such as in VACM, where we need to know the securityname > AND > > > the security model that generates the securityName. > > > > > > As with RFC5592, I agree that how you convert the authenticated > > > identity from SSH depends on the SSH implementation, since the > > > identity used in SSH (and other protocols) can vary dramatically > > > depending on the underlying authentication mechanism. > > > > > > The discuss for 4742bis is the total lack of the > > explanation REQUIRED > > > by 4741bis. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Ersue, Mehmet (NSN - DE/Munich) > > [mailto:mehmet.ersue@nsn.com] > > > > Sent: Tuesday, March 01, 2011 4:39 PM > > > > To: ext David Harrington > > > > Cc: The IESG; draft-ietf-netconf-rfc4742bis@tools.ietf.org; > > > > ext Romascanu, Dan (Dan); bertietf@bwijnen.net > > > > Subject: FW: David Harrington's Discuss on > > > > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) > > > > > > > > Hi Dave, > > > > > > > > we discussed the issue with the username in the NETCONF WG > > > > intensively > > > > (see the 4742bis discussion in > > > > http://www.ietf.org/proceedings/78/minutes/netconf.txt). > > > > > > > > Naming policies might differ between administrative domains and > > > > identities represented as usernames mean different things in > > > > different operating systems. Following the statement in RFC 5592 > > > > we decided that the method to obtain the username for the > NETCONF > > > > Server from SSH should be implementation-dependant. > > > > > > > > However, I agree that such an explanation is missing in the > draft. > > > > > > > > We discussed it again in the NETCONF ML and would like to > suggest > > > > following text change. > > > > > > > > OLD: > > > > How the NETCONF Server extracts the SSH user name from the > > > > SSH layer > > > > is implementation-dependent. > > > > > > > > NEW: > > > > There is no standard way for an application running on an > SSH > > > > server to determine a user name for the current session. > How > > > the > > > > NETCONF Server extracts the user name from the SSH layer is > > > > therefore implementation-dependent. Any > > transformations applied > > > to > > > > the authenticated user name by the SSH layer are outside the > > > scope > > > > of this document. > > > > > > > > > > > > Would this text be sufficient for you? > > > > > > > > Thank you for your support. > > > > > > > > Regards, > > > > Mehmet > > > > (document shepherd) > > > > > > > > -----Original Message----- > > > > From: ext David Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Monday, February 28, 2011 11:23 PM > > > > To: The IESG > > > > Cc: netconf-chairs@tools.ietf.org; > > > > draft-ietf-netconf-rfc4742bis@tools.ietf.org > > > > Subject: David Harrington's Discuss on > > > > draft-ietf-netconf-rfc4742bis-07: > > > > (withDISCUSS and COMMENT) > > > > > > > > David Harrington has entered the following ballot position for > > > > draft-ietf-netconf-rfc4742bis-07: Discuss > > > > > > > > When responding, please keep the subject line intact and reply > to > > > all > > > > email addresses included in the To and CC lines. (Feel free > > > > to cut this > > > > introductory paragraph, however.) > > > > > > > > Please refer to > > > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > 1) 4741bis says: "The authentication process MUST result in an > > > > authenticated client > > > > identity whose permissions are known to the server. The > > > > authenticated identity of a client is commonly > > referred to as the > > > > NETCONF username. The algorithm used to derive the username > is > > > > transport protocol specific and in addition specific to the > > > > authentication mechanism used by the transport > > protocol. NETCONF > > > > transport protocols therefore MUST explain how a NETCONF > > > > username is > > > > derived from the authentication mechanisms supported by > > > > the transport > > > > protocol. > > > > > > > > The access permissions of a given client, identified by its > > > NETCONF > > > > username, are part of the configuration of the NETCONF > > > > server. These > > > > permissions MUST be enforced during the remainder of > > the NETCONF > > > > session. The details how access control is configured is > > > > outside the > > > > scope of this document." > > > > > > > > 4742bis says: "How the NETCONF Server extracts the SSH user name > > > from > > > > the SSH layer > > > > is implementation-dependent." > > > > > > > > This is not an explanation. Assuming an operator must > > specify access > > > > control rights for a user in the configuration o fthe > > server, it is > > > > important that the operator understands what the netconf > > username(s) > > > > will be. That is presumably why it is important for the Netconf > > > > transport protocol specification to explain the algorithm for > > > deriving > > > > the username. > > > > > > > > RFC5592 defines an SSH subsystem for use with SNMP, and has > > > > had to deal > > > > with similar issues, including constraints about not changing > the > > > > username associated with a session, allowing "user@host" style > > > naming, > > > > etc. > > > > Maybe those are not needed for netconf, but the above > > > > "implementation-dependent" explanations seems woefully > inadequate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > 1) The IANA section does not specify that the assigned > > port is a TCP > > > > port. should it? > > > > > > > > > > > > > > > > From j.schoenwaelder@jacobs-university.de Thu Mar 3 09:06:23 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F54C3A67F1 for ; Thu, 3 Mar 2011 09:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 wOUSQgMoet7j for ; Thu, 3 Mar 2011 09:06:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BCB993A6830 for ; Thu, 3 Mar 2011 09:06:21 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9772C002F; Thu, 3 Mar 2011 18:07:28 +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 1eK5foxchv4W; Thu, 3 Mar 2011 18:07:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 149C2C002D; Thu, 3 Mar 2011 18:07:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B541C16DA9A3; Thu, 3 Mar 2011 18:07:23 +0100 (CET) Date: Thu, 3 Mar 2011 18:07:23 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20110303170723.GB21275@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A6401B929D8@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401B929D8@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) 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, 03 Mar 2011 17:06:23 -0000 On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Any comments? Pls also check the mail below from > David Harrington. [... stuff removed I figured out is not helpful to send ...] NETCONF is the wrong place to constraint user name. For SSH, this is a no-brainer anyway. /js PS: We dealt with the uniquess questions explaining that this is an ACM issue and note that it is even mentioned in the Security Considerations section: [...] Second, it could be desirable to authorize based on mechanisms available in the secure transport layer (SSH, BEEP, etc). PS: RFC 4252 says: byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] RFC 4251 says: string Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Mar 3 09:15:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029DF3A6830 for ; Thu, 3 Mar 2011 09:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLbawmch5ySP for ; Thu, 3 Mar 2011 09:15:32 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 037D63A69FC for ; Thu, 3 Mar 2011 09:15:32 -0800 (PST) Received: from localhost (75-149-169-190-Washington.hfc.comcastbusiness.net [75.149.169.190]) by mail.hardakers.net (Postfix) with ESMTPSA id 9DDE82475C; Thu, 3 Mar 2011 09:16:16 -0800 (PST) From: Wes Hardaker To: Phil Shafer References: <201103011945.p21Jjcfr032304@idle.juniper.net> Date: Thu, 03 Mar 2011 09:16:15 -0800 In-Reply-To: <201103011945.p21Jjcfr032304@idle.juniper.net> (Phil Shafer's message of "Tue, 1 Mar 2011 14:45:38 -0500") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:15:33 -0000 >>>>> On Tue, 1 Mar 2011 14:45:38 -0500, Phil Shafer said: PS> The idea of "user@host" is completely local to the client. The SSH PS> server has no clue that this is going on. I'm a bit shocked that PS> this is an issue for SNMP, but admittedly haven't read 5592. Don't worry Phil, you don't need to read it. It's a client side specifier only in 5592 for how to specify a connection to a remote server. -- Wes Hardaker Cobham Analytic Solutions From bertietf@bwijnen.net Thu Mar 3 10:44:50 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D8B3A695F for ; Thu, 3 Mar 2011 10:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2CHulyE7k57 for ; Thu, 3 Mar 2011 10:44:50 -0800 (PST) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id C65A93A67D3 for ; Thu, 3 Mar 2011 10:44:49 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PvDX9-0002DY-Uy for netconf@ietf.org; Thu, 03 Mar 2011 19:45:56 +0100 Message-ID: <4EF53DDCF4344B6499BE0C8343B7D87D@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf" Date: Thu, 3 Mar 2011 19:35:19 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: [Netconf] Fw: Jari Arkko's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSSand COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:44:51 -0000 FYI and comments ----- Original Message ----- From: "Jari Arkko" To: "The IESG" Cc: ; ; Sent: Thursday, March 03, 2011 6:05 PM Subject: Jari Arkko's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSSand COMMENT) Jari Arkko has entered the following ballot position for draft-ietf-netconf-4741bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The document does not seem to specify who is allowed kill sessions. Shouldn't that be specified? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some comments from Ari Keränen: 4.3. Element Shouldn't the "t" namespace be defined in the error-path examples? 7.9. There is no discussion on who is allowed to kill whose sessions. I'd assume user is allowed to kills his own sessions (i.e., sessions associated with the same NETCONF username), but how about other sessions? If this is out of scope for this document, could at least say that it "depends on local policy". 8.3.5.1. , , , and Is really *any* operation (including ones defined in future documents) allowed here, or just one of the operations mentioned in the title? The text seems to imply the latter, but the example the former. 8.4.1. Description The confirmed-commit functionality is unclear. One paragraph (before the current 2nd paragraph) really explaining how this works would be helpful. That is, when/why would one send confirmed commit and what kind of messages/parameters you need at each stage. 8.6.4.1. A validate operation can fail for any of the following reasons: Would it be OK to fail validation for some other reason? 8.8.5.3. The :url capability modifies the operation to accept the element as the value of the parameters. What should the server do if it gets URL in the delete-config? Delete the (local copy of the) config retrieved from the address pointed by the URL? Delete the file pointed by the URL? Appendix C. YANG Module for NETCONF Protocol Operations reference "RFC XXXX, section YYY"; Should add the correct section number (multiple times in the Appendix C). From bwijnen@bwijnen.net Thu Mar 3 10:57:01 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D7F3A6A08 for ; Thu, 3 Mar 2011 10:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 zlzLUM9kozJK for ; Thu, 3 Mar 2011 10:57:00 -0800 (PST) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id 94FDC3A695F for ; Thu, 3 Mar 2011 10:57:00 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PvDX5-0002Cb-A0 for netconf@ietf.org; Thu, 03 Mar 2011 19:45:51 +0100 Message-ID: From: "Bert Wijnen" To: "Netconf" Date: Thu, 3 Mar 2011 19:45:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: [Netconf] Fw: 4741bis and 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: Thu, 03 Mar 2011 18:57:01 -0000 FYI ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: Sent: Thursday, March 03, 2011 6:27 PM Subject: 4741bis and 4742bis The IESG discussed the two bis documents in the telechat today. Some of the issues were clarified, a few other remain to be resolved. The resolution for the two documents is Revised-ID Needed - I think that the number of edits exceeds what can be reasonably dealt with in RFC Editor notes. Note for 4741bis the new DISCUSS by Jari and the fact that Alexey's DISCUSS is a placeholder - more information will come in the following days. Please continue to work to solve the open issues, and take into account that the deadline for submitting I-Ds before Prague is Monday 3/14. Also please copy Alexey both on responses related to 4741bis and 4742bis. Alexey agreed to clear his DISCUSS on 4742bis on condition to be copied on mails related to the solution of David's DISCUSS. Thanks and Regards, Dan From kwatsen@juniper.net Thu Mar 3 12:07:15 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6343A687B for ; Thu, 3 Mar 2011 12:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+2nfA7Y0yZe for ; Thu, 3 Mar 2011 12:07:14 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 45F0F3A67EF for ; Thu, 3 Mar 2011 12:07:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTW/1Lz+lDRqhn986hYNwkjVt3Wpb9giD@postini.com; Thu, 03 Mar 2011 12:08:22 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 3 Mar 2011 12:04:21 -0800 From: Kent Watsen To: "Bert (IETF) Wijnen" , netconf Date: Thu, 3 Mar 2011 12:05:05 -0800 Thread-Topic: [Netconf] Fwd: Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) Thread-Index: AcvZjUVEOCa+EhxPR7OH4x8W1FWM1AAUHpIg Message-ID: <84600D05C20FF943918238042D7670FD38607A6A42@EMBX01-HQ.jnpr.net> References: <4D6F6CAA.30107@bwijnen.net> In-Reply-To: <4D6F6CAA.30107@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Fwd: Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:07:15 -0000 > 5. In Appendix B, it seems that some of the enumerated datatypes could be > changed from xs:string to something more restrictive, such as xs:NMTOKEN > (e.g., error types, error tags, error severity, edit operation type). I started doing this to all my XSDs. I even take it a step further=20 By defining a type that cannot be empty, as XSD otherwise allows empty content. For instance: Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Fri Mar 4 00:40:39 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82A93A6908; Fri, 4 Mar 2011 00:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 Q67uyPx-ErS3; Fri, 4 Mar 2011 00:40:38 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id E85D83A6842; Fri, 4 Mar 2011 00:40:35 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PvQZw-0006cS-7X; Fri, 04 Mar 2011 09:41:42 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PvQZw-0004aJ-2F; Fri, 04 Mar 2011 09:41:40 +0100 Message-ID: <4D70A5C4.2040005@bwijnen.net> Date: Fri, 04 Mar 2011 09:41:40 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Harrington References: <20110301230555.15990.2719.idtracker@localhost> In-Reply-To: <20110301230555.15990.2719.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48e05e0adb345daecfe792149c30256ce Cc: netconf , The IESG , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 08:40:39 -0000 More answers/comments from Juergen below. Can I ask mister Harrington to participate in the discussion on the NETCONF WG mailing list? That is the only way to get to convergence in a reasonable amount of time. Dave, you ARE a particpant in the WG, and I hope you can pay attention there till we reach agreement on this DISCUSS. I hate to have to keep forarding yoru emails to the WG and then forward any WG technical responses back to you. That is not productive, and things may get lost in that path. Thanks, Bert Wijnen Document shepherd -------- Original Message -------- Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) Date: Thu, 3 Mar 2011 18:07:23 +0100 From: Juergen Schoenwaelder Reply-To: Juergen Schoenwaelder To: Ersue, Mehmet (NSN - DE/Munich) CC: Netconf On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Any comments? Pls also check the mail below from > David Harrington. [... stuff removed I figured out is not helpful to send ...] NETCONF is the wrong place to constraint user name. For SSH, this is a no-brainer anyway. /js PS: We dealt with the uniquess questions explaining that this is an ACM issue and note that it is even mentioned in the Security Considerations section: [...] Second, it could be desirable to authorize based on mechanisms available in the secure transport layer (SSH, BEEP, etc). PS: RFC 4252 says: byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] RFC 4251 says: string Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 ______________________ On 3/2/11 12:05 AM, David Harrington wrote: > David Harrington has entered the following ballot position for > draft-ietf-netconf-4741bis-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8? > > 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol? > > 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) copyright in yang module needs updating. > > 2) appendix F doesn't mention dropping the local file requirement for URLs, > > 3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0. > > 4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability. > > 5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control. > > > > From bertietf@bwijnen.net Fri Mar 4 00:52:14 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069D83A6942 for ; Fri, 4 Mar 2011 00:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 2fx8owERI3vN for ; Fri, 4 Mar 2011 00:52:13 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id C543C3A6892 for ; Fri, 4 Mar 2011 00:52:12 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PvQlB-0006vm-7i; Fri, 04 Mar 2011 09:53:18 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PvQlA-0005Yf-V2; Fri, 04 Mar 2011 09:53:17 +0100 Message-ID: <4D70A87C.8040908@bwijnen.net> Date: Fri, 04 Mar 2011 09:53:16 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a40d0ee8866f918d27ee299e0dea4106 Cc: netconf Subject: [Netconf] next steps for draft-ietf-4741bis-09.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, 04 Mar 2011 08:52:14 -0000 Editors/authors of 4741bis, All DISCUSSes and COMMENTs from the IESG are now collected. See page http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ballot/ There are also a few RFC-Editor notes at the bottom of this page: http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/writeup/ May I ask the editors/authors to come up with proposed text that will fix and/or address the issues and comments. You could send such text snippets to the WG mailing list, OR you an do it in a new rev of the document (that will need to be done anyways when we agree). Note that the deadline for posting new drafts is 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT Let me know ifthre is any way I can (or need to) help. Thanks, Bert Wijnen Document shepherd From mehmet.ersue@nsn.com Tue Mar 8 09:28:15 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BD53A6928 for ; Tue, 8 Mar 2011 09:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U4qsUoS7umt for ; Tue, 8 Mar 2011 09:28:15 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AA8AD3A68F5 for ; Tue, 8 Mar 2011 09:28:14 -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 p28HTPcP020690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 18:29:25 +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 p28HTP1h014634; Tue, 8 Mar 2011 18:29:25 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 18:29:25 +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, 8 Mar 2011 18:29:22 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft NETCONF Session Agenda for IETF 80 Thread-Index: Acvdtl1NzRtI7aINQWiO4h3NGhMuEA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 08 Mar 2011 17:29:25.0351 (UTC) FILETIME=[5EBE5770:01CBDDB6] Subject: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 08 Mar 2011 17:28:15 -0000 Dear NETCONF WG, below is a draft agenda for the NETCONF session in Prague. Please send us your comments/requests by March 16, 2011. Mehmet & Bert (DRAFT) Agenda for NETCONF WG Session ------------------------------------- IETF 80 - Prague, Czech Republic March 27 - April 1, 2011 THURSDAY, March 31, 2011 1300-1500 Afternoon Session I Room Barcelona WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Status of 4741bis and 4742bis (5 minutes - M. Bjorklund/M. Wassermann) 2. Network Configuration Protocol Access Control Model - A. Bierman (40 minutes)=20 http://tools.ietf.org/html/draft-ietf-netconf-access-control=20 3. NETCONF System Notifications - A. Bierman (30 minutes)=20 draft-ietf-netconf-system-notification=20 =20 http://tools.ietf.org/html/draft-ietf-netconf-system-notification=20 Open mike: Possible topics: - (if necessary) Discussion on NETCONF username - Improved NACM rule specification, features/requirements M. Bjorklund/A. Bierman Any other topics to discuss?=20 AOB From biermana@Brocade.com Tue Mar 8 10:07:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC7A3A693D for ; Tue, 8 Mar 2011 10:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.296, 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 8lANiV62og0E for ; Tue, 8 Mar 2011 10:07:10 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 34A333A68AF for ; Tue, 8 Mar 2011 10:07:10 -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 p28I7hGO018831; Tue, 8 Mar 2011 10:08:25 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id uwq49g43s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Mar 2011 10:08:25 -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, 8 Mar 2011 10:16:21 -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, 8 Mar 2011 10:08:24 -0800 From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf Date: Tue, 8 Mar 2011 10:08:24 -0800 Thread-Topic: Draft NETCONF Session Agenda for IETF 80 Thread-Index: Acvdtl1NzRtI7aINQWiO4h3NGhMuEAABT6qg Message-ID: References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_07:2011-03-08, 2011-03-08, 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-1012030000 definitions=main-1103080101 Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 08 Mar 2011 18:07:11 -0000 I will be posting an update (-03) to the netconf system notifications draft, based on comments from Martin. http://www.ietf.org/id/draft-ietf-netconf-system-notifications-02.txt Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Ersue, Mehmet (NSN - DE/Munich) Sent: Tuesday, March 08, 2011 9:29 AM To: Netconf Subject: [Netconf] Draft NETCONF Session Agenda for IETF 80 Dear NETCONF WG, below is a draft agenda for the NETCONF session in Prague. Please send us your comments/requests by March 16, 2011. Mehmet & Bert (DRAFT) Agenda for NETCONF WG Session ------------------------------------- IETF 80 - Prague, Czech Republic March 27 - April 1, 2011 THURSDAY, March 31, 2011 1300-1500 Afternoon Session I Room Barcelona WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Status of 4741bis and 4742bis (5 minutes - M. Bjorklund/M. Wassermann) 2. Network Configuration Protocol Access Control Model - A. Bierman (40 minutes)=20 http://tools.ietf.org/html/draft-ietf-netconf-access-control=20 3. NETCONF System Notifications - A. Bierman (30 minutes)=20 draft-ietf-netconf-system-notification=20 =20 http://tools.ietf.org/html/draft-ietf-netconf-system-notification=20 Open mike: Possible topics: - (if necessary) Discussion on NETCONF username - Improved NACM rule specification, features/requirements M. Bjorklund/A. Bierman Any other topics to discuss?=20 AOB _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From Internet-Drafts@ietf.org Tue Mar 8 15:15:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6A93A659B; Tue, 8 Mar 2011 15:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 8yjdW+LBMoGR; Tue, 8 Mar 2011 15:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724ED3A67B3; Tue, 8 Mar 2011 15:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110308231501.17204.46756.idtracker@localhost> Date: Tue, 08 Mar 2011 15:15:01 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common NETCONF system events such as a change in NETCONF capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the NETCONF system 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-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-system-notifications-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-08150858.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Tue Mar 8 23:48:32 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3873A6864; Tue, 8 Mar 2011 23:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wfL8CvHjjtgp; Tue, 8 Mar 2011 23:48:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 328E53A6870; Tue, 8 Mar 2011 23:48:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77B41C0073; Wed, 9 Mar 2011 08:49:46 +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 Ux9lfgLH5glD; Wed, 9 Mar 2011 08:49:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 525ADC0013; Wed, 9 Mar 2011 08:49:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1AD7016E7953; Wed, 9 Mar 2011 08:49:38 +0100 (CET) Date: Wed, 9 Mar 2011 08:49:38 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20110309074938.GA40759@elstar.local> Mail-Followup-To: David Harrington , "'Bert (IETF) Wijnen'" , 'The IESG' , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, 'netconf' References: <20110301230555.15990.2719.idtracker@localhost> <4D70A5C4.2040005@bwijnen.net> <9ED039155BC64BC7BD62C00C298A9A6B@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ED039155BC64BC7BD62C00C298A9A6B@davidPC> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'netconf' , draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, 'The IESG' Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 09 Mar 2011 07:48:32 -0000 On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote: > --- The DISCUSS for 4741bis --- > > I have concerns about whether the ***netconf username*** being > provided by the netconf transport layer to its upper layers is clearly > defined enough. It is unclear what the format is, what the character > set is, and whether the authentication service (e.g., SSH) is included > in what the netconf transport layer provides. > > and the concern is whether what is provided by the netconf transport > layer will meet the assumptions of operators. > What if, I as an implementer chose to provide a netconf username of > the following form? > "dbh > ssh > ssh-password algorithm > <<]]>> > > > > SSH user name = dharrington@huaweisymantec.com > " > > would this be legal? according to 4741bis and 4742bis, it would appear > to be legal, because anything is acceptable ... > would it be useable by operators to, for example, specify an access > control policy? > or map it to existing native access controls? > would it be useable by operators to configure an access control policy > using netconf? or a CLI? The vast majority of deployed CLIs tells me that apparently this works in real life. > I fear it would not be. > But I think this would be perfectly legal according to the netconf > standard. > that's my concern. There are usually operating system specific constraints on what you can use as a user name. I fear that we are discussing a purely academic problem here. > So maybe 4741bis simply needs to say that since 4741bis defines no > constraints, anything is acceptable in a netconf username, so 4741bis > implementations MUST gracefully accept whatever is provided by the > transport layer as a netconf username. Since there is going to be access control for NETCONF, I guess we implicitely do expect that the username is a UTF8 string. In fact, draft-ietf-netconf-access-control-02.txt defines this: typedef nacm-user-name-type { type string { length "1..max"; } description "General Purpose User Name string."; } Would your concern be addressed if we state this in text in 4741bis? > --- The DISCUSS for 4741bis --- > > I have a concern that the netconf transport layer might not return the > nature of the authentication mechanism. This might be important to > other parts of the system, such as an access control system. > If the transport layer does not provide this, is it acceptable for an > access control system to violate "netconf layering" to go get that > information? will that information be available when an AC system is > determining permissions? > If so, it is unclear whether the Message layer is actually > transport-independent, as claimed in section 1.2. > and whether upper layers are transport-independent. > The layering diagrams don't really show where an access control system > would fit in the architecture. > My concern is whether upper layers have the information necessary to > identify the authenticated entity. > o user: The authenticated identity of the client. The > authenticated > identity of a client is commonly referred to as the NETCONF > username. > > section 2.2 says: > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. > This text does not identify what types of permissions must be known to > the server. > Is this the native access control system that defines the permissions? > what types of permissions are you referring to? permission to > establish an SSH subsystem? open a netconf session? perform > edit-config operations? modify certain portions of the datastore? > If "dbh" can be returned from two different transports, but represent > two different client identities, how can the server know the > associated permissions? > "whose permissions are known to the server" is really ambiguous. > I think the text is unclear about compliance requirements of the MUST. > > Those are my concerns, and I don't see them addressed in the ML > discussions. NETCONF access control is work in progress. As mentioned before, 4741bis says in the security considerations: [...] It is further expected that the identity of each end of a NETCONF session will be available to the other in order to determine authorization for any given request. One could also easily envision additional information, such as transport and encryption methods, being made available for purposes of authorization. Are you saying we have to keep the revision of 4741 (which does not do authorization either) on hold until the access control work has been completed?? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Mar 9 00:00:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A08D3A6850; Wed, 9 Mar 2011 00:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.309, 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 2EqguIjsVR3K; Wed, 9 Mar 2011 00:00:02 -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 91A783A6822; Wed, 9 Mar 2011 00:00:02 -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 366DC616001; Wed, 9 Mar 2011 09:01:17 +0100 (CET) Date: Wed, 09 Mar 2011 09:01:16 +0100 (CET) Message-Id: <20110309.090116.518558379095829416.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110309074938.GA40759@elstar.local> References: <4D70A5C4.2040005@bwijnen.net> <9ED039155BC64BC7BD62C00C298A9A6B@davidPC> <20110309074938.GA40759@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: iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:00:03 -0000 Hi, Juergen Schoenwaelder wrote: > On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote: > > So maybe 4741bis simply needs to say that since 4741bis defines no > > constraints, anything is acceptable in a netconf username, so 4741bis > > implementations MUST gracefully accept whatever is provided by the > > transport layer as a netconf username. > > Since there is going to be access control for NETCONF, I guess we > implicitely do expect that the username is a UTF8 string. But do we care in what format the transport delivers it to NETCONF? I don't care if the transport delivers a UTF-16 encoded unicode string to the netconf server. However, we (implicitly) expect it to be a subset of unicode, namely the subset that can be encoded in XML (which incidentally is the allowed values for the 'string' YANG data type). /martin From j.schoenwaelder@jacobs-university.de Wed Mar 9 00:09:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE753A6864; Wed, 9 Mar 2011 00:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 3rY79IvytvtR; Wed, 9 Mar 2011 00:09: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 505DD3A6850; Wed, 9 Mar 2011 00:09:08 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFB4DC0073; Wed, 9 Mar 2011 09:10:23 +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 KR9h5TEZ6ITN; Wed, 9 Mar 2011 09:10: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 1A007C0013; Wed, 9 Mar 2011 09:10:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 556B416E7C23; Wed, 9 Mar 2011 09:10:18 +0100 (CET) Date: Wed, 9 Mar 2011 09:10:18 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110309081018.GA40962@elstar.local> Mail-Followup-To: Martin Bjorklund , ietfdbh@comcast.net, netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org References: <4D70A5C4.2040005@bwijnen.net> <9ED039155BC64BC7BD62C00C298A9A6B@davidPC> <20110309074938.GA40759@elstar.local> <20110309.090116.518558379095829416.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110309.090116.518558379095829416.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 09 Mar 2011 08:09:09 -0000 On Wed, Mar 09, 2011 at 09:01:16AM +0100, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote: > > > So maybe 4741bis simply needs to say that since 4741bis defines no > > > constraints, anything is acceptable in a netconf username, so 4741bis > > > implementations MUST gracefully accept whatever is provided by the > > > transport layer as a netconf username. > > > > Since there is going to be access control for NETCONF, I guess we > > implicitely do expect that the username is a UTF8 string. > > But do we care in what format the transport delivers it to NETCONF? > I don't care if the transport delivers a UTF-16 encoded unicode > string to the netconf server. > > However, we (implicitly) expect it to be a subset of unicode, namely > the subset that can be encoded in XML (which incidentally is the > allowed values for the 'string' YANG data type). We are talking about how things work conceptually. You implementation might accept whatever format and do translation wherever you want as long as the end result is going to be representable as a UTF8 string. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tomoyuki.iijima.fg@hitachi.com Wed Mar 9 00:09:32 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E213A688A for ; Wed, 9 Mar 2011 00:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57Goa9-GVm73 for ; Wed, 9 Mar 2011 00:09:31 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id B9AF03A687D for ; Wed, 9 Mar 2011 00:09:30 -0800 (PST) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 2CD8E37AC4; Wed, 9 Mar 2011 17:10:46 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p298AkwX025054; Wed, 9 Mar 2011 17:10:46 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p298AjOn000759; Wed, 9 Mar 2011 17:10:45 +0900 X-AuditID: b753bd60-a50bbba000004916-4e-4d7736051e70 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 12F142042F8; Wed, 9 Mar 2011 17:10:45 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p298AR611190524; Wed, 9 Mar 2011 17:10:28 +0900 Message-ID: <4D7735EE.900@hitachi.com> Date: Wed, 09 Mar 2011 17:10:22 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Netconf Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 08:09:32 -0000 Dear WG chairs, > Open mike: > Possible topics: > - (if necessary) Discussion on NETCONF username > - Improved NACM rule specification, features/requirements M. > Bjorklund/A. Bierman > > Any other topics to discuss? I've submitted following draft. I'd appreciate it if you could put this topic on the agenda if time is available. I'm considering sending Netconf Notification over WebSocket(Bi-directional HTTP). I suppose this topic hasn't been discussed yet... http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps-00 Kind regards, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > below is a draft agenda for the NETCONF session in Prague. > Please send us your comments/requests by March 16, 2011. > > Mehmet & Bert > > > (DRAFT) Agenda for NETCONF WG Session > ------------------------------------- > > IETF 80 - Prague, Czech Republic > March 27 - April 1, 2011 > > THURSDAY, March 31, 2011 > 1300-1500 Afternoon Session I > Room Barcelona > > WG Chairs: > Bert Wijnen > Mehmet Ersue > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Chartered items: > > 1. Status of 4741bis and 4742bis (5 minutes - M. Bjorklund/M. > Wassermann) > 2. Network Configuration Protocol Access Control Model - A. > Bierman (40 minutes) > http://tools.ietf.org/html/draft-ietf-netconf-access-control > 3. NETCONF System Notifications - A. Bierman (30 minutes) > draft-ietf-netconf-system-notification > > http://tools.ietf.org/html/draft-ietf-netconf-system-notification > > Open mike: > Possible topics: > - (if necessary) Discussion on NETCONF username > - Improved NACM rule specification, features/requirements M. > Bjorklund/A. Bierman > > Any other topics to discuss? > > AOB > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory TEL: 045-860-2156 (ext. 874-6059) E-mail: tomoyuki.iijima.fg@hitachi.com From mbj@tail-f.com Wed Mar 9 00:27:13 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044243A68B6; Wed, 9 Mar 2011 00:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.285, 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 18JBMTCiUMTB; Wed, 9 Mar 2011 00:27:12 -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 DF0423A68B5; Wed, 9 Mar 2011 00:27:11 -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 5EC75616001; Wed, 9 Mar 2011 09:28:27 +0100 (CET) Date: Wed, 09 Mar 2011 09:28:25 +0100 (CET) Message-Id: <20110309.092825.1038860387346035420.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110309081018.GA40962@elstar.local> References: <20110309074938.GA40759@elstar.local> <20110309.090116.518558379095829416.mbj@tail-f.com> <20110309081018.GA40962@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: iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:27:13 -0000 Juergen Schoenwaelder wrote: > On Wed, Mar 09, 2011 at 09:01:16AM +0100, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote: > > > > So maybe 4741bis simply needs to say that since 4741bis defines no > > > > constraints, anything is acceptable in a netconf username, so 4741bis > > > > implementations MUST gracefully accept whatever is provided by the > > > > transport layer as a netconf username. > > > > > > Since there is going to be access control for NETCONF, I guess we > > > implicitely do expect that the username is a UTF8 string. > > > > But do we care in what format the transport delivers it to NETCONF? > > I don't care if the transport delivers a UTF-16 encoded unicode > > string to the netconf server. > > > > However, we (implicitly) expect it to be a subset of unicode, namely > > the subset that can be encoded in XML (which incidentally is the > > allowed values for the 'string' YANG data type). > > We are talking about how things work conceptually. It doesn't make much sense to say that the string is conceptually encoded in UTF-8. I suggest we add a sentence: The username is a string of characters that match the "Char" production from section 2.2 of [1]. OLD: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. NEW: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from section 2.2 of [1]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. /martin From j.schoenwaelder@jacobs-university.de Wed Mar 9 02:47:52 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F091E3A68FE; Wed, 9 Mar 2011 02:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 anVfRnsnygMo; Wed, 9 Mar 2011 02:47:52 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D7D003A681A; Wed, 9 Mar 2011 02:47:50 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63CD9C0087; Wed, 9 Mar 2011 11:49:06 +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 LFghtf4yLmmB; Wed, 9 Mar 2011 11:49:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6A99C007F; Wed, 9 Mar 2011 11:49:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A46E516E8174; Wed, 9 Mar 2011 11:48:59 +0100 (CET) Date: Wed, 9 Mar 2011 11:48:59 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110309104859.GA41325@elstar.local> Mail-Followup-To: Martin Bjorklund , ietfdbh@comcast.net, netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org References: <20110309074938.GA40759@elstar.local> <20110309.090116.518558379095829416.mbj@tail-f.com> <20110309081018.GA40962@elstar.local> <20110309.092825.1038860387346035420.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110309.092825.1038860387346035420.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 09 Mar 2011 10:47:53 -0000 On Wed, Mar 09, 2011 at 09:28:25AM +0100, Martin Bjorklund wrote: > OLD: > > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The algorithm used to derive the username is > transport protocol specific and in addition specific to the > authentication mechanism used by the transport protocol. NETCONF > transport protocols therefore MUST explain how a NETCONF username is > derived from the authentication mechanisms supported by the transport > protocol. > > NEW: > > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The username is a string of characters that > match the "Char" production from section 2.2 of [1]. The algorithm > used to derive the username is transport protocol specific and in > addition specific to the authentication mechanism used by the > transport protocol. NETCONF transport protocols therefore MUST > explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol. Fine for, especially if David tells us that this change addresses his concern. /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 Mar 9 04:06:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35FB33A6998 for ; Wed, 9 Mar 2011 04:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWeEDjsCP4Dn for ; Wed, 9 Mar 2011 04:06:34 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 16B5A3A698D for ; Wed, 9 Mar 2011 04:06:33 -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 p29C7ft1007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 13:07:41 +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 p29C7eou007919; Wed, 9 Mar 2011 13:07:40 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 13:07: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: Wed, 9 Mar 2011 13:07:39 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> In-Reply-To: <4D7735EE.900@hitachi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft NETCONF Session Agenda for IETF 80 Thread-Index: AcveMX+CdU7ihZ+vQhiS8yVz/8iP9AADIUJA References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> <4D7735EE.900@hitachi.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Tomoyuki Iijima" X-OriginalArrivalTime: 09 Mar 2011 12:07:40.0708 (UTC) FILETIME=[96B15640:01CBDE52] Cc: Netconf Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 12:06:35 -0000 Dear Tomoyuki, the co-chairs would like to see the WG interest first=20 before allocating scarce session time. So, please summarize the main message of your draft in a=20 mail and initiate some discussion on the NETCONF maillist. You can also answer initial questions/comments from my=20 side: - You copied a rather old figure from RFC5277. You should use the figure of and refer to 4741bis. - Why do you think an additional transport binding is=20 necessary? BEEP is also bi-directional. - NETCONF exchanges XML documents with RPC commands.=20 I am missing some examples and explanation how you do=20 this on top of Websocket transport. Mehmet=20 > -----Original Message----- > From: ext Tomoyuki Iijima [mailto:tomoyuki.iijima.fg@hitachi.com] > Sent: Wednesday, March 09, 2011 9:10 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Netconf > Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 >=20 > Dear WG chairs, >=20 > > Open mike: > > Possible topics: > > - (if necessary) Discussion on NETCONF username > > - Improved NACM rule specification, features/requirements M. > > Bjorklund/A. Bierman > > > > Any other topics to discuss? >=20 > I've submitted following draft. I'd appreciate it if you could put this > topic on the agenda if time is available. I'm considering sending > Netconf Notification over WebSocket(Bi-directional HTTP). I suppose > this > topic hasn't been discussed yet... >=20 > http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps-00 >=20 > Kind regards, >=20 > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear NETCONF WG, > > > > below is a draft agenda for the NETCONF session in Prague. > > Please send us your comments/requests by March 16, 2011. > > > > Mehmet & Bert > > > > > > (DRAFT) Agenda for NETCONF WG Session > > ------------------------------------- > > > > IETF 80 - Prague, Czech Republic > > March 27 - April 1, 2011 > > > > THURSDAY, March 31, 2011 > > 1300-1500 Afternoon Session I > > Room Barcelona > > > > WG Chairs: > > Bert Wijnen > > Mehmet Ersue > > > > Scribes (IF no_volunteers THEN wait_forever) > > Agenda bashing (2 minutes) > > WG status review (5 minutes) > > > > Chartered items: > > > > 1. Status of 4741bis and 4742bis (5 minutes - M. Bjorklund/M. > > Wassermann) > > 2. Network Configuration Protocol Access Control Model - A. > > Bierman (40 minutes) > > http://tools.ietf.org/html/draft-ietf-netconf-access-control > > 3. NETCONF System Notifications - A. Bierman (30 minutes) > > draft-ietf-netconf-system-notification > > > > http://tools.ietf.org/html/draft-ietf-netconf-system-notification > > > > Open mike: > > Possible topics: > > - (if necessary) Discussion on NETCONF username > > - Improved NACM rule specification, features/requirements M. > > Bjorklund/A. Bierman > > > > Any other topics to discuss? > > > > AOB > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > . >=20 > -- > Tomoyuki Iijima > Hitachi, Ltd., Central Research Laboratory > TEL: 045-860-2156 (ext. 874-6059) > E-mail: tomoyuki.iijima.fg@hitachi.com From wwwrun@rfc-editor.org Wed Mar 9 05:07:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2013A6948 for ; Wed, 9 Mar 2011 05:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXKPtZ2zFyUv for ; Wed, 9 Mar 2011 05:07:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 916243A69B4 for ; Wed, 9 Mar 2011 05:07:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 09562E0710; Wed, 9 Mar 2011 05:08:51 -0800 (PST) To: balazs.lengyel@ericsson.com, mbj@tail-f.com, dromasca@avaya.com, rbonica@juniper.net, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20110309130851.09562E0710@rfc-editor.org> Date: Wed, 9 Mar 2011 05:08:51 -0800 (PST) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC5717 (2746) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 13:07:35 -0000 The following errata report has been submitted for RFC5717, "Partial Lock Remote Procedure Call (RPC) for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5717&eid=2746 -------------------------------------- Type: Technical Reported by: Mehmet Ersue Section: Appendix C Original Text ------------- Step 6 - Lock user Joe The NETCONF server grants the partial lock. The scope of this second lock includes only the node with name Joe. The lock protects all data below this particular node. Step 7 - Receive lock 2 /usr:top/usr:users/user[usr:name="Joe"]" Corrected Text -------------- Step 6 - Lock user Joe The NETCONF server grants the partial lock. The scope of this second lock includes only the node with name Joe. The lock protects all data below this particular node. Step 7 - Receive lock 2 /usr:top/usr:users/usr:user[usr:name="Joe"] Notes ----- - Appendix C is non-normative. - The instance identifier: /usr:top/usr:users/user[usr:name="Joe"]" must be replaced with: /usr:top/usr:users/usr:user[usr:name="Joe"] Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5717 (draft-ietf-netconf-partial-lock-11) -------------------------------------- Title : Partial Lock Remote Procedure Call (RPC) for NETCONF Publication Date : December 2009 Author(s) : B. Lengyel, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From mbj@tail-f.com Wed Mar 9 05:24:48 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E993A69BF for ; Wed, 9 Mar 2011 05:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.265, 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 COYPaA4mhVIf for ; Wed, 9 Mar 2011 05:24: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 62F023A69BC for ; Wed, 9 Mar 2011 05:24:47 -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 7DA3D76C31C; Wed, 9 Mar 2011 14:26:02 +0100 (CET) Date: Wed, 09 Mar 2011 14:26:01 +0100 (CET) Message-Id: <20110309.142601.832110756066966873.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20110309130851.09562E0710@rfc-editor.org> References: <20110309130851.09562E0710@rfc-editor.org> 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: rbonica@juniper.net, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (2746) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 13:24:48 -0000 Hi, This Errata is correct (i.e. it fixes a bug), but it is a duplicate of Errata ID: 2657. /martin RFC Errata System wrote: > > The following errata report has been submitted for RFC5717, > "Partial Lock Remote Procedure Call (RPC) for NETCONF". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5717&eid=2746 > > -------------------------------------- > Type: Technical > Reported by: Mehmet Ersue > > Section: Appendix C > > Original Text > ------------- > Step 6 - Lock user Joe > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > message-id="104"> > > > > > > The NETCONF server grants the partial lock. The scope of this second > lock includes only the node with name Joe. The lock protects > all data below this particular node. > > Step 7 - Receive lock > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > message-id="104"> > 2 > > /usr:top/usr:users/user[usr:name="Joe"]" > > > > > Corrected Text > -------------- > Step 6 - Lock user Joe > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > message-id="104"> > > > > > > The NETCONF server grants the partial lock. The scope of this second > lock includes only the node with name Joe. The lock protects > all data below this particular node. > > Step 7 - Receive lock > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > message-id="104"> > 2 > > /usr:top/usr:users/usr:user[usr:name="Joe"] > > > > > Notes > ----- > - Appendix C is non-normative. > - The instance identifier: /usr:top/usr:users/user[usr:name="Joe"]" > must be replaced with: /usr:top/usr:users/usr:user[usr:name="Joe"] > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5717 (draft-ietf-netconf-partial-lock-11) > -------------------------------------- > Title : Partial Lock Remote Procedure Call (RPC) for NETCONF > Publication Date : December 2009 > Author(s) : B. Lengyel, M. Bjorklund > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From mehmet.ersue@nsn.com Wed Mar 9 05:38:24 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EA63A67E4 for ; Wed, 9 Mar 2011 05:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5gERIG2kmmY for ; Wed, 9 Mar 2011 05:38:23 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B648C3A683E for ; Wed, 9 Mar 2011 05:38:22 -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 p29DdSnw023679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 14:39:28 +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 p29DdSCa023554; Wed, 9 Mar 2011 14:39:28 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 14:39:28 +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, 9 Mar 2011 14:39:26 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C0A777@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110309.142601.832110756066966873.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5717 (2746) Thread-Index: AcveXYqPLAmwEnNVSXCCzScdSSkniwAARe5w References: <20110309130851.09562E0710@rfc-editor.org> <20110309.142601.832110756066966873.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 09 Mar 2011 13:39:28.0041 (UTC) FILETIME=[6951A990:01CBDE5F] Cc: netconf@ietf.org, rbonica@juniper.net Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (2746) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 13:38:24 -0000 Martin, the new Errata 2746 corrects a bug in the old one. The plan is to reject old Errata 2657 and to accept=20 new Errata 2746, which will done soon by Dan. Mehmet=20 > -----Original Message----- > From: ext Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, March 09, 2011 2:26 PM > To: rfc-editor@rfc-editor.org > Cc: balazs.lengyel@ericsson.com; dromasca@avaya.com; > rbonica@juniper.net; bertietf@bwijnen.net; Ersue, Mehmet (NSN - > DE/Munich); netconf@ietf.org > Subject: Re: [Technical Errata Reported] RFC5717 (2746) >=20 > Hi, >=20 >=20 > This Errata is correct (i.e. it fixes a bug), but it is a duplicate of > Errata ID: 2657. >=20 >=20 > /martin >=20 >=20 > RFC Errata System wrote: > > > > The following errata report has been submitted for RFC5717, > > "Partial Lock Remote Procedure Call (RPC) for NETCONF". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5717&eid=3D2746 > > > > -------------------------------------- > > Type: Technical > > Reported by: Mehmet Ersue > > > > Section: Appendix C > > > > Original Text > > ------------- > > Step 6 - Lock user Joe > > > > > xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > > message-id=3D"104"> > > > > > > > > > > > > The NETCONF server grants the partial lock. The scope of this > second > > lock includes only the node with name Joe. The lock > protects > > all data below this particular node. > > > > Step 7 - Receive lock > > > > > xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > > message-id=3D"104"> > > 2 > > > > /usr:top/usr:users/user[usr:name=3D"Joe"]" > > > > > > > > > > Corrected Text > > -------------- > > Step 6 - Lock user Joe > > > > > xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > > message-id=3D"104"> > > > > > > > > > > > > The NETCONF server grants the partial lock. The scope of this > second > > lock includes only the node with name Joe. The lock > protects > > all data below this particular node. > > > > Step 7 - Receive lock > > > > > xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > > message-id=3D"104"> > > 2 > > > > /usr:top/usr:users/usr:user[usr:name=3D"Joe"] > > > > > > > > > > Notes > > ----- > > - Appendix C is non-normative. > > - The instance identifier: = /usr:top/usr:users/user[usr:name=3D"Joe"]" > > must be replaced with: > /usr:top/usr:users/usr:user[usr:name=3D"Joe"] > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5717 (draft-ietf-netconf-partial-lock-11) > > -------------------------------------- > > Title : Partial Lock Remote Procedure Call (RPC) for > NETCONF > > Publication Date : December 2009 > > Author(s) : B. Lengyel, M. Bjorklund > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > From ietfdbh@comcast.net Tue Mar 8 22:25:34 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D99D3A683C for ; Tue, 8 Mar 2011 22:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 Q1xHRHRHDw+B for ; Tue, 8 Mar 2011 22:25:26 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id BBF093A683D for ; Tue, 8 Mar 2011 22:25:26 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id GuRc1g0021eYJf8A2uSiU0; Wed, 09 Mar 2011 06:26:42 +0000 Received: from davidPC ([67.189.235.106]) by omta19.emeryville.ca.mail.comcast.net with comcast id GuSf1g00l2JQnJT01uSgPb; Wed, 09 Mar 2011 06:26:42 +0000 From: "David Harrington" To: "'Bert \(IETF\) Wijnen'" References: <20110301230555.15990.2719.idtracker@localhost> <4D70A5C4.2040005@bwijnen.net> In-Reply-To: <4D70A5C4.2040005@bwijnen.net> Date: Wed, 9 Mar 2011 01:26:32 -0500 Message-ID: <9ED039155BC64BC7BD62C00C298A9A6B@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcvaR//WUnBeYmaAQzKCavUdZlv7SAD0GaOA X-Mailman-Approved-At: Wed, 09 Mar 2011 05:40:15 -0800 Cc: 'netconf' , 'The IESG' , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 06:25:34 -0000 Hi Bert and others, Wow, "mister harrington"???? Actually, I am not a participant in the WG. I haven't actually read any emails in this WG since last July. I also don't think I've been present in a netconf meeting since at least last July. I am subscribed to the ML, but I don't read it. If you think I should unsubscribe, let me know and I will. I have discussions about DISCUSSes re: many WG documents, but I do not subscribe to all mailing lists, and seldom do those discussions happen on the WG mailing lists. The discussions are held in emails addressed to the DISCUSS holder, and the iesg list, usually by the document authors and/or shepherd, and the secretariat is working to capture those DISCUSS discussions to be archived. and as far as I can tell, that is standard IESG procedure for discussing DISCUSSes. It is NOT standard IESG procedure to require ADs to subscribe and hold discussions on WG mailing lists. Just so you know. But since you asked nicely, I'll respond here. --- The DISCUSS for 4742bis --- 4741bis states " NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol." My concern was not how the "SSH user name" is obtained. It is fine to me that that is implementation-dependent, since different netconf transport implementations might choose different SSH implementations to work with, and might choose different authentication methods, which will result in different things being returned by the SSH implementation. But there is no explanation of how the ***netconf username*** is derived from the ***SSH user name***. As I see it from the text, the intention is that the netconf username has a 1:1 mapping from the SSH user name. Actually, I think that assumption may be incorrect, as we learned in ISMS. IIRC, SSH is rather ambiguous about whether "user name" MUST contain a value (e.g., when using GSSAPI) I think your intent is that ***netconf username will contain whatever the SSH implementation provides to the netconf transport implementation***. I am fine with that intention. But that explanation is not documented in 4742bis. --- The DISCUSS for 4741bis --- I have concerns about whether the ***netconf username*** being provided by the netconf transport layer to its upper layers is clearly defined enough. It is unclear what the format is, what the character set is, and whether the authentication service (e.g., SSH) is included in what the netconf transport layer provides. and the concern is whether what is provided by the netconf transport layer will meet the assumptions of operators. What if, I as an implementer chose to provide a netconf username of the following form? "dbh ssh ssh-password algorithm <<]]>> SSH user name = dharrington@huaweisymantec.com " would this be legal? according to 4741bis and 4742bis, it would appear to be legal, because anything is acceptable ... would it be useable by operators to, for example, specify an access control policy? or map it to existing native access controls? would it be useable by operators to configure an access control policy using netconf? or a CLI? I fear it would not be. But I think this would be perfectly legal according to the netconf standard. that's my concern. So maybe 4741bis simply needs to say that since 4741bis defines no constraints, anything is acceptable in a netconf username, so 4741bis implementations MUST gracefully accept whatever is provided by the transport layer as a netconf username. I think it might be simpler to document the presumed constraints on character set, control characters, etc. But that is a WG choice. But whether the choice is to constrain the netconf username, or NOT constrain it in any way, the choice should be documented so the standard is clear and unambiguous about compliance requirements. --- The DISCUSS for 4741bis --- I have a concern that the netconf transport layer might not return the nature of the authentication mechanism. This might be important to other parts of the system, such as an access control system. If the transport layer does not provide this, is it acceptable for an access control system to violate "netconf layering" to go get that information? will that information be available when an AC system is determining permissions? If so, it is unclear whether the Message layer is actually transport-independent, as claimed in section 1.2. and whether upper layers are transport-independent. The layering diagrams don't really show where an access control system would fit in the architecture. My concern is whether upper layers have the information necessary to identify the authenticated entity. o user: The authenticated identity of the client. The authenticated identity of a client is commonly referred to as the NETCONF username. section 2.2 says: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. This text does not identify what types of permissions must be known to the server. Is this the native access control system that defines the permissions? what types of permissions are you referring to? permission to establish an SSH subsystem? open a netconf session? perform edit-config operations? modify certain portions of the datastore? If "dbh" can be returned from two different transports, but represent two different client identities, how can the server know the associated permissions? "whose permissions are known to the server" is really ambiguous. I think the text is unclear about compliance requirements of the MUST. Those are my concerns, and I don't see them addressed in the ML discussions. dbh > -----Original Message----- > From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] > Sent: Friday, March 04, 2011 3:42 AM > To: David Harrington > Cc: The IESG; netconf-chairs@tools.ietf.org; > draft-ietf-netconf-4741bis@tools.ietf.org; netconf > Subject: Re: David Harrington's Discuss on > draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > More answers/comments from Juergen below. > > Can I ask mister Harrington to participate in the discussion on the > NETCONF WG mailing list? That is the only way to get to convergence > in a reasonable amount of time. Dave, you ARE a particpant in the WG, > and I hope you can pay attention there till we reach agreement on this > DISCUSS. I hate to have to keep forarding yoru emails to the WG and > then forward any WG technical responses back to you. > That is not productive, and things may get lost in that path. > > Thanks, > Bert Wijnen > Document shepherd > > -------- Original Message -------- > Subject: Re: [Netconf] FW: David Harrington's Discuss on > draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT) > Date: Thu, 3 Mar 2011 18:07:23 +0100 > From: Juergen Schoenwaelder > > Reply-To: Juergen Schoenwaelder > > To: Ersue, Mehmet (NSN - DE/Munich) > CC: Netconf > > > > On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN > - DE/Munich) wrote: > > > Any comments? Pls also check the mail below from > > David Harrington. > > [... stuff removed I figured out is not helpful to send ...] > > NETCONF is the wrong place to constraint user name. For SSH, this is > a no-brainer anyway. > > /js > > PS: We dealt with the uniquess questions explaining that this is an > ACM issue and note that it is even mentioned in the Security > Considerations section: > > [...] Second, it could be desirable to authorize based on > mechanisms available in the secure transport layer (SSH, > BEEP, etc). > > PS: RFC 4252 says: > > byte SSH_MSG_USERAUTH_REQUEST > string user name in ISO-10646 UTF-8 encoding [RFC3629] > > RFC 4251 says: > > string > > Arbitrary length binary string. Strings are allowed to contain > arbitrary binary data, including null characters and 8-bit > characters. They are stored as a uint32 containing its length > (number of bytes that follow) and zero (= empty string) or more > bytes that are the value of the string. Terminating null > characters are not used. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ______________________ > > > > > > On 3/2/11 12:05 AM, David Harrington wrote: > > David Harrington has entered the following ballot position for > > draft-ietf-netconf-4741bis-09: Discuss > > > > When responding, please keep the subject line intact and > reply to all > > email addresses included in the To and CC lines. (Feel free > to cut this > > introductory paragraph, however.) > > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > 1) should there be constraints on the basic format of > username? if it is expected to be specified by an operator in > config files or databases, should it be human-readable? ascii? utf-8? > > > > 2) should the format be predictable, so the operator can > determine what the NC username will be, given a knowledge of > the corresponding identifier in the secure transport protocol? > > > > 3) commit MUST revert at 600 secs, but timeout is > configurable., what if somebody sets it to 700 seconds? MUST > it still revert at 600? Can a low timeout cause a denial of service? > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > 1) copyright in yang module needs updating. > > > > 2) appendix F doesn't mention dropping the local file > requirement for URLs, > > > > 3) terminology should probably define username, not user. > It is doubtful username is commonly referred, since it did > not exist in 1.0. > > > > 4) I found the use of RFC2119 laniguage rather > inconsistent. Some uses of "can" probbaly should have been > MAY. Some uses of "are" probbaly should have been MUST, to > ensure interoperability. > > > > 5) I support Lars' Discuss. There is no requirement to use > a transport protocol that provides congestion control. If a > transport is used that does not already provide congestion > control, then the NC transport should provide congestion > control. It is RECOMMENDED to use an existing transprt > standard that provides congestion control. > > > > > > > > > > From mbj@tail-f.com Wed Mar 9 05:47:00 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F3D3A6869 for ; Wed, 9 Mar 2011 05:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.247, 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 lIhLJBa5IN1g for ; Wed, 9 Mar 2011 05:46:59 -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 B28653A6881 for ; Wed, 9 Mar 2011 05:46:59 -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 F049776C2F3; Wed, 9 Mar 2011 14:48:14 +0100 (CET) Date: Wed, 09 Mar 2011 14:48:13 +0100 (CET) Message-Id: <20110309.144813.955031449097613214.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401C0A777@DEMUEXC006.nsn-intra.net> References: <20110309130851.09562E0710@rfc-editor.org> <20110309.142601.832110756066966873.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0A777@DEMUEXC006.nsn-intra.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rbonica@juniper.net, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (2746) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Mar 2011 13:47:00 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > Martin, > > the new Errata 2746 corrects a bug in the old one. Aha, the extra double quote. Ok, good. /martin From phil@juniper.net Wed Mar 9 06:09:36 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAC13A69E0; Wed, 9 Mar 2011 06:09:36 -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 F2RQJuIW0gc5; Wed, 9 Mar 2011 06:09:36 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 13BD83A69D9; Wed, 9 Mar 2011 06:09:27 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTXeKY+TxTT1fPvBjhzKWKiKdkoqiJWcC@postini.com; Wed, 09 Mar 2011 06:10:52 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Mar 2011 05:56:51 -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 p29Dvkv19544; Wed, 9 Mar 2011 05:57:46 -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 p29DYX1F016190; Wed, 9 Mar 2011 13:34:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103091334.p29DYX1F016190@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20110309104859.GA41325@elstar.local> Date: Wed, 9 Mar 2011 08:34:33 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:09:36 -0000 >On Wed, Mar 09, 2011 at 09:28:25AM +0100, Martin Bjorklund wrote: > The username is a string of characters that match the "Char" > production from section 2.2 of [1]. What is [1]? Are you limiting the character set? Are you saying that this string must be encodable in utf-8? Are there strings that cannot be encoded in utf-8? Does this sentence add any useful information for the implementor? Juergen Schoenwaelder writes: >Fine for, especially if David tells us that this change addresses his >concern. I'm baffled as to how this addresses his concern, which was that our use of the term "implementation-dependent" is "woefully inadequate". Describing or restricting the encoding does not seem to be related. Nit: In 4742bis, the sentence "How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent." should not use a hyphen. (I guess that's "MUST NOT use" ;^) Thanks, Phil From mbj@tail-f.com Wed Mar 9 06:13:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EE93A69D9; Wed, 9 Mar 2011 06:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, 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 Uj1Re89q1pR1; Wed, 9 Mar 2011 06:13:11 -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 15F1A3A69C9; Wed, 9 Mar 2011 06:13:11 -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 0293C76C2C7; Wed, 9 Mar 2011 15:14:26 +0100 (CET) Date: Wed, 09 Mar 2011 15:14:25 +0100 (CET) Message-Id: <20110309.151425.693799676206062637.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201103091334.p29DYX1F016190@idle.juniper.net> References: <20110309104859.GA41325@elstar.local> <201103091334.p29DYX1F016190@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: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:13:11 -0000 Phil Shafer wrote: > >On Wed, Mar 09, 2011 at 09:28:25AM +0100, Martin Bjorklund wrote: > > The username is a string of characters that match the "Char" > > production from section 2.2 of [1]. > > What is [1]? [1] is the XML spec, so section 2.2 is http://www.w3.org/TR/REC-xml/#charsets. The sentence simply says that the username must not contain characters that cannot be encoded in XML. /martin From phil@juniper.net Wed Mar 9 07:26:57 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC103A689F; Wed, 9 Mar 2011 07:26:57 -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 wDG0nwAW8zx5; Wed, 9 Mar 2011 07:26:56 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 609603A6821; Wed, 9 Mar 2011 07:26:48 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTXechO0XocgMleLP3SER1QNDBL6x8zTi@postini.com; Wed, 09 Mar 2011 07:28:13 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Mar 2011 07:24:33 -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 p29FPSv60208; Wed, 9 Mar 2011 07:25:28 -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 p29F2FqJ016913; Wed, 9 Mar 2011 15:02:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103091502.p29F2FqJ016913@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110309.151425.693799676206062637.mbj@tail-f.com> Date: Wed, 9 Mar 2011 10:02:15 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:26:57 -0000 Martin Bjorklund writes: >The sentence simply says that the username must not contain characters >that cannot be encoded in XML. So we are making control characters illegal in user names? I'm not saying this is common, but I don't really want to take the "well no one would _ever_ do that" attitude that prevented XML from encoding control characters. Thanks, Phil From mbj@tail-f.com Wed Mar 9 08:01:22 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28D13A68C9; Wed, 9 Mar 2011 08:01:22 -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 oFQc+osXuYT0; Wed, 9 Mar 2011 08:01:22 -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 CB6953A68C8; Wed, 9 Mar 2011 08:01:21 -0800 (PST) Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 0079B76C350; Wed, 9 Mar 2011 17:02:36 +0100 (CET) Date: Wed, 09 Mar 2011 17:02:34 +0100 (CET) Message-Id: <20110309.170234.199713540.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201103091502.p29F2FqJ016913@idle.juniper.net> References: <20110309.151425.693799676206062637.mbj@tail-f.com> <201103091502.p29F2FqJ016913@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: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:01:22 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >The sentence simply says that the username must not contain characters > >that cannot be encoded in XML. > > So we are making control characters illegal in user names? I'm > not saying this is common, but I don't really want to take the > "well no one would _ever_ do that" attitude that prevented XML > from encoding control characters. We have to play along with the rules invented by XML. YANG does the same thing. /martin From biermana@Brocade.com Wed Mar 9 08:06:58 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902943A6859; Wed, 9 Mar 2011 08:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.247, 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 o8-0to9WyeqP; Wed, 9 Mar 2011 08:06:57 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id B62143A67D8; Wed, 9 Mar 2011 08:06:57 -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 p29G8C16009218; Wed, 9 Mar 2011 08:08:12 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id uxbpug1qu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Mar 2011 08:08:12 -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, 9 Mar 2011 08:10:48 -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, 9 Mar 2011 08:08:10 -0800 From: Andy Bierman To: Phil Shafer , Martin Bjorklund Date: Wed, 9 Mar 2011 08:08:09 -0800 Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: Acvebp+HirqHPEi1SmqRB9r88/ueqAABM3tA Message-ID: References: <20110309.151425.693799676206062637.mbj@tail-f.com> <201103091502.p29F2FqJ016913@idle.juniper.net> In-Reply-To: <201103091502.p29F2FqJ016913@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_07:2011-03-09, 2011-03-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103090096 Cc: "iesg@ietf.org" , "draft-ietf-netconf-4741bis@tools.ietf.org" , "ietfdbh@comcast.net" , "netconf-chairs@tools.ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:06:58 -0000 Hi, I think the restriction to limit user names to XML is OK. We have a practical need to return user names for data in 3 standard YANG modules already (2 still I-Ds). In reality, there are so many applications that expect ASCII, that it is difficult to even use UTF-8 chars in user names. (Even some of the email addresses on this thread cannot use their real spelling because of non-ASCII chars in them.) Andy -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Wednesday, March 09, 2011 7:02 AM To: Martin Bjorklund Cc: j.schoenwaelder@jacobs-university.de; iesg@ietf.org; ietfdbh@comcast.ne= t; netconf@ietf.org; netconf-chairs@tools.ietf.org; draft-ietf-netconf-4741= bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-474= 1bis-09: (with DISCUSS and COMMENT)=20 Martin Bjorklund writes: >The sentence simply says that the username must not contain characters >that cannot be encoded in XML. So we are making control characters illegal in user names? I'm not saying this is common, but I don't really want to take the "well no one would _ever_ do that" attitude that prevented XML from encoding control characters. Thanks, Phil From randy_presuhn@mindspring.com Wed Mar 9 10:06:52 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E763A68F5; Wed, 9 Mar 2011 10:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 YhBVVKolBLgz; Wed, 9 Mar 2011 10:06:51 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D64E83A68CF; Wed, 9 Mar 2011 10:06:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kiwKH4z9RbqJ+FbG+6uLMweowDxBxJoLSgoelzcixWZ1l6rWOwrwpcZO61ex9G13; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PxNnq-0005Qe-M2; Wed, 09 Mar 2011 13:08:06 -0500 Message-ID: <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Juergen Schoenwaelder" , "Phil Shafer" References: <201103091334.p29DYX1F016190@idle.juniper.net> Date: Wed, 9 Mar 2011 10:08:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb2f666eb8d81ad82f1beef154bb1f38d1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Cc: netconf@ietf.org, ietfdbh@comcast.net, iesg@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:06:52 -0000 Hi - > From: "Phil Shafer" > To: "Juergen Schoenwaelder" > Cc: ; ; ; ; > Sent: Wednesday, March 09, 2011 5:34 AM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > >On Wed, Mar 09, 2011 at 09:28:25AM +0100, Martin Bjorklund wrote: > > The username is a string of characters that match the "Char" > > production from section 2.2 of [1]. > > What is [1]? Are you limiting the character set? Are you saying > that this string must be encodable in utf-8? Are there strings > that cannot be encoded in utf-8? Does this sentence add any useful > information for the implementor? ... Since these things would need to be matched, I tried to find where the document spells out which normalization form is to be used. I couldn't. Did I miss something, or is the choice of normalization form left to the implementors' imaginations? Randy From j.schoenwaelder@jacobs-university.de Wed Mar 9 12:25:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F963A6AA8; Wed, 9 Mar 2011 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.088, 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 k-emB0ns4lkh; Wed, 9 Mar 2011 12:25: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 2D55D3A6AA7; Wed, 9 Mar 2011 12:25:08 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 320D0C001E; Wed, 9 Mar 2011 21:26:24 +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 RP2Tcu7DTl7L; Wed, 9 Mar 2011 21:26: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 6C31EC0003; Wed, 9 Mar 2011 21:26:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 74A0A16E92DC; Wed, 9 Mar 2011 21:25:55 +0100 (CET) Date: Wed, 9 Mar 2011 21:25:55 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110309202555.GA43502@elstar.local> Mail-Followup-To: Martin Bjorklund , phil@juniper.net, iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org References: <20110309.151425.693799676206062637.mbj@tail-f.com> <201103091502.p29F2FqJ016913@idle.juniper.net> <20110309.170234.199713540.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110309.170234.199713540.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 09 Mar 2011 20:25:09 -0000 On Wed, Mar 09, 2011 at 05:02:34PM +0100, Martin Bjorklund wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > > >The sentence simply says that the username must not contain characters > > >that cannot be encoded in XML. > > > > So we are making control characters illegal in user names? I'm > > not saying this is common, but I don't really want to take the > > "well no one would _ever_ do that" attitude that prevented XML > > from encoding control characters. > > We have to play along with the rules invented by XML. YANG does the > same thing. RFC 6020 says for the string data type: The string built-in type represents human-readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: ;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. string = *char char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / %x10000-10FFFF Is this 100% identical with what section 2.2 in [1] says? Since we need to represent user names in YANG data models, we better make sure this is doable without any complications. /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 Wed Mar 9 12:33:50 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970453A6A6E; Wed, 9 Mar 2011 12:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 1ckooVuG4Koy; Wed, 9 Mar 2011 12:33:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 475E33A6969; Wed, 9 Mar 2011 12:33:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EAE9C0003; Wed, 9 Mar 2011 21:35:04 +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 6LqaqteFb9Ye; Wed, 9 Mar 2011 21:35:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6822C001C; Wed, 9 Mar 2011 21:35:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88EA516E9339; Wed, 9 Mar 2011 21:34:36 +0100 (CET) Date: Wed, 9 Mar 2011 21:34:36 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110309203436.GB43502@elstar.local> Mail-Followup-To: Randy Presuhn , Phil Shafer , iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 09 Mar 2011 20:33:51 -0000 On Wed, Mar 09, 2011 at 10:08:16AM -0800, Randy Presuhn wrote: > Since these things would need to be matched, I tried to find where the > document spells out which normalization form is to be used. I couldn't. > Did I miss something, or is the choice of normalization form left to the > implementors' imaginations? makes an interesting recommendation that applications should preserve input code points, only normalizing strings to the application's preferred normal form for internal use only... YANG does not force a normalization for the string type. It tries to preserve them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed Mar 9 12:35:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40B53A6AAD for ; Wed, 9 Mar 2011 12:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 ROqBki+YvLCD for ; Wed, 9 Mar 2011 12:35:34 -0800 (PST) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id C10413A69FD for ; Wed, 9 Mar 2011 12:35:34 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta05.emeryville.ca.mail.comcast.net with comcast id H8Tq1g0041Y3wxoA58cr4l; Wed, 09 Mar 2011 20:36:51 +0000 Received: from davidPC ([67.189.235.106]) by omta15.emeryville.ca.mail.comcast.net with comcast id H8cV1g0142JQnJT8b8cduG; Wed, 09 Mar 2011 20:36:50 +0000 From: "David Harrington" To: "'Martin Bjorklund'" , References: <4D70A5C4.2040005@bwijnen.net><9ED039155BC64BC7BD62C00C298A9A6B@davidPC><20110309074938.GA40759@elstar.local> <20110309.090116.518558379095829416.mbj@tail-f.com> In-Reply-To: <20110309.090116.518558379095829416.mbj@tail-f.com> Date: Wed, 9 Mar 2011 21:36:21 +0100 Message-ID: <7B6909DFBB78455CB368D890EEA0AF73@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcveMC3lWFT/LbueRtm5zwqFjNWI4wAaRSfA Cc: iesg@ietf.org, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:35:35 -0000 Hi, I would like the (implicitly) in your response made explicit in the document. I don't care that much whether this is specified as cross-transport (i.e., in 4741bis) or per-transport (i.e. in 4742bis), but the expectation should be documented. dbh > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, March 09, 2011 9:01 AM > To: j.schoenwaelder@jacobs-university.de > Cc: ietfdbh@comcast.net; netconf@ietf.org; > draft-ietf-netconf-4741bis@tools.ietf.org; > netconf-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on > draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > Hi, > > Juergen Schoenwaelder wrote: > > On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote: > > > So maybe 4741bis simply needs to say that since 4741bis defines no > > > constraints, anything is acceptable in a netconf > username, so 4741bis > > > implementations MUST gracefully accept whatever is provided by the > > > transport layer as a netconf username. > > > > Since there is going to be access control for NETCONF, I guess we > > implicitely do expect that the username is a UTF8 string. > > But do we care in what format the transport delivers it to NETCONF? > I don't care if the transport delivers a UTF-16 encoded unicode > string to the netconf server. > > However, we (implicitly) expect it to be a subset of unicode, namely > the subset that can be encoded in XML (which incidentally is the > allowed values for the 'string' YANG data type). > > > /martin > From ietfdbh@comcast.net Wed Mar 9 13:00:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273F23A6AD0 for ; Wed, 9 Mar 2011 13:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Wrv39-irStFC for ; Wed, 9 Mar 2011 13:00:34 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id F3CF43A6AC0 for ; Wed, 9 Mar 2011 13:00:33 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id H91q1g0021Y3wxoA191r82; Wed, 09 Mar 2011 21:01:51 +0000 Received: from davidPC ([67.189.235.106]) by omta15.emeryville.ca.mail.comcast.net with comcast id H91j1g02R2JQnJT8b91kFn; Wed, 09 Mar 2011 21:01:47 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Martin Bjorklund'" References: <20110309.151425.693799676206062637.mbj@tail-f.com> <201103091502.p29F2FqJ016913@idle.juniper.net> <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> In-Reply-To: <20110309202555.GA43502@elstar.local> Date: Wed, 9 Mar 2011 22:01:36 +0100 Message-ID: <795EF5C74EF246A593C43298AA44C877@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcvemEVYhl3ouMVqTfuO9qxXoTkcRAAAxC0w Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:00:35 -0000 Hi, The crux of my discuss for 4741bis is that the netconf username will be used by other things, such as CLIs, scripts, YANG, etc. and should be in a format compatible with expected usage. Expected usage appears to include embedding in XML documents, YANG data models, native CLI handling, and matching (such as during lookup in an access control system, whether proprietary or standardized). I don't care whether the format of the netconf username is compatible with section 2.2 of the XML specification, or with RFC 6020's string data type, or ascii, or some other choice of the WG (although I recommend using something standardized). The (implicit) expectation should be made explicit in documentation (and I think 4741bis makes the most sense to define the expected format of a netconf username). dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 09, 2011 9:26 PM > To: Martin Bjorklund > Cc: phil@juniper.net; iesg@ietf.org; ietfdbh@comcast.net; > netconf@ietf.org; netconf-chairs@tools.ietf.org; > draft-ietf-netconf-4741bis@tools.ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on > draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > On Wed, Mar 09, 2011 at 05:02:34PM +0100, Martin Bjorklund wrote: > > Phil Shafer wrote: > > > Martin Bjorklund writes: > > > >The sentence simply says that the username must not > contain characters > > > >that cannot be encoded in XML. > > > > > > So we are making control characters illegal in user names? I'm > > > not saying this is common, but I don't really want to take the > > > "well no one would _ever_ do that" attitude that prevented XML > > > from encoding control characters. > > > > We have to play along with the rules invented by XML. YANG does the > > same thing. > > RFC 6020 says for the string data type: > > The string built-in type represents human-readable strings in YANG. > Legal characters are tab, carriage return, line feed, and the legal > characters of Unicode and ISO/IEC 10646 [ISO.10646]: > > ;; any Unicode character, excluding the surrogate blocks, > ;; FFFE, and FFFF. > string = *char > char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / > %x10000-10FFFF > > Is this 100% identical with what section 2.2 in [1] says? Since we > need to represent user names in YANG data models, we better make sure > this is doable without any complications. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From mbj@tail-f.com Wed Mar 9 13:08:51 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5843A6AB0; Wed, 9 Mar 2011 13:08:51 -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 CXHdQqHLi0nA; Wed, 9 Mar 2011 13:08:50 -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 274A43A6A69; Wed, 9 Mar 2011 13:08:50 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1FCD476C2C8; Wed, 9 Mar 2011 22:10:00 +0100 (CET) Date: Wed, 09 Mar 2011 22:09:55 +0100 (CET) Message-Id: <20110309.220955.117242983.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <795EF5C74EF246A593C43298AA44C877@davidPC> References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> 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, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:08:51 -0000 Hi David, "David Harrington" wrote: > Hi, > > The crux of my discuss for 4741bis is that the netconf username will > be used by other things, such as CLIs, scripts, YANG, etc. and should > be in a format compatible with expected usage. > Expected usage appears to include embedding in XML documents, YANG > data models, native CLI handling, and matching (such as during lookup > in an access control system, whether proprietary or standardized). Agreed. > I don't care whether the format of the netconf username is compatible > with section 2.2 of the XML specification, or with RFC 6020's string > data type, or ascii, or some other choice of the WG (although I > recommend using something standardized). > > The (implicit) expectation should be made explicit in documentation > (and I think 4741bis makes the most sense to define the expected > format of a netconf username). Would the following change resolve your DISCUSS? I suggest we add a sentence: The username is a string of characters that match the "Char" production from section 2.2 of [1]. OLD: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. NEW: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from section 2.2 of [1]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. /martin From kwatsen@juniper.net Wed Mar 9 13:56:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB733A659A for ; Wed, 9 Mar 2011 13:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 kiroL2bcBEmx for ; Wed, 9 Mar 2011 13:56:09 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 9905F3A6407 for ; Wed, 9 Mar 2011 13:56:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTXf3xvWU1bg9uRiqySL/b6+GPsbKqJvG@postini.com; Wed, 09 Mar 2011 13:57:26 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; Wed, 9 Mar 2011 13:42:46 -0800 From: Kent Watsen To: "netconf@ietf.org" Date: Wed, 9 Mar 2011 13:43:38 -0800 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5sab6tCM7W3WQn2dazboZbfALgArNizQ Message-ID: <84600D05C20FF943918238042D7670FD38625361DB@EMBX01-HQ.jnpr.net> References: <20110308231501.17204.46756.idtracker@localhost> In-Reply-To: <20110308231501.17204.46756.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:56:11 -0000 This I-D doesn't quite meet my needs and I'm wondering if it's because the = I-D's scope isn't broad enough or because the plan is to have a complementa= ry set of I-Ds fill in the void. To clarify, our current NMS application i= s interested in the following kinds of events: - FRU added/removed - Software added/removed - Configuration changed - Interface up/down I don't imagine every NMS to have the same interests and I even imagine our= s will have new interests over time (i.e. user/policy/license added/removed= , etc.). So this makes me wonder what the plan is to accommodate these oth= er events. Will we continually update this RFC or will we lets other RFCs = define their own events? For instance, a RFC for managing hardware defines= hardware-oriented notifications, a RFC for managing software defines softw= are-oriented notifications, etc. NITS ---- 1. the "netconf-config-change" description says "An edit record will be pre= sent for each distinct edit operation on the target datastore." How does = this relate to implicit changes? Can we be sure to indicate that the list = of "distinct edit operations" reflects the final state of the target datast= ore and not necessarily what was passed in ? 2. The description for modified-capability says "The new modified value of = the complete URI is returned", but the description for added-capability and= deleted-capability don't indicate if the complete or base URI are returned= . Assuming that it is intended that the complete uri is always returned, I= suggest that the description for the top-level netconf-capability-change s= ays that and we remove the word "complete" from the modified-capability des= cription (i.e. should now read "The new modified value of the URI is return= ed.") 3. I'm still twisted about the "netconf-config-change" event not identifyin= g *which* startup/running datastore was modified. (i.e. Juniper's Dual REs= or Yuma's "--startup" parameter). Even though, as Martin points out, NetC= onf doesn't officially support more than one instance of a datastore and th= at a vendor-specific augmentation can be used, it's such a PITA. Or maybe,= to turn this around, should we now start defining an ability for NetConf t= o support more than one instance of datastores? 4. missing "Acknowledgements" section 5. s/parms/params/g ---or--- s/parms/parameters/g Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 6:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.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 System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datast= ores. However, client applications often need to be aware of common NETCON= F system events such as a change in NETCONF capabilities, which may impact = management applications. Standard mechanisms are needed to support the mon= itoring of the NETCONF system events within the NETCONF server. This docum= ent defines a YANG module which allows a NETCONF client to receive notifica= tions for some common events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From muthu@cisco.com Wed Mar 9 15:29:17 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA813A6765; Wed, 9 Mar 2011 15:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdW13mRW5xXX; Wed, 9 Mar 2011 15:29:16 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4228C3A672F; Wed, 9 Mar 2011 15:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=muthu@cisco.com; l=2680; q=dns/txt; s=iport; t=1299713433; x=1300923033; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PxjhdlyHJiOS0tHm97QNnIgRBCyV7hDgmVoYqMg0tko=; b=DXr7k7RnzK34CvWVMVJGtmJjYN6Tqn5AYOVaPMNHjOK8/e19nYFIhIA3 nvUtz2JIdQ9UVmrQi8jl+3Dvg19esmbeCepJtgNgWsdi5VzcOGq1KurLr qcUqS0pd7HH7sL59JJuCd+KXSosSxKTAUjZqjwLrEAfQMbm9VMR0TNb6P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAL6cd02rRN+K/2dsb2JhbACYRY4tdKZtnDWFZQSFIopm X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208";a="273531690" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2011 23:30:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p29NUTVr025124; Wed, 9 Mar 2011 23:30:33 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 15:30:31 -0800 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, 9 Mar 2011 15:30:30 -0800 Message-ID: In-Reply-To: <20110308231501.17204.46756.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5yTf8HgJxyQ6SReC43ao+dhcWwAxuDfA References: <20110308231501.17204.46756.idtracker@localhost> From: "Muthumayan Madhayyan (muthu)" To: , X-OriginalArrivalTime: 09 Mar 2011 23:30:31.0947 (UTC) FILETIME=[FB7445B0:01CBDEB1] Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:29:17 -0000 Hi: 1. In netconf-config-change notification, there is a list element called 'edit'. Is that really meant to be a list ? Is so, what is the key for this list ? Also where is the type instance-identifier defined (would that be in ietf-netconf ?). I presume that the motivation for sending this instance information is for the NMS to do a partial retrieval of config ? 2. Seems like the netconf-session-start and netconf-session-end is primarily meant to track netconf user sessions. The prefix netconf-session-* and the use of netconf specific enumerations like 'bad-hello' etc. seems to suggest that. However, the session-id in common-session-parms seems to suggest that this notification can be sent for non-NETCONF sessions as well. If so, some of the enumerations for termination-reason don't really make sense. Would it help to state that non-NETCONF terminations would be tracked under 'other' enum ? 3. In the grouping changed-by-parms, one of the choice is 'server'. What is the use case where server can initiate a configuration change without user intervention ?=20 Thanks, - muthu -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 3:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common NETCONF system events such as a change in NETCONF capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the NETCONF system 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-notificati ons-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From biermana@Brocade.com Wed Mar 9 16:49:49 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD1E3A6B1F for ; Wed, 9 Mar 2011 16:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0BcteSvqHrZ for ; Wed, 9 Mar 2011 16:49:48 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 8F3C73A6B1C for ; Wed, 9 Mar 2011 16:49:48 -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 p2A0lo0c004110; Wed, 9 Mar 2011 16:51:03 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id uxhqhg4sb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Mar 2011 16:51:03 -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; Wed, 9 Mar 2011 16:58:57 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 9 Mar 2011 16:51:02 -0800 From: Andy Bierman To: Kent Watsen , "netconf@ietf.org" Date: Wed, 9 Mar 2011 16:51:01 -0800 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5sab6tCM7W3WQn2dazboZbfALgArNizQAAo3VUA= Message-ID: References: <20110308231501.17204.46756.idtracker@localhost> <84600D05C20FF943918238042D7670FD38625361DB@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD38625361DB@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_09:2011-03-09, 2011-03-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-1012030000 definitions=main-1103090190 Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:49:49 -0000 Hi, Events other than config-change (on your) list are out of scope. You can post a new I-D to the netmod WG I guess, proposing new work. Nits answered inline. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, March 09, 2011 1:44 PM To: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-0= 3.txt This I-D doesn't quite meet my needs and I'm wondering if it's because the = I-D's scope isn't broad enough or because the plan is to have a complementa= ry set of I-Ds fill in the void. To clarify, our current NMS application i= s interested in the following kinds of events: - FRU added/removed - Software added/removed - Configuration changed - Interface up/down I don't imagine every NMS to have the same interests and I even imagine our= s will have new interests over time (i.e. user/policy/license added/removed= , etc.). So this makes me wonder what the plan is to accommodate these oth= er events. Will we continually update this RFC or will we lets other RFCs = define their own events? For instance, a RFC for managing hardware defines= hardware-oriented notifications, a RFC for managing software defines softw= are-oriented notifications, etc. NITS ---- 1. the "netconf-config-change" description says "An edit record will be pre= sent for each distinct edit operation on the target datastore." How does = this relate to implicit changes? Can we be sure to indicate that the list = of "distinct edit operations" reflects the final state of the target datast= ore and not necessarily what was passed in ? [ab: the server is free to decide how to describe the edits that took place and how much detail is preserved. There is no canonical form of an edit defined.] 2. The description for modified-capability says "The new modified value of = the complete URI is returned", but the description for added-capability and= deleted-capability don't indicate if the complete or base URI are returned= . Assuming that it is intended that the complete uri is always returned, I= suggest that the description for the top-level netconf-capability-change s= ays that and we remove the word "complete" from the modified-capability des= cription (i.e. should now read "The new modified value of the URI is return= ed.") [ab: good point -- the full form of the URI is always given] 3. I'm still twisted about the "netconf-config-change" event not identifyin= g *which* startup/running datastore was modified. (i.e. Juniper's Dual REs= or Yuma's "--startup" parameter). Even though, as Martin points out, NetC= onf doesn't officially support more than one instance of a datastore and th= at a vendor-specific augmentation can be used, it's such a PITA. Or maybe,= to turn this around, should we now start defining an ability for NetConf t= o support more than one instance of datastores? [ab: the target-datastore enum says it is running or startup.] 4. missing "Acknowledgements" section [ab: OK] 5. s/parms/params/g ---or--- s/parms/parameters/g [ab: OK -- will use 2nd one] Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 6:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.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 System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datast= ores. However, client applications often need to be aware of common NETCON= F system events such as a change in NETCONF capabilities, which may impact = management applications. Standard mechanisms are needed to support the mon= itoring of the NETCONF system events within the NETCONF server. This docum= ent defines a YANG module which allows a NETCONF client to receive notifica= tions for some common events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion 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 Mar 9 16:56:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B783A6B1F; Wed, 9 Mar 2011 16:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.185, 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 vrr6+DJcbiDc; Wed, 9 Mar 2011 16:56:41 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 3B43E3A6B08; Wed, 9 Mar 2011 16:56:41 -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 p2A0rUeX010134; Wed, 9 Mar 2011 16:57:58 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id uxhqhg4xa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Mar 2011 16:57:58 -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; Wed, 9 Mar 2011 17:05:52 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 9 Mar 2011 16:57:57 -0800 From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" , "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Date: Wed, 9 Mar 2011 16:57:55 -0800 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5yTf8HgJxyQ6SReC43ao+dhcWwAxuDfAAAPOoXA= Message-ID: References: <20110308231501.17204.46756.idtracker@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-10_01:2011-03-09, 2011-03-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-1012030000 definitions=main-1103090191 Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:56:42 -0000 Hi, answers inline. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Muthumayan Madhayyan (muthu) Sent: Wednesday, March 09, 2011 3:31 PM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-0= 3.txt Hi: 1. In netconf-config-change notification, there is a list element called 'edit'. Is that really meant to be a list ? Is so, what is the key for this list ? Also where is the type instance-identifier defined (would that be in ietf-netconf ?). I presume that the motivation for sending this instance information is for the NMS to do a partial retrieval of config ? [ab: a config-false list does not need a key. The server is free to retain and report as much detail as it wants. E.g. Add to candidate: merge new /mylist[id=3D1] entry merge new /mylist[id=3D2] entry Then . A server may report this as 1 merge on /mylist or 2 merges (1 on /mylist[id=3D1] and 1 on /mylist[id=3D2]).] 2. Seems like the netconf-session-start and netconf-session-end is primarily meant to track netconf user sessions. The prefix netconf-session-* and the use of netconf specific enumerations like 'bad-hello' etc. seems to suggest that. However, the session-id in common-session-parms seems to suggest that this notification can be sent for non-NETCONF sessions as well. If so, some of the enumerations for termination-reason don't really make sense. Would it help to state that non-NETCONF terminations would be tracked under 'other' enum ? [ab: I can add a note stating that non-NETCONF sessions are terminated as 'other'.] 3. In the grouping changed-by-parms, one of the choice is 'server'. What is the use case where server can initiate a configuration change without user intervention ?=20 [ab: a server may create config as a result of hardware change, on initially when a fresh running config is created as the factory default config. The server may get some OOB request to add a new VLAN for example, and could create non-default config.] Thanks, - muthu -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 3:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common NETCONF system events such as a change in NETCONF capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the NETCONF system 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-notificati ons-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Wed Mar 9 17:01:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E543A6AFE for ; Wed, 9 Mar 2011 17:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.164, 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 nGOaAa9HdlsP for ; Wed, 9 Mar 2011 17:01:40 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 509713A6937 for ; Wed, 9 Mar 2011 17:01:40 -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 p2A0rUeq010134; Wed, 9 Mar 2011 17:02:57 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id uxhqhg521-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Mar 2011 17:02:57 -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; Wed, 9 Mar 2011 17:10:52 -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, 9 Mar 2011 17:02:56 -0800 From: Andy Bierman To: Andy Bierman , Kent Watsen , "netconf@ietf.org" Date: Wed, 9 Mar 2011 17:02:55 -0800 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5sab6tCM7W3WQn2dazboZbfALgArNizQAAo3VUAAAHOwEA== Message-ID: References: <20110308231501.17204.46756.idtracker@localhost> <84600D05C20FF943918238042D7670FD38625361DB@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-10_01:2011-03-09, 2011-03-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-1012030000 definitions=main-1103090191 Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 01:01:42 -0000 oops -- did not see your 'which' running or 'which' startup. does not compute. Clearly not supported by the standard. There are only 1 of each datastore type, except N of . Without a rewrite of the protocol, architecture, partial-lock, and every other protocol extension, there is no point adding support for multiple (candidate, running, startup) datastores. You can augment the notification with vendor leafs providing this information about a vendor feature. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Andy Bierman Sent: Wednesday, March 09, 2011 4:51 PM To: Kent Watsen; netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-0= 3.txt Hi, Events other than config-change (on your) list are out of scope. You can post a new I-D to the netmod WG I guess, proposing new work. Nits answered inline. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, March 09, 2011 1:44 PM To: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-0= 3.txt This I-D doesn't quite meet my needs and I'm wondering if it's because the = I-D's scope isn't broad enough or because the plan is to have a complementa= ry set of I-Ds fill in the void. To clarify, our current NMS application i= s interested in the following kinds of events: - FRU added/removed - Software added/removed - Configuration changed - Interface up/down I don't imagine every NMS to have the same interests and I even imagine our= s will have new interests over time (i.e. user/policy/license added/removed= , etc.). So this makes me wonder what the plan is to accommodate these oth= er events. Will we continually update this RFC or will we lets other RFCs = define their own events? For instance, a RFC for managing hardware defines= hardware-oriented notifications, a RFC for managing software defines softw= are-oriented notifications, etc. NITS ---- 1. the "netconf-config-change" description says "An edit record will be pre= sent for each distinct edit operation on the target datastore." How does = this relate to implicit changes? Can we be sure to indicate that the list = of "distinct edit operations" reflects the final state of the target datast= ore and not necessarily what was passed in ? [ab: the server is free to decide how to describe the edits that took place and how much detail is preserved. There is no canonical form of an edit defined.] 2. The description for modified-capability says "The new modified value of = the complete URI is returned", but the description for added-capability and= deleted-capability don't indicate if the complete or base URI are returned= . Assuming that it is intended that the complete uri is always returned, I= suggest that the description for the top-level netconf-capability-change s= ays that and we remove the word "complete" from the modified-capability des= cription (i.e. should now read "The new modified value of the URI is return= ed.") [ab: good point -- the full form of the URI is always given] 3. I'm still twisted about the "netconf-config-change" event not identifyin= g *which* startup/running datastore was modified. (i.e. Juniper's Dual REs= or Yuma's "--startup" parameter). Even though, as Martin points out, NetC= onf doesn't officially support more than one instance of a datastore and th= at a vendor-specific augmentation can be used, it's such a PITA. Or maybe,= to turn this around, should we now start defining an ability for NetConf t= o support more than one instance of datastores? [ab: the target-datastore enum says it is running or startup.] 4. missing "Acknowledgements" section [ab: OK] 5. s/parms/params/g ---or--- s/parms/parameters/g [ab: OK -- will use 2nd one] Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 6:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.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 System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datast= ores. However, client applications often need to be aware of common NETCON= F system events such as a change in NETCONF capabilities, which may impact = management applications. Standard mechanisms are needed to support the mon= itoring of the NETCONF system events within the NETCONF server. This docum= ent defines a YANG module which allows a NETCONF client to receive notifica= tions for some common events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion 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 randy_presuhn@mindspring.com Wed Mar 9 19:50:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697D43A6803; Wed, 9 Mar 2011 19:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 1dN0MF+bAs40; Wed, 9 Mar 2011 19:50:10 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 5FE4E3A67D6; Wed, 9 Mar 2011 19:50:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=obWFum/MLDrTDqhgggTrFnEIN9oZL4SUmVMh/U/DhdhXdak+FbqiXkCojDot2fpf; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PxWuK-0007UF-Ky; Wed, 09 Mar 2011 22:51:24 -0500 Message-ID: <002c01cbded6$7567dde0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Juergen Schoenwaelder" References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> Date: Wed, 9 Mar 2011 19:51:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb8285b063fc43658675c7184d2b4a2c2c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:50:12 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: "Phil Shafer" ; ; ; ; ; > Sent: Wednesday, March 09, 2011 12:34 PM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > On Wed, Mar 09, 2011 at 10:08:16AM -0800, Randy Presuhn wrote: > > > Since these things would need to be matched, I tried to find where the > > document spells out which normalization form is to be used. I couldn't. > > Did I miss something, or is the choice of normalization form left to the > > implementors' imaginations? > > makes an > interesting recommendation that applications should preserve input > code points, only normalizing strings to the application's preferred > normal form for internal use only... > > YANG does not force a normalization for the string type. It tries to > preserve them. Let me re-ask the question with an example. How are implementations required to treat the sequence U+0061 U+0308 and U+00E4 in user names? Are they identical, different, or is the answer implementation-specific? (Both are "ä".) Randy From j.schoenwaelder@jacobs-university.de Wed Mar 9 23:02:25 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F193A68C6; Wed, 9 Mar 2011 23:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 2u8XwYHksBHW; Wed, 9 Mar 2011 23:02:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8DC4C3A6984; Wed, 9 Mar 2011 23:02:19 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F31EC000A; Thu, 10 Mar 2011 08:03: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 3guR5bs--waD; Thu, 10 Mar 2011 08:03:35 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1E9EC0003; Thu, 10 Mar 2011 08:03:34 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id BD02F16E9DE9; Thu, 10 Mar 2011 08:03:06 +0100 (CET) Date: Thu, 10 Mar 2011 08:03:05 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Randy Presuhn , Phil Shafer , iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002c01cbded6$7567dde0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 10 Mar 2011 07:02:25 -0000 On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: > Let me re-ask the question with an example. > How are implementations required to treat the sequence > U+0061 U+0308 and U+00E4 in user names? Are they > identical, different, or is the answer implementation-specific? > (Both are "ä".) See why I avoid these characters. ;-) I see your point but whatever the answer is, it really needs to be answered for the YANG string data type. Right now, 4741bis does not really do anything with the user name, except requiring that transports provide one. I know, this is a rather poor excuse. Well, that said, there are of course protocol functions that do comparisons like the subtree filter. I guess we need to check what XPATH has to say about this - well xpath 2.0 provides normalization functions and requires NFC. Is there some sort of a guideline which normalization form is preferred in IETF standards? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tomoyuki.iijima.fg@hitachi.com Thu Mar 10 01:56:55 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136C63A68C4 for ; Thu, 10 Mar 2011 01:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-5TI5uL1+c1 for ; Thu, 10 Mar 2011 01:56:54 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id D08B33A689A for ; Thu, 10 Mar 2011 01:56:53 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 6871637AC4; Thu, 10 Mar 2011 18:58:10 +0900 (JST) Received: from mfilter3.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id p2A9w976030503; Thu, 10 Mar 2011 18:58:09 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter3.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2A9w8L7014325; Thu, 10 Mar 2011 18:58:09 +0900 X-AuditID: b753bd60-a274aba0000001d0-e1-4d78a0b04bd3 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 04E688B0311; Thu, 10 Mar 2011 18:58:08 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2A9vr118743420; Thu, 10 Mar 2011 18:57:53 +0900 Message-ID: <4D78A0A1.7050502@hitachi.com> Date: Thu, 10 Mar 2011 18:57:53 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> <4D7735EE.900@hitachi.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Netconf Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 10 Mar 2011 09:56:55 -0000 Dear Mehmet, > So, please summarize the main message of your draft in a > mail and initiate some discussion on the NETCONF maillist. Sure, I've pasted below the abstract of the I-D. This memo proposes transporting NETCONF Notification over WebSocket protocol[I-D.ietf-hybi-thewebsocketprotocol]. RFC5277[RFC5277] specifies that NETCONF Notification must be sent over SSH, BEEP, SSL and console from an NETCONF server to NETCONF clients. When NETCONF Notification was defined, this transport mapping was a reasonable decision. Bi-directional capability is necessary for transporting NETCONF Notification. But at present, WebSocket protocol, which is based on HTTP and has a bi-directional capability, is available. This memo describes the way in which NETCONF Notification is sent over WebSocket protocol. > You can also answer initial questions/comments from my > side: > - You copied a rather old figure from RFC5277. You should > use the figure of and refer to 4741bis. I understand. > - Why do you think an additional transport binding is > necessary? BEEP is also bi-directional. Yes, according to RFC4743, when exchanging NETCONF messages over SOAP/HTTP, a network device can send NETCONF Notification over SOAP/BEEP. To the best of my knowledge, however, BEEP is not widely adopted. And, preparing both HTTP and BEEP for NETCONF/SOAP is onerous. In contrast, WebSocket is expected to be used widely and is an extension of HTTP. > - NETCONF exchanges XML documents with RPC commands. > I am missing some examples and explanation how you do > this on top of Websocket transport. WebSocket is under development. So there might be some wiggle room. If specification of the current WebSocket I-D is unchanged, XML documents with RPC commands such as and written in RFC5277 should be put in application data in the figure of the following I-D. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-4.3 Kind regards, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Tomoyuki, > > the co-chairs would like to see the WG interest first > before allocating scarce session time. > > So, please summarize the main message of your draft in a > mail and initiate some discussion on the NETCONF maillist. > > You can also answer initial questions/comments from my > side: > - You copied a rather old figure from RFC5277. You should > use the figure of and refer to 4741bis. > - Why do you think an additional transport binding is > necessary? BEEP is also bi-directional. > - NETCONF exchanges XML documents with RPC commands. > I am missing some examples and explanation how you do > this on top of Websocket transport. > > Mehmet > > >> -----Original Message----- >> From: ext Tomoyuki Iijima [mailto:tomoyuki.iijima.fg@hitachi.com] >> Sent: Wednesday, March 09, 2011 9:10 AM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 >> >> Dear WG chairs, >> >> > Open mike: >> > Possible topics: >> > - (if necessary) Discussion on NETCONF username >> > - Improved NACM rule specification, features/requirements M. >> > Bjorklund/A. Bierman >> > >> > Any other topics to discuss? >> >> I've submitted following draft. I'd appreciate it if you could put > this >> topic on the agenda if time is available. I'm considering sending >> Netconf Notification over WebSocket(Bi-directional HTTP). I suppose >> this >> topic hasn't been discussed yet... >> >> http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps-00 >> >> Kind regards, >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear NETCONF WG, >>> >>> below is a draft agenda for the NETCONF session in Prague. >>> Please send us your comments/requests by March 16, 2011. >>> >>> Mehmet & Bert >>> >>> >>> (DRAFT) Agenda for NETCONF WG Session >>> ------------------------------------- >>> >>> IETF 80 - Prague, Czech Republic >>> March 27 - April 1, 2011 >>> >>> THURSDAY, March 31, 2011 >>> 1300-1500 Afternoon Session I >>> Room Barcelona >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. Status of 4741bis and 4742bis (5 minutes - M. Bjorklund/M. >>> Wassermann) >>> 2. Network Configuration Protocol Access Control Model - A. >>> Bierman (40 minutes) >>> > http://tools.ietf.org/html/draft-ietf-netconf-access-control >>> 3. NETCONF System Notifications - A. Bierman (30 minutes) >>> draft-ietf-netconf-system-notification >>> >>> http://tools.ietf.org/html/draft-ietf-netconf-system-notification >>> >>> Open mike: >>> Possible topics: >>> - (if necessary) Discussion on NETCONF username >>> - Improved NACM rule specification, features/requirements M. >>> Bjorklund/A. Bierman >>> >>> Any other topics to discuss? >>> >>> AOB >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> . -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory TEL: 045-860-2156 (ext. 874-6059) E-mail: tomoyuki.iijima.fg@hitachi.com From j.schoenwaelder@jacobs-university.de Thu Mar 10 04:01:06 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5193A6A5F for ; Thu, 10 Mar 2011 04:01:06 -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 bf1tW-p4BENk for ; Thu, 10 Mar 2011 04:01:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 144313A6A1E for ; Thu, 10 Mar 2011 04:01:02 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A90CC002F; Thu, 10 Mar 2011 13:02:20 +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 h07s3Wk-1tbH; Thu, 10 Mar 2011 13:02:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357B2C0025; Thu, 10 Mar 2011 13:02:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 974B216EA967; Thu, 10 Mar 2011 13:02:12 +0100 (CET) Date: Thu, 10 Mar 2011 13:02:12 +0100 From: Juergen Schoenwaelder To: Tomoyuki Iijima Message-ID: <20110310120212.GB45896@elstar.local> Mail-Followup-To: Tomoyuki Iijima , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> <4D7735EE.900@hitachi.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> <4D78A0A1.7050502@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D78A0A1.7050502@hitachi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 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, 10 Mar 2011 12:01:06 -0000 On Thu, Mar 10, 2011 at 06:57:53PM +0900, Tomoyuki Iijima wrote: > > - Why do you think an additional transport binding is > > necessary? BEEP is also bi-directional. > > Yes, according to RFC4743, when exchanging NETCONF messages over > SOAP/HTTP, a network device can send NETCONF Notification over > SOAP/BEEP. To the best of my knowledge, however, BEEP is not widely > adopted. And, preparing both HTTP and BEEP for NETCONF/SOAP is > onerous. In contrast, WebSocket is expected to be used widely and is > an extension of HTTP. Every standards-track transport causes maintenance costs. Instead of working on another transport for an "expected to be used widely" protocol, I would rather spent time discussing whether some of the existing standards-track transports should be made experimental or historic. OK, I see that your I-D claims "Intended status: Informational" but this sounds more like Experimental to me. That said, I am somewhat concerned about the idea to create a transport that can only handle a certain type of NETCONF messages. This seems the wrong approach to me. Perhaps the goal should rather be to declare NETCONF/SOAP historic and replace it with an Experimental WebSocket transport. ;-) /js (who is not making friends today) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Mar 10 04:31:59 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4793D3A6924 for ; Thu, 10 Mar 2011 04:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 tms510DIztyu for ; Thu, 10 Mar 2011 04:31:58 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id AA65C3A691D for ; Thu, 10 Mar 2011 04:31:57 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pxf3I-0003QP-1B for netconf@ietf.org; Thu, 10 Mar 2011 13:33:13 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pxf3H-0007n8-5T for netconf@ietf.org; Thu, 10 Mar 2011 13:33:11 +0100 Message-ID: <4D78C507.1060906@bwijnen.net> Date: Thu, 10 Mar 2011 13:33:11 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: netconf References: <4CD64A16.3090408@bwijnen.net> In-Reply-To: <4CD64A16.3090408@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41f9bceacd210d0ca05e8dc58c572d02d Subject: [Netconf] Review of: draft-ietf-netconf-access-control-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: Thu, 10 Mar 2011 12:31:59 -0000 I would like to encourage all WG participants to review and comment on draft-ietf-netconf-access-control-02.txt. If you can do so (well) before our meeting in Prague, then the editor(s)/author(s) have time to construct a list of open issues (if any) and prepare answers or proposal on how to address the issues. We can then make better progress in Prague. Here are a first few comments from me. It seems most of my initial comments on revision 01 have been addressed. But 7. sect 3.4 page 10 speaks about databases. I think it is better to use datastores here, is it not? has been addressed in the text. But the YANG module still uses database in most places. Is that intentional? The following 2 comments did not cause change in the doc. That may be fine, but can you then comment/answer: 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? Thanks, Bert On 11/7/10 7:41 AM, Bert (IETF) Wijnen wrote: > 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 bwijnen@ripe.net Thu Mar 10 06:34:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4FC3A69D7 for ; Thu, 10 Mar 2011 06:34:33 -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 09iRiGk7vdJ8 for ; Thu, 10 Mar 2011 06:34:32 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 098F63A69D3 for ; Thu, 10 Mar 2011 06:34:32 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PxgxB-0000uB-D1 for netconf@ietf.org; Thu, 10 Mar 2011 15:35:49 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PxgxB-0001U4-9k for netconf@ietf.org; Thu, 10 Mar 2011 15:35:01 +0100 Message-ID: <4D78E195.6040504@ripe.net> Date: Thu, 10 Mar 2011 15:35:01 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -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: 5ef2bffdfa2294c21c35da1b4f77885e8c128eae8b41c8e3ebd828474eed34c9 Subject: [Netconf] nacm extensions in draft-ietf-netconf-access-control-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: Thu, 10 Mar 2011 14:34:33 -0000 Here is one of them: extension secure { description "Used to indicate that the data model node represents a sensitive security system parameter. If present, the NETCONF server will only allow the designated 'superuser' to have write or execute default nacm-rights-type for the node. An explicit access control rule is required for all other users. The 'secure' extension may appear within a data, rpc, or notification node definition. It is ignored otherwise."; } The 2nd para is conflicting with what I see in sect 3.3.5, where the first bullet says: 1. If the parameter is set to 'false', then the data node access request is permitted. And I believe that I read someplace else in the document that also at the very first start, there may be no NACM config defined yet. Bert From mehmet.ersue@nsn.com Thu Mar 10 06:34:47 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15533A69F5 for ; Thu, 10 Mar 2011 06:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNHmq67e629h for ; Thu, 10 Mar 2011 06:34:46 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1D9F03A69D7 for ; Thu, 10 Mar 2011 06:34:45 -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 p2AEa1WX015132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2011 15:36:01 +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 p2AEZxt1007506; Thu, 10 Mar 2011 15:36:01 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 15:36:01 +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: Thu, 10 Mar 2011 15:36:00 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110309.220955.117242983.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: AcvenmEb5fK9zZW2RlKkEDISCx1q4wAkXfVA References: <20110309.170234.199713540.mbj@tail-f.com><20110309202555.GA43502@elstar.local><795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Mar 2011 14:36:01.0247 (UTC) FILETIME=[7A3D8EF0:01CBDF30] Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:34:47 -0000 Does it sound correct if 4741bis says: "The algorithm used to derive the username is transport protocol specific" and 4742bis says: "How the NETCONF Server extracts the user name from the SSH layer is implementation-dependent. " ? How can NETCONF SSH transport can . . . "explain how a NETCONF username is derived from the authentication=20 mechanisms supported by the transport protocol." ? Mehmet=20 PS: I think we don't need to put IESG always on CC. > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Martin Bjorklund > Sent: Wednesday, March 09, 2011 10:10 PM > To: ietfdbh@comcast.net > Cc: netconf@ietf.org; draft-ietf-netconf-4741bis@tools.ietf.org; > netconf-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) >=20 > Hi David, >=20 > "David Harrington" wrote: > > Hi, > > > > The crux of my discuss for 4741bis is that the netconf username will > > be used by other things, such as CLIs, scripts, YANG, etc. and should > > be in a format compatible with expected usage. > > Expected usage appears to include embedding in XML documents, YANG > > data models, native CLI handling, and matching (such as during lookup > > in an access control system, whether proprietary or standardized). >=20 > Agreed. >=20 > > I don't care whether the format of the netconf username is compatible > > with section 2.2 of the XML specification, or with RFC 6020's string > > data type, or ascii, or some other choice of the WG (although I > > recommend using something standardized). > > > > The (implicit) expectation should be made explicit in documentation > > (and I think 4741bis makes the most sense to define the expected > > format of a netconf username). >=20 > Would the following change resolve your DISCUSS? >=20 > I suggest we add a sentence: >=20 > The username is a string of characters that match the "Char" > production from section 2.2 of [1]. >=20 > OLD: >=20 > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The algorithm used to derive the username is > transport protocol specific and in addition specific to the > authentication mechanism used by the transport protocol. NETCONF > transport protocols therefore MUST explain how a NETCONF username is > derived from the authentication mechanisms supported by the > transport > protocol. >=20 > NEW: >=20 > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The username is a string of characters that > match the "Char" production from section 2.2 of [1]. The algorithm > used to derive the username is transport protocol specific and in > addition specific to the authentication mechanism used by the > transport protocol. NETCONF transport protocols therefore MUST > explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol. >=20 >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Thu Mar 10 06:45:01 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F352F3A69F4 for ; Thu, 10 Mar 2011 06:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 BQ3JAmw5UDUq for ; Thu, 10 Mar 2011 06:44:59 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 392403A69C2 for ; Thu, 10 Mar 2011 06:44:59 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pxh82-0001Rw-2B; Thu, 10 Mar 2011 15:46:16 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pxh81-0002QM-Tk; Thu, 10 Mar 2011 15:46:13 +0100 Message-ID: <4D78E435.1070308@bwijnen.net> Date: Thu, 10 Mar 2011 15:46:13 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <20110309.170234.199713540.mbj@tail-f.com><20110309202555.GA43502@elstar.local><795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd419cd6c53a57d4b9d81f9fd78fef2800f Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:45:01 -0000 But this way... it may take a long time before DBH sees it. At least we need to copy him explicitly. Adding IESG too creates an extra chance that he sees it. Bert On 3/10/11 3:36 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Does it sound correct if 4741bis says: > "The algorithm used to derive the username is transport protocol > specific" > > and 4742bis says: > "How the NETCONF Server extracts the user name from the SSH layer is > implementation-dependent. " ? > > How can NETCONF SSH transport can . . . > > "explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol." ? > > Mehmet > > PS: I think we don't need to put IESG always on CC. > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of ext Martin Bjorklund >> Sent: Wednesday, March 09, 2011 10:10 PM >> To: ietfdbh@comcast.net >> Cc: netconf@ietf.org; draft-ietf-netconf-4741bis@tools.ietf.org; >> netconf-chairs@tools.ietf.org; iesg@ietf.org >> Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- >> netconf-4741bis-09: (with DISCUSS and COMMENT) >> >> Hi David, >> >> "David Harrington" wrote: >>> Hi, >>> >>> The crux of my discuss for 4741bis is that the netconf username will >>> be used by other things, such as CLIs, scripts, YANG, etc. and > should >>> be in a format compatible with expected usage. >>> Expected usage appears to include embedding in XML documents, YANG >>> data models, native CLI handling, and matching (such as during > lookup >>> in an access control system, whether proprietary or standardized). >> Agreed. >> >>> I don't care whether the format of the netconf username is > compatible >>> with section 2.2 of the XML specification, or with RFC 6020's string >>> data type, or ascii, or some other choice of the WG (although I >>> recommend using something standardized). >>> >>> The (implicit) expectation should be made explicit in documentation >>> (and I think 4741bis makes the most sense to define the expected >>> format of a netconf username). >> Would the following change resolve your DISCUSS? >> >> I suggest we add a sentence: >> >> The username is a string of characters that match the "Char" >> production from section 2.2 of [1]. >> >> OLD: >> >> The authentication process MUST result in an authenticated client >> identity whose permissions are known to the server. The >> authenticated identity of a client is commonly referred to as the >> NETCONF username. The algorithm used to derive the username is >> transport protocol specific and in addition specific to the >> authentication mechanism used by the transport protocol. NETCONF >> transport protocols therefore MUST explain how a NETCONF username > is >> derived from the authentication mechanisms supported by the >> transport >> protocol. >> >> NEW: >> >> The authentication process MUST result in an authenticated client >> identity whose permissions are known to the server. The >> authenticated identity of a client is commonly referred to as the >> NETCONF username. The username is a string of characters that >> match the "Char" production from section 2.2 of [1]. The algorithm >> used to derive the username is transport protocol specific and in >> addition specific to the authentication mechanism used by the >> transport protocol. NETCONF transport protocols therefore MUST >> explain how a NETCONF username is derived from the authentication >> mechanisms supported by the transport protocol. >> >> >> >> /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 j.schoenwaelder@jacobs-university.de Thu Mar 10 07:39:41 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0393A69E6 for ; Thu, 10 Mar 2011 07:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 b2JTbun7A4tI for ; Thu, 10 Mar 2011 07:39:40 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B3FB3A69CC for ; Thu, 10 Mar 2011 07:39:40 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79608C0032; Thu, 10 Mar 2011 16:40:57 +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 aIHaoRfzQY2c; Thu, 10 Mar 2011 16:40: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 6132CC0026; Thu, 10 Mar 2011 16:40:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B9FA16EB434; Thu, 10 Mar 2011 16:40:48 +0100 (CET) Date: Thu, 10 Mar 2011 16:40:48 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20110310154048.GA46792@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , netconf@ietf.org References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 10 Mar 2011 15:39:41 -0000 On Thu, Mar 10, 2011 at 03:36:00PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Does it sound correct if 4741bis says: > "The algorithm used to derive the username is transport protocol > specific" > > and 4742bis says: > "How the NETCONF Server extracts the user name from the SSH layer is > implementation-dependent. " ? > > How can NETCONF SSH transport can . . . > > "explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol." ? 4741bis says a NETCONF transport must provide a username. I think this is about all 4741bis can do (plus the addition to say that usernames must be XML representable, but there is text in the making for this so lets consider this point addressed). With SSH, what typically happens, is that you (a) run a certain authentication protocol within SSH that may (b) interface with external AAA services and that typically (c) results into a notion of a system account and the username NETCONF implementations pick is likely the notion of a system account (or system "user") than the identity used in the SSH authentication protocol. While for many case the step from (a) to (b) and from (b) to (c) is an identity transform, this does not necessarily have to be this way. This was the core of the discussion of one of the IETF meetings. The intention of 4742bis (at least as I understand things) is to say the NETCONF transport picks the username from whatever is the result of (c) or (b) if step (c) does not exist or (a) if steps (b) and (b) do not exist. Is this is a reasonable description of 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 mbj@tail-f.com Thu Mar 10 09:30:34 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902A53A6B31 for ; Thu, 10 Mar 2011 09:30:34 -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 AtAtjaJoNCd6 for ; Thu, 10 Mar 2011 09:30:33 -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 9CEBB3A6A3B for ; Thu, 10 Mar 2011 09:30:33 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5799776C316; Thu, 10 Mar 2011 18:31:50 +0100 (CET) Date: Thu, 10 Mar 2011 18:31:48 +0100 (CET) Message-Id: <20110310.183148.238754710.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4D78C507.1060906@bwijnen.net> References: <4CD64A16.3090408@bwijnen.net> <4D78C507.1060906@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] Review of: draft-ietf-netconf-access-control-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: Thu, 10 Mar 2011 17:30:34 -0000 Hi, "Bert (IETF) Wijnen" wrote: > 7. sect 3.4 page 10 > speaks about databases. I think it is better to use datastores > here, is it not? > > has been addressed in the text. But the YANG module still uses > database in most places. Is that intentional? No, we will fix that. > The following 2 comments did not cause change in the doc. The second comment actually did cause a change in the doc. > That may be fine, but can you then comment/answer: > 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? Yes. > Are we implicitly saying that YANG is incomplete in this aspect? Not really; YANG has an extension mechanism which is designed to be used in situations like this. NACM is using that mechanism and defines two extension statements. > 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? Actually, the new text in -02 says: A client MUST always be authorized to receive the and notification events, defined in [RFC5277] I hope this is clearer than the old text. /martin From mehmet.ersue@nsn.com Thu Mar 10 09:55:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1173A68EE for ; Thu, 10 Mar 2011 09:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0A6rOS6j9gR for ; Thu, 10 Mar 2011 09:55:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D7E663A68CC for ; Thu, 10 Mar 2011 09:55:24 -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 p2AHufHW021528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2011 18:56:41 +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 p2AHufxl000539; Thu, 10 Mar 2011 18:56:41 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 18:56:41 +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: Thu, 10 Mar 2011 18:56:39 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110310154048.GA46792@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: AcvfOY6hP9qyeKbdRO+ju1VmhGrZyQAEUNFw References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> <20110310154048.GA46792@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Mar 2011 17:56:41.0484 (UTC) FILETIME=[82C7ECC0:01CBDF4C] Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:55:26 -0000 Juergen, > Is this is a reasonable description of the situation? It is at least the way you interpret it from the pov. of=20 an implementer. > NETCONF transport protocols therefore MUST > explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol. However, I don't think it is a good idea to say that the=20 "SSH transport MUST explain how a NETCONF username is derived=20 from the authentication mechanisms." This is a very hard "MUST" which SSH transport specification=20 cannot provide.=20 The only thing SSH transport specification does say is: "How the NETCONF Server extracts the user name from the SSH layer is implementation-dependent." What SSH transport document could say is e.g. (but not much more): " There is no standard way for an application running on an SSH server to determine a user name for the current session. How the NETCONF Server extracts the user name from the SSH layer is therefore implementation-dependent.=20 The user name provided by the SSH implementation will be made=20 available to NETCONF message layer as NETCONF username without=20 any modification. Any transformations applied to the authenticated=20 user name by the SSH layer are outside the scope of this document." However this would be insufficient with the MUST statement in 4741bis=20 above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis=20 cannot provide. Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, March 10, 2011 4:41 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: ext Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) >=20 > On Thu, Mar 10, 2011 at 03:36:00PM +0100, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > Does it sound correct if 4741bis says: > > "The algorithm used to derive the username is transport protocol > > specific" > > > > and 4742bis says: > > "How the NETCONF Server extracts the user name from the SSH layer is > > implementation-dependent. " ? > > > > How can NETCONF SSH transport can . . . > > > > "explain how a NETCONF username is derived from the authentication > > mechanisms supported by the transport protocol." ? >=20 > 4741bis says a NETCONF transport must provide a username. I think this > is about all 4741bis can do (plus the addition to say that usernames > must be XML representable, but there is text in the making for this so > lets consider this point addressed). >=20 > With SSH, what typically happens, is that you >=20 > (a) run a certain authentication protocol within SSH that may > (b) interface with external AAA services and that typically > (c) results into a notion of a system account >=20 > and the username NETCONF implementations pick is likely the notion of > a system account (or system "user") than the identity used in the SSH > authentication protocol. While for many case the step from (a) to (b) > and from (b) to (c) is an identity transform, this does not > necessarily have to be this way. This was the core of the discussion > of one of the IETF meetings. >=20 > The intention of 4742bis (at least as I understand things) is to say > the NETCONF transport picks the username from whatever is the result > of (c) or (b) if step (c) does not exist or (a) if steps (b) and (b) > do not exist. >=20 > Is this is a reasonable description of the situation? >=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 bertietf@bwijnen.net Thu Mar 10 10:12:58 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1BA3A68F1 for ; Thu, 10 Mar 2011 10:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.485 X-Spam-Level: X-Spam-Status: No, score=-100.485 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlvCniLgvOUq for ; Thu, 10 Mar 2011 10:12:57 -0800 (PST) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id 8A5B53A68CB for ; Thu, 10 Mar 2011 10:12:56 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PxkNJ-0002GT-UI; Thu, 10 Mar 2011 19:14:14 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <4CD64A16.3090408@bwijnen.net><4D78C507.1060906@bwijnen.net> <20110310.183148.238754710.mbj@tail-f.com> In-Reply-To: <20110310.183148.238754710.mbj@tail-f.com> Date: Thu, 10 Mar 2011 19:14:13 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of: draft-ietf-netconf-access-control-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: Thu, 10 Mar 2011 18:12:58 -0000 OK. Thanks Martin. Bert ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, March 10, 2011 6:31 PM Subject: Re: [Netconf] Review of: draft-ietf-netconf-access-control-02.txt > Hi, > > "Bert (IETF) Wijnen" wrote: >> 7. sect 3.4 page 10 >> speaks about databases. I think it is better to use datastores >> here, is it not? >> >> has been addressed in the text. But the YANG module still uses >> database in most places. Is that intentional? > > No, we will fix that. > >> The following 2 comments did not cause change in the doc. > > The second comment actually did cause a change in the doc. > >> That may be fine, but can you then comment/answer: >> 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? > > Yes. > >> Are we implicitly saying that YANG is incomplete in this aspect? > > Not really; YANG has an extension mechanism which is designed to be > used in situations like this. NACM is using that mechanism and > defines two extension statements. > >> 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? > > Actually, the new text in -02 says: > > A client MUST always be authorized to receive the > and notification events, defined in [RFC5277] > > I hope this is clearer than the old text. > > > /martin From j.schoenwaelder@jacobs-university.de Thu Mar 10 10:31:55 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF413A68F5 for ; Thu, 10 Mar 2011 10:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 fZQnXcxb17ui for ; Thu, 10 Mar 2011 10:31:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C7E73A67EE for ; Thu, 10 Mar 2011 10:31:53 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D4A6C0032; Thu, 10 Mar 2011 19:33: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 C-L+gGaY3aF0; Thu, 10 Mar 2011 19:33: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 6A0ECC001E; Thu, 10 Mar 2011 19:33:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6E24C16EB91A; Thu, 10 Mar 2011 19:33:04 +0100 (CET) Date: Thu, 10 Mar 2011 19:33:03 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20110310183303.GA47066@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Martin Bjorklund , netconf@ietf.org References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> <20110310154048.GA46792@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 10 Mar 2011 18:31:55 -0000 On Thu, Mar 10, 2011 at 06:56:39PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Juergen, > > > Is this is a reasonable description of the situation? > > It is at least the way you interpret it from the pov. of > an implementer. > > > NETCONF transport protocols therefore MUST > > explain how a NETCONF username is derived from the authentication > > mechanisms supported by the transport protocol. > > However, I don't think it is a good idea to say that the > "SSH transport MUST explain how a NETCONF username is derived > from the authentication mechanisms." > > This is a very hard "MUST" which SSH transport specification > cannot provide. > > The only thing SSH transport specification does say is: > "How the NETCONF Server extracts the user name from the SSH layer is > implementation-dependent." > > What SSH transport document could say is e.g. (but not much more): > > " There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. > > The user name provided by the SSH implementation will be made > available to NETCONF message layer as NETCONF username without > any modification. Any transformations applied to the authenticated > user name by the SSH layer are outside the scope of this document." > > However this would be insufficient with the MUST statement in 4741bis > above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis > cannot provide. I give up. I meanwhile do not know anymore what the text says since I fail to be able to track which changes have been agreed and which ones not. I maintain the statement that a NETCONF transport that does not provide a username is unacceptable - or we give up on access control. The issue is also not that SSH does not provide a username - the issue is that documenting exactly how this is done without restricting SSH authentication protocols and/or AAA systems is difficult. Since the easy way forward of declaring this implementation dependent does not seem to fly, someone has to cast creative text that says a bit more than "this implementation dependent" without saying too much. This is what we should discuss, not the MUST provide username requirement in 4741bis. /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 Thu Mar 10 10:55:10 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B4F3A6923 for ; Thu, 10 Mar 2011 10:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.148, 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 YBePTL0L8Noi for ; Thu, 10 Mar 2011 10:55:09 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 72B383A68EA for ; Thu, 10 Mar 2011 10:55:09 -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 p2AIlg6h030656; Thu, 10 Mar 2011 10:56:26 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id uy1nfg4wj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Mar 2011 10:56:26 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Mar 2011 10:59:01 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 10 Mar 2011 10:56:25 -0800 From: Andy Bierman To: Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" Date: Thu, 10 Mar 2011 10:56:24 -0800 Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: AcvfUa8Z38lGe/lcQkigoC1TMKiEVQAAKhXw Message-ID: References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> <20110310154048.GA46792@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@elstar.local> In-Reply-To: <20110310183303.GA47066@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=2011-03-10_09:2011-03-10, 2011-03-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-1012030000 definitions=main-1103100131 Cc: "netconf@ietf.org" Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:55:10 -0000 Hi, I agree with Juergen that 4741bis (and even 4742bis) does not need to define exactly how a user-name must be derived from each transport layer that NETCONF uses. The specific user name values are not relevant to the monitoring or NACM modules. Operators will need to be familiar with the user name details within their own network, but they control the creation of user accounts. IMO, this is a site-specific detail, outside the scope of the=20 combination of protocols in use. There are lots of site-specific details outside the scope of NETCONF and SSH standards (like server configuration). It seems like SSH should define properties it exports to higher layers, such as a user name. Having NETCONF define how SSH must work does not seem right. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Thursday, March 10, 2011 10:33 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-474= 1bis-09: (with DISCUSS and COMMENT) On Thu, Mar 10, 2011 at 06:56:39PM +0100, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Juergen, >=20 > > Is this is a reasonable description of the situation? >=20 > It is at least the way you interpret it from the pov. of=20 > an implementer. >=20 > > NETCONF transport protocols therefore MUST > > explain how a NETCONF username is derived from the authentication > > mechanisms supported by the transport protocol. >=20 > However, I don't think it is a good idea to say that the=20 > "SSH transport MUST explain how a NETCONF username is derived=20 > from the authentication mechanisms." >=20 > This is a very hard "MUST" which SSH transport specification=20 > cannot provide.=20 >=20 > The only thing SSH transport specification does say is: > "How the NETCONF Server extracts the user name from the SSH layer is > implementation-dependent." >=20 > What SSH transport document could say is e.g. (but not much more): >=20 > " There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent.=20 >=20 > The user name provided by the SSH implementation will be made=20 > available to NETCONF message layer as NETCONF username without=20 > any modification. Any transformations applied to the authenticated=20 > user name by the SSH layer are outside the scope of this document." >=20 > However this would be insufficient with the MUST statement in 4741bis=20 > above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis=20 > cannot provide. I give up. I meanwhile do not know anymore what the text says since I fail to be able to track which changes have been agreed and which ones not. I maintain the statement that a NETCONF transport that does not provide a username is unacceptable - or we give up on access control. The issue is also not that SSH does not provide a username - the issue is that documenting exactly how this is done without restricting SSH authentication protocols and/or AAA systems is difficult. Since the easy way forward of declaring this implementation dependent does not seem to fly, someone has to cast creative text that says a bit more than "this implementation dependent" without saying too much. This is what we should discuss, not the MUST provide username requirement in 4741bis. /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 randy_presuhn@mindspring.com Thu Mar 10 11:00:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6773A698D for ; Thu, 10 Mar 2011 11:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 afzkKeQ-sVgz for ; Thu, 10 Mar 2011 11:00:06 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id B92073A6923 for ; Thu, 10 Mar 2011 11:00:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=h8Ba9XVbBZhLUD5+q8rrP0jVNv+9anxQjpA7+px6hXzvXy0OtNrfZcyyo7F/zO/6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Pxl6x-0005WR-Jk for netconf@ietf.org; Thu, 10 Mar 2011 14:01:23 -0500 Message-ID: <006301cbdf55$9800e200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110309.170234.199713540.mbj@tail-f.com><20110309202555.GA43502@elstar.local><795EF5C74EF246A593C43298AA44C877@davidPC><20110309.220955.117242983.mbj@tail-f.com><80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net><20110310154048.GA46792@elstar.local><80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@elstar.local> Date: Thu, 10 Mar 2011 11:01:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfbf0d9b7520a02a94827ffc9877678aeb1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:00:07 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: > Sent: Thursday, March 10, 2011 10:33 AM > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > > "How the NETCONF Server extracts the user name from the SSH layer is > > implementation-dependent." > > > > What SSH transport document could say is e.g. (but not much more): > > > > " There is no standard way for an application running on an SSH > > server to determine a user name for the current session. How the > > NETCONF Server extracts the user name from the SSH layer is > > therefore implementation-dependent. > > > > The user name provided by the SSH implementation will be made > > available to NETCONF message layer as NETCONF username without > > any modification. Any transformations applied to the authenticated > > user name by the SSH layer are outside the scope of this document." > > > > However this would be insufficient with the MUST statement in 4741bis > > above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis > > cannot provide Let's get real. Even though "implementation-dependent" isn't the most satisfying way of describing how something happens, there are times (and this is probably one) where it's the only reasonable way, unless one is willing to accept that any effort to further specify matters will almost inevitably end up over-constraining implementations. ... > I maintain the statement that a NETCONF transport that does not > provide a username is unacceptable - or we give up on access > control. Agreed. "Implementation-dependent" may be distasteful, but the alternative of abandoning access control would be throwing the baby out with the bathwater. > The issue is also not that SSH does not provide a username - > the issue is that documenting exactly how this is done without > restricting SSH authentication protocols and/or AAA systems is > difficult. Since the easy way forward of declaring this implementation > dependent does not seem to fly, someone has to cast creative text that > says a bit more than "this implementation dependent" without saying > too much. This is what we should discuss, not the MUST provide > username requirement in 4741bis. I agree that the username requirement is not what should be under discussion. I reluctantly agree that if this group is unwilling to let the implementation-dependent sleeping dog lie, the only alternative is to spell out and get agreement on the "blessed" set of implementation- dependent things that might be done to produce a username. And I strongly agree that that exercise will need to take care not to say too much - an over-specification here could cause as much trouble as the under-specification that caused the mess in the first place. Randy From muthu@cisco.com Thu Mar 10 12:08:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921233A680F; Thu, 10 Mar 2011 12:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNOrthqsXXqJ; Thu, 10 Mar 2011 12:08:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5477B3A67FF; Thu, 10 Mar 2011 12:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=muthu@cisco.com; l=4946; q=dns/txt; s=iport; t=1299787761; x=1300997361; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kELMz9wHMMc5m5/giy9RIPW0CQNHhZc7m1gCG384oik=; b=VSJP96/KaTc6PTL9SOw0IcGzgmspL8QPkuB3z3clRFcDv70UBCOIbAuk XgL6RFcSww7GmvBf5sxA+GVV119HAgKAlb8SzWi4nLu+e8fhUpOzZCkK9 tes3anjYIjeCR5C1VMokhOgaIyLrxJn1Z9U7FDZyqlwbICNPnmheOlvYR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBADO+eE2rRN+K/2dsb2JhbACYX41Sd6UinDKFYgSFJIpv X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208";a="343911877" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2011 20:09:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p2AK9LSG017244; Thu, 10 Mar 2011 20:09:21 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 12:09:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 12:09:19 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] I-DAction:draft-ietf-netconf-system-notifications-03.txt Thread-Index: Acvd5yTf8HgJxyQ6SReC43ao+dhcWwAxuDfAAAPOoXAAJ4JEoA== References: <20110308231501.17204.46756.idtracker@localhost> From: "Muthumayan Madhayyan (muthu)" To: "Andy Bierman" , , X-OriginalArrivalTime: 10 Mar 2011 20:09:21.0491 (UTC) FILETIME=[0B509A30:01CBDF5F] Cc: netconf@ietf.org Subject: Re: [Netconf] I-DAction:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:08:04 -0000 Hi Andy, Please see inline:=20 -----Original Message----- From: Andy Bierman [mailto:biermana@Brocade.com]=20 Sent: Wednesday, March 09, 2011 4:58 PM To: Muthumayan Madhayyan (muthu); Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: netconf@ietf.org Subject: RE: [Netconf] I-DAction:draft-ietf-netconf-system-notifications-03.txt Hi, answers inline. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Muthumayan Madhayyan (muthu) Sent: Wednesday, March 09, 2011 3:31 PM To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt Hi: 1. In netconf-config-change notification, there is a list element called 'edit'. Is that really meant to be a list ? Is so, what is the key for this list ? Also where is the type instance-identifier defined (would that be in ietf-netconf ?). I presume that the motivation for sending this instance information is for the NMS to do a partial retrieval of config ? [ab: a config-false list does not need a key. The server is free to retain and report as much detail as it wants. [muthu > ] OK.=20 E.g. Add to candidate: merge new /mylist[id=3D1] entry merge new /mylist[id=3D2] entry Then . A server may report this as 1 merge on /mylist or 2 merges (1 on /mylist[id=3D1] and 1 on /mylist[id=3D2]).] [muthu > ] Wouldn't it make sense to send some sort of identifier that tags every commit operation (commit-id) ? If the NMS ever loses connectivity with the server and regains connectivity later, it can chose to sync up based on the commit-id.=20 [muthu > ] Were you planning on defining the typedef instance-identifier in this YANG module ? 2. Seems like the netconf-session-start and netconf-session-end is primarily meant to track netconf user sessions. The prefix netconf-session-* and the use of netconf specific enumerations like 'bad-hello' etc. seems to suggest that. However, the session-id in common-session-parms seems to suggest that this notification can be sent for non-NETCONF sessions as well. If so, some of the enumerations for termination-reason don't really make sense. Would it help to state that non-NETCONF terminations would be tracked under 'other' enum ? [ab: I can add a note stating that non-NETCONF sessions are terminated as 'other'.] [muthu > ] Ok. 3. In the grouping changed-by-parms, one of the choice is 'server'. What is the use case where server can initiate a configuration change without user intervention ?=20 [ab: a server may create config as a result of hardware change, on initially when a fresh running config is created as the factory default config. The server may get some OOB request to add a new VLAN for example, and could create non-default config.] [muthu > ] The factory default config makes sense. The OOB request I presume is still a user request, coming in from some other manageability interface (snmp perhaps?) - so shouldn't that be just considered non-NETCONF config user request. In any case, there is a use-case for 'server' triggered configuration change. Thanks, - muthu -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 08, 2011 3:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol System Notifications Author(s) : A. Bierman Filename : draft-ietf-netconf-system-notifications-03.txt Pages : 13 Date : 2011-03-08 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common NETCONF system events such as a change in NETCONF capabilities, which may impact management applications. Standard mechanisms are needed to support the monitoring of the NETCONF system 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-notificati ons-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Thu Mar 10 12:25:05 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8223A699C for ; Thu, 10 Mar 2011 12:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rODpZL6TE49o for ; Thu, 10 Mar 2011 12:25:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3AED33A6945 for ; Thu, 10 Mar 2011 12:25:03 -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 p2AKQFJY002263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2011 21:26:15 +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 p2AKQE4w026570; Thu, 10 Mar 2011 21:26:14 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 21:26:14 +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: Thu, 10 Mar 2011 21:26:12 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C0B336@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110310183303.GA47066@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: AcvfUZ1oYwXjm3l5SXufMNt/DcMakwAAg3VA References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> <20110310154048.GA46792@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Mar 2011 20:26:14.0140 (UTC) FILETIME=[66E693C0:01CBDF61] Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:25:05 -0000 Hi Juergen, we are all trying to get the two bis drafts one step further. > I maintain the statement that a NETCONF transport that does not > provide a username is unacceptable - or we give up on access control.=20 Nobody said it shouldn't. > The issue is also not that SSH does not provide a username - > the issue is that documenting exactly how this is done without > restricting SSH authentication protocols and/or AAA systems is > difficult.=20 Yes, it is difficult to describe what SSH transport is not aware=20 of.=20 > Since the easy way forward of declaring this implementation > dependent does not seem to fly, someone has to cast creative=20 > text that says a bit more than "this implementation dependent"=20 > without saying too much.=20 Fine, see below for a proposal. > This is what we should discuss, not the MUST provide username=20 requirement in 4741bis. Actually, the text Martin proposed imposes much more than "provide=20 username".=20 The point is that the SSH transport does not know how the NETCONF=20 username is derived from the authentication mechanisms. IOW=20 SSH transport does not know how things are done in lower layers. Now trying a compromise: The proposed text (below) for 4742bis is probably not bad for=20 the purpose and for what SSH transport can state: "The user name provided by the SSH implementation will be made available to NETCONF message layer as NETCONF username without any modification. Any transformations applied to the authenticated=20 user name by the SSH layer are outside the scope of this document." If you guys know anything what can be said additionally, please=20 let me know. With this, we still have kind of mismatch between the proposed texts=20 for 4741bis and 4742bis.=20 As 4742bis cannot fulfil the MUST statement, SHOULD would be probably more appropriate. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, March 10, 2011 7:33 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: ext Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) >=20 > On Thu, Mar 10, 2011 at 06:56:39PM +0100, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > Juergen, > > > > > Is this is a reasonable description of the situation? > > > > It is at least the way you interpret it from the pov. of > > an implementer. > > > > > NETCONF transport protocols therefore MUST > > > explain how a NETCONF username is derived from the authentication > > > mechanisms supported by the transport protocol. > > > > However, I don't think it is a good idea to say that the > > "SSH transport MUST explain how a NETCONF username is derived > > from the authentication mechanisms." > > > > This is a very hard "MUST" which SSH transport specification > > cannot provide. > > > > The only thing SSH transport specification does say is: > > "How the NETCONF Server extracts the user name from the SSH layer is > > implementation-dependent." > > > > What SSH transport document could say is e.g. (but not much more): > > > > " There is no standard way for an application running on an SSH > > server to determine a user name for the current session. How the > > NETCONF Server extracts the user name from the SSH layer is > > therefore implementation-dependent. > > > > The user name provided by the SSH implementation will be made > > available to NETCONF message layer as NETCONF username without > > any modification. Any transformations applied to the > authenticated > > user name by the SSH layer are outside the scope of this > document." > > > > However this would be insufficient with the MUST statement in 4741bis > > above. IMO 4741bis shouldn't impose to 4742bis something, which > 4742bis > > cannot provide. >=20 > I give up. I meanwhile do not know anymore what the text says since I > fail to be able to track which changes have been agreed and which ones > not. >=20 > I maintain the statement that a NETCONF transport that does not > provide a username is unacceptable - or we give up on access > control. The issue is also not that SSH does not provide a username - > the issue is that documenting exactly how this is done without > restricting SSH authentication protocols and/or AAA systems is > difficult. Since the easy way forward of declaring this implementation > dependent does not seem to fly, someone has to cast creative text that > says a bit more than "this implementation dependent" without saying > too much. This is what we should discuss, not the MUST provide > username requirement in 4741bis. >=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 mbj@tail-f.com Thu Mar 10 12:44:32 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5613A6962 for ; Thu, 10 Mar 2011 12:44: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 sg7bUfbQnWWp for ; Thu, 10 Mar 2011 12:44:32 -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 E47F03A67F8 for ; Thu, 10 Mar 2011 12:44:31 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EAAF076C326; Thu, 10 Mar 2011 21:45:48 +0100 (CET) Date: Thu, 10 Mar 2011 21:45:48 +0100 (CET) Message-Id: <20110310.214548.188258827.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110310183303.GA47066@elstar.local> References: <20110310154048.GA46792@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@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] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:44:33 -0000 Juergen Schoenwaelder wrote: > I maintain the statement that a NETCONF transport that does not > provide a username is unacceptable - or we give up on access > control. The issue is also not that SSH does not provide a username - > the issue is that documenting exactly how this is done without > restricting SSH authentication protocols and/or AAA systems is > difficult. Since the easy way forward of declaring this implementation > dependent does not seem to fly, someone has to cast creative text that > says a bit more than "this implementation dependent" without saying > too much. This is what we should discuss, not the MUST provide > username requirement in 4741bis. +1 to this!! /martin From phil@juniper.net Thu Mar 10 12:55:08 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBB63A699C for ; Thu, 10 Mar 2011 12:55:08 -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 Jn68KGEWL1n7 for ; Thu, 10 Mar 2011 12:55:07 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 6E1BD3A67F8 for ; Thu, 10 Mar 2011 12:55:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTXk6+KRqCjtwM6O3oqyaSy1MAdbT9Xpe@postini.com; Thu, 10 Mar 2011 12:56:25 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Mar 2011 12:52:29 -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 p2AKrRv37968; Thu, 10 Mar 2011 12:53: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 p2AKUEkA027708; Thu, 10 Mar 2011 20:30:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103102030.p2AKUEkA027708@idle.juniper.net> To: Randy Presuhn In-Reply-To: <006301cbdf55$9800e200$6801a8c0@oemcomputer> Date: Thu, 10 Mar 2011 15:30:14 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:55:08 -0000 "Randy Presuhn" writes: >Let's get real. Even though "implementation-dependent" isn't the most >satisfying way of describing how something happens, there are times Amen. Maybe we should just ape the words from SFTP (which also uses SSH as a substrate): http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 This protocol assumes that it runs over a secure channel, such as a channel in [RFC4251], that the server has already authenticated the client, and that the identity of the client user is available to the protocol. It talks about restricting owner and group fields to UTF-8, but only when it's talking about transmitting these fields over the wire. I'd be happy to change our current text to something patterned after the above. Terming it an assumption may be more palatable than calling it "implementation dependent". Thanks, Phil From mbj@tail-f.com Thu Mar 10 13:02:55 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F167F3A67F8; Thu, 10 Mar 2011 13:02:54 -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 0xlB7eTUiBQ2; Thu, 10 Mar 2011 13:02:53 -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 6E8383A698C; Thu, 10 Mar 2011 13:02:52 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 090B376C332; Thu, 10 Mar 2011 22:04:10 +0100 (CET) Date: Thu, 10 Mar 2011 22:04:07 +0100 (CET) Message-Id: <20110310.220407.207318548.mbj@tail-f.com> To: muthu@cisco.com From: Martin Bjorklund In-Reply-To: References: 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: Internet-Drafts@ietf.org, biermana@Brocade.com, netconf@ietf.org, i-d-announce@ietf.org Subject: Re: [Netconf] I-DAction:draft-ietf-netconf-system-notifications-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:02:55 -0000 Hi, "Muthumayan Madhayyan (muthu)" wrote: > [muthu > ] Wouldn't it make sense to send some sort of identifier that > tags every commit operation (commit-id) ? If the NMS ever loses > connectivity with the server and regains connectivity later, it can > chose to sync up based on the commit-id. I agree that this would be very useful. It has been discussed before, when we did RFC 6022. However, in order to be useful, a solution to this would require more than just a "commit-id" in the notification. The commit-id should also be available in the datastore list in RFC 6022. And maybe even reported back in the reply to , , and (depending on data store). All this could be done in a separate document (and YANG module) (hint, hint ;) > [muthu > ] Were you planning on defining the typedef instance-identifier > in this YANG module ? instance-identifier is a built-in type in YANG. > 3. In the grouping changed-by-parms, one of the choice is 'server'. What > is the use case where server can initiate a configuration change without > user intervention ? > > [ab: a server may create config as a result of hardware change, > on initially when a fresh running config is created as the > factory default config. The server may get some OOB request > to add a new VLAN for example, and could create non-default config.] > > > [muthu > ] The factory default config makes sense. The OOB request I > presume is still a user request, coming in from some other manageability > interface (snmp perhaps?) - so shouldn't that be just considered > non-NETCONF config user request. I agree. > In any case, there is a use-case for > 'server' triggered configuration change. An example of a server initiated change is when the user sets "foo", but as a result also "bar" is changed. /martin From mbj@tail-f.com Thu Mar 10 13:24:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15AE83A698C for ; Thu, 10 Mar 2011 13:24:03 -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 G7QpSNrUQ2yt for ; Thu, 10 Mar 2011 13:24:02 -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 F32CD3A6A5D for ; Thu, 10 Mar 2011 13:24:01 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AC9A176C2F3; Thu, 10 Mar 2011 22:25:19 +0100 (CET) Date: Thu, 10 Mar 2011 22:25:17 +0100 (CET) Message-Id: <20110310.222517.212564698.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201103102030.p2AKUEkA027708@idle.juniper.net> References: <006301cbdf55$9800e200$6801a8c0@oemcomputer> <201103102030.p2AKUEkA027708@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] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:24:03 -0000 Phil Shafer wrote: > "Randy Presuhn" writes: > >Let's get real. Even though "implementation-dependent" isn't the most > >satisfying way of describing how something happens, there are times > > Amen. Maybe we should just ape the words from SFTP (which also > uses SSH as a substrate): > > http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 > > This protocol assumes that it runs over a secure channel, such as a > channel in [RFC4251], that the server has already authenticated the > client, and that the identity of the client user is available to the > protocol. > > It talks about restricting owner and group fields to UTF-8, but > only when it's talking about transmitting these fields over the > wire. > > I'd be happy to change our current text to something patterned > after the above. Terming it an assumption may be more palatable > than calling it "implementation dependent". I assume you want to put this text in 4741bis, instead of the "MUST explain how a username..." text? (Or did you really mean 4742bis? that's where the "implementation dependent" text is...) I don't think it helps if we replace 2119 language with "assume". It seems to me that this "assume" really is a MUST. /martin From phil@juniper.net Thu Mar 10 14:22:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275113A6AB4 for ; Thu, 10 Mar 2011 14:22: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=[AWL=0.000, 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 Btb2NuhXD93s for ; Thu, 10 Mar 2011 14:22:04 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 4D1BD3A6A9E for ; Thu, 10 Mar 2011 14:22:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTXlPV6K7x0EFLhMwX1/Ep+MnXr09hvgI@postini.com; Thu, 10 Mar 2011 14:23:22 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Mar 2011 14:18:37 -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 p2AMJZv78511; Thu, 10 Mar 2011 14:19:35 -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 p2ALuMQ6028466; Thu, 10 Mar 2011 21:56:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103102156.p2ALuMQ6028466@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110310.222517.212564698.mbj@tail-f.com> Date: Thu, 10 Mar 2011 16:56:22 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:22:07 -0000 Martin Bjorklund writes: >I don't think it helps if we replace 2119 language with "assume". It >seems to me that this "assume" really is a MUST. My take is that we're spending more time on this than an issue this minor needs. If this language is good enough to SFTP, it should be good enough for us. Thanks, Phil From mbj@tail-f.com Thu Mar 10 15:47:01 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497693A67B6 for ; Thu, 10 Mar 2011 15:47: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 xx8+-Ev2tKl3 for ; Thu, 10 Mar 2011 15:47: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 5CCC13A67B2 for ; Thu, 10 Mar 2011 15:47:00 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8842E76C32E; Fri, 11 Mar 2011 00:48:17 +0100 (CET) Date: Fri, 11 Mar 2011 00:48:16 +0100 (CET) Message-Id: <20110311.004816.242901305.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201103102156.p2ALuMQ6028466@idle.juniper.net> References: <20110310.222517.212564698.mbj@tail-f.com> <201103102156.p2ALuMQ6028466@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] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:47:01 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >I don't think it helps if we replace 2119 language with "assume". It > >seems to me that this "assume" really is a MUST. > > My take is that we're spending more time on this than an issue this > minor needs. If this language is good enough to SFTP, it should > be good enough for us. The problem is that your text and the current text both say the same thing, so your text does not solve the problem. The both say that a NETCONF transport must provide a user name. But the problem is in 4742bis that we can't really specify *how* SSH provides a user name, since it depends on the authentication protocol used. /martin From phil@juniper.net Thu Mar 10 18:23:20 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E840B3A67FC for ; Thu, 10 Mar 2011 18:23: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 On997QAoR1aB for ; Thu, 10 Mar 2011 18:23:20 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id F38EF3A6820 for ; Thu, 10 Mar 2011 18:23:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTXmH4uFTD5L5r26NSAYg3MKIo8Z0bajZ@postini.com; Thu, 10 Mar 2011 18:24:38 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Mar 2011 18:17:26 -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 p2B2INv77739; Thu, 10 Mar 2011 18:18:23 -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 p2B1t9lw029654; Fri, 11 Mar 2011 01:55:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103110155.p2B1t9lw029654@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110311.004816.242901305.mbj@tail-f.com> Date: Thu, 10 Mar 2011 20:55:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:23:21 -0000 Martin Bjorklund writes: >But the problem is in 4742bis that we can't really specify *how* SSH >provides a user name, since it depends on the authentication protocol >used. This is because it's implementation dependent, which is what the current text says. I don't see this as a problem, since it is completely internal to the implementation. Thanks, Phil From randy_presuhn@mindspring.com Thu Mar 10 18:47:08 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF293A6B1E for ; Thu, 10 Mar 2011 18:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 0660zvsHX6tu for ; Thu, 10 Mar 2011 18:47:07 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 466B53A6B1C for ; Thu, 10 Mar 2011 18:47:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eR39B4FwRMZ8p1aYrUA2IgP++ufvK/D7q92K1GcypLtIZfs6oPRWbx1PUj8bbGSq; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PxsOv-0000Q9-KN for netconf@ietf.org; Thu, 10 Mar 2011 21:48:25 -0500 Message-ID: <001c01cbdf96$d7869140$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110310.222517.212564698.mbj@tail-f.com><201103102156.p2ALuMQ6028466@idle.juniper.net> <20110311.004816.242901305.mbj@tail-f.com> Date: Thu, 10 Mar 2011 18:48:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb150c22fc8a1fec6994b0a5a2ee33f528350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:47:08 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Thursday, March 10, 2011 3:48 PM > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > The problem is that your text and the current text both say the same > thing, so your text does not solve the problem. The both say that a > NETCONF transport must provide a user name. > > But the problem is in 4742bis that we can't really specify *how* SSH > provides a user name, since it depends on the authentication protocol > used. There are apparently different expectations of what satisfies a requirement to explain how something is done. For me, "it's implementation dependent" is a perfectly reasonable way to address such a requirement when the realities of deployed infrastructure don't permit a more detailed description. Ugly? Yes, but the alternative is to "fix" SSH, and that seems far outside this group's charter. Randy From bertietf@bwijnen.net Fri Mar 11 01:15:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27983A69ED for ; Fri, 11 Mar 2011 01:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6CXCcrN5XZF for ; Fri, 11 Mar 2011 01:15:09 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 76AF73A686A for ; Fri, 11 Mar 2011 01:15:07 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PxySM-0000PM-R4; Fri, 11 Mar 2011 10:16:24 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PxySM-0002sz-Lg; Fri, 11 Mar 2011 10:16:22 +0100 Message-ID: <4D79E866.7040607@bwijnen.net> Date: Fri, 11 Mar 2011 10:16:22 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf@ietf.org References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0B163@DEMUEXC006.nsn-intra.net> <20110310154048.GA46792@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@elstar.local> In-Reply-To: <20110310183303.GA47066@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b3dbd38e79174b8585ded40b92a02426 Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 09:15:10 -0000 WG, please express your opinion on the below text changes On 3/10/11 7:33 PM, Juergen Schoenwaelder wrote: ..snip.... > I give up. I meanwhile do not know anymore what the text says since I > fail to be able to track which changes have been agreed and which ones > not. > .. snip ... > /js > Would be good to see if we have WG concensus... but I think we do. We discussed this matter extensively in one of our IETF sessions, and we had major (not full) consensus that the "implementation dependent" is what we wanted. We may not yet have OK from DBH, but we (WG chairs) will start work on that together with our AD. The current proposed text changes are: For 4741bis, add one sentence: The username is a string of characters that match the "Char" production from section 2.2 of [1]. OLD: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. NEW: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from section 2.2 of [1]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. for rfc4742bis, the proposed change is: OLD: How the NETCONF Server extracts the user name from the SSH layer is therefore implementation-dependent. NEW: There is no standard way for an application running on an SSH server to determine a user name for the current session. How the NETCONF Server extracts the user name from the SSH layer is therefore implementation-dependent. The user name provided by the SSH implementation will be made available to NETCONF message layer as NETCONF username without any modification. Any transformations applied to the authenticated user name by the SSH layer are outside the scope of this document. Bert and Mehmet From mbj@tail-f.com Fri Mar 11 01:56:31 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5527D3A68B6 for ; Fri, 11 Mar 2011 01:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.218, 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 pBobpUX1C5FN for ; Fri, 11 Mar 2011 01:56:30 -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 8AC263A68AB for ; Fri, 11 Mar 2011 01:56:30 -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 6A6CE616002; Fri, 11 Mar 2011 10:57:48 +0100 (CET) Date: Fri, 11 Mar 2011 10:57:47 +0100 (CET) Message-Id: <20110311.105747.176744464168461462.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4D79E866.7040607@bwijnen.net> References: <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net> <20110310183303.GA47066@elstar.local> <4D79E866.7040607@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] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 09:56:31 -0000 Hi, "Bert (IETF) Wijnen" wrote: > OLD: > How the NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. > NEW: > There is no standard way for an application running on an SSH > server to determine a user name for the current session. How the > NETCONF Server extracts the user name from the SSH layer is > therefore implementation-dependent. It is obvious that *how* the username is passed from the SSH layer to the application is implementation dependent, since it amongst other things depends on the programming langauge used. But the interesting thing that we want to try to capture is *what* the user name is. A naive (incorrect) attempt would be to say that the username passed from SSH to NETCONF is the "user name" field in the SSH_MSG_USERAUTH_REQUEST message. But this is not correct, since e.g. GSSAPI says that this field may be empty, and the real user name will fall out from the GSSAPI procedure. I suggest this simpler text: OLD: How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent. NEW: The user name provided by the SSH layer will be made available to NETCONF message layer as NETCONF username without any modification. Any transformations applied to the authenticated user name by the SSH layer are outside the scope of this document. /martin From mehmet.ersue@nsn.com Fri Mar 11 02:22:59 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0033F3A681F for ; Fri, 11 Mar 2011 02:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-nqBD4qC2Ut for ; Fri, 11 Mar 2011 02:22:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A03923A67B0 for ; Fri, 11 Mar 2011 02:22:57 -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 p2BAOENk028334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 11:24:14 +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 p2BAOAbJ000881; Fri, 11 Mar 2011 11:24:14 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 11:24:04 +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, 11 Mar 2011 11:24:01 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C3C6AE@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110311.105747.176744464168461462.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: Acvf0suIV38KaQzBRiCcqfX3mGzeZQAAmWpA References: <80A0822C5E9A4440A5117C2F4CD36A6401C0B2EA@DEMUEXC006.nsn-intra.net><20110310183303.GA47066@elstar.local><4D79E866.7040607@bwijnen.net> <20110311.105747.176744464168461462.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 11 Mar 2011 10:24:04.0932 (UTC) FILETIME=[72A0B040:01CBDFD6] Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 10:22:59 -0000 Hi Martin, the text is indeed a bit redundant could be more short. However, I think the statement with "implementation dependent"=20 is substantial from the NETCONF transport specification pov. I don't mind to keep it in any form as explanation for ... > The user name provided by the SSH layer will be made > available to NETCONF message layer as NETCONF username without > any modification. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Martin Bjorklund > Sent: Friday, March 11, 2011 10:58 AM > To: bertietf@bwijnen.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) >=20 > Hi, >=20 > "Bert (IETF) Wijnen" wrote: > > OLD: > > How the NETCONF Server extracts the user name from the SSH layer > is > > therefore implementation-dependent. > > NEW: > > There is no standard way for an application running on an SSH > > server to determine a user name for the current session. How the > > NETCONF Server extracts the user name from the SSH layer is > > therefore implementation-dependent. >=20 > It is obvious that *how* the username is passed from the SSH layer to > the application is implementation dependent, since it amongst other > things depends on the programming langauge used. >=20 > But the interesting thing that we want to try to capture is *what* the > user name is. A naive (incorrect) attempt would be to say that the > username passed from SSH to NETCONF is the "user name" field in the > SSH_MSG_USERAUTH_REQUEST message. But this is not correct, since > e.g. GSSAPI says that this field may be empty, and the real user name > will fall out from the GSSAPI procedure. >=20 > I suggest this simpler text: >=20 > OLD: >=20 > How the NETCONF Server extracts the SSH user name from the SSH layer > is implementation-dependent. >=20 > NEW: >=20 > The user name provided by the SSH layer will be made > available to NETCONF message layer as NETCONF username without > any modification. Any transformations applied to the authenticated > user name by the SSH layer are outside the scope of this document. >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From ietfc@btconnect.com Fri Mar 11 03:13:39 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40F63A68DD for ; Fri, 11 Mar 2011 03:13:39 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTOZtCkOh+7r for ; Fri, 11 Mar 2011 03:13:38 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 75C263A68C4 for ; Fri, 11 Mar 2011 03:13:38 -0800 (PST) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2beaomr06.btconnect.com with SMTP id CGU66368; Fri, 11 Mar 2011 11:14:49 +0000 (GMT) Message-ID: <022501cbdfd4$80642a60$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Martin Bjorklund" , "Phil Shafer" References: <201103102156.p2ALuMQ6028466@idle.juniper.net> Date: Fri, 11 Mar 2011 11:10:04 +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.4D7A0429.006D, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4D7A042E.0089,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 11:13:39 -0000 ----- Original Message ----- From: "Phil Shafer" To: "Martin Bjorklund" Cc: Sent: Thursday, March 10, 2011 10:56 PM > Martin Bjorklund writes: > >I don't think it helps if we replace 2119 language with "assume". It > >seems to me that this "assume" really is a MUST. > > My take is that we're spending more time on this than an issue this > minor needs. If this language is good enough to SFTP, it should > be good enough for us. True but not relevant. It has to be good enough to clear the IESG DISCUSS and they have a different mind set to us, which we have to embrace (if you weren't part of the similar discussions in ISMS, you haven't lived:-( For myself, implementation dependent is fine (if imperfect). Tom Petch > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Fri Mar 11 05:00:25 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3BD3A6BE1 for ; Fri, 11 Mar 2011 05:00:25 -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=[AWL=0.000, 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 J+qgZT4f7gkR for ; Fri, 11 Mar 2011 05:00:24 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id CF78F3A6BD6 for ; Fri, 11 Mar 2011 05:00:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTXodMmWgHQ10A2Xbz4+4V6KD3sHI4CcW@postini.com; Fri, 11 Mar 2011 05:01:44 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 11 Mar 2011 04:55:38 -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 p2BCuav23888; Fri, 11 Mar 2011 04:56:36 -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 p2BCXMen032879; Fri, 11 Mar 2011 12:33:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103111233.p2BCXMen032879@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110311.105747.176744464168461462.mbj@tail-f.com> Date: Fri, 11 Mar 2011 07:33:22 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:00:25 -0000 Martin Bjorklund writes: > The user name provided by the SSH layer will be made > available to NETCONF message layer as NETCONF username without > any modification. Any transformations applied to the authenticated > user name by the SSH layer are outside the scope of this document. These sentences seem to say the opposites, that is can be changed and that changes are outside the scope of this document. In fact if the user name contains control characters, it must be modified to allow XML to handle it. Also the user name provided by the SSH layer (the "user name" field in the SSH_MSG_USERAUTH_REQUEST message) may be overridden by the user name returned by RADIUS. Or by "ssh layer" are you meaning sshd/login/pam/etc? Thanks, Phil From mbj@tail-f.com Fri Mar 11 05:07:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262EA3A6952 for ; Fri, 11 Mar 2011 05:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.206, 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 QvFhgDN8iDhX for ; Fri, 11 Mar 2011 05:07:42 -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 4B2553A6926 for ; Fri, 11 Mar 2011 05:07:42 -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 4836876C1A0; Fri, 11 Mar 2011 14:09:00 +0100 (CET) Date: Fri, 11 Mar 2011 14:08:58 +0100 (CET) Message-Id: <20110311.140858.623298456415409402.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201103111233.p2BCXMen032879@idle.juniper.net> References: <20110311.105747.176744464168461462.mbj@tail-f.com> <201103111233.p2BCXMen032879@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] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:07:43 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > > The user name provided by the SSH layer will be made > > available to NETCONF message layer as NETCONF username without > > any modification. Any transformations applied to the authenticated > > user name by the SSH layer are outside the scope of this document. > > These sentences seem to say the opposites, that is can be changed > and that changes are outside the scope of this document. > > In fact if the user name contains control characters, it must be > modified to allow XML to handle it. Do you want to add text to handle this? > Also the user name provided > by the SSH layer (the "user name" field in the SSH_MSG_USERAUTH_REQUEST > message) may be overridden by the user name returned by RADIUS. > > Or by "ssh layer" are you meaning sshd/login/pam/etc? Yes. I.e. I don't want to go into what can happen down below, I want to say as little as possible. /martin From phil@juniper.net Fri Mar 11 05:22:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522F33A69AE for ; Fri, 11 Mar 2011 05:22:12 -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 sY6BG1r9oaES for ; Fri, 11 Mar 2011 05:22:11 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E84803A6835 for ; Fri, 11 Mar 2011 05:22:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTXoiTcHTyQKq4Jf1mQC/5ymMSNF/BYRb@postini.com; Fri, 11 Mar 2011 05:23:30 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 11 Mar 2011 05:17:36 -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 p2BDIWv37420; Fri, 11 Mar 2011 05:18:32 -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 p2BCtIJB033434; Fri, 11 Mar 2011 12:55:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201103111255.p2BCtIJB033434@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110311.140858.623298456415409402.mbj@tail-f.com> Date: Fri, 11 Mar 2011 07:55:18 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:22:12 -0000 Martin Bjorklund writes: >> Or by "ssh layer" are you meaning sshd/login/pam/etc? > >Yes. I.e. I don't want to go into what can happen down below, I want >to say as little as possible. So you'd need to define the term "ssh layer". Or say "underlaying system software". Or just say "implementation dependent" ;^) Thanks, Phil From ietfdbh@comcast.net Fri Mar 11 12:53:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601BF3A6A12 for ; Fri, 11 Mar 2011 12:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 N-0aCgR+yzaz for ; Fri, 11 Mar 2011 12:53:25 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 5A66F3A692E for ; Fri, 11 Mar 2011 12:53:23 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta13.westchester.pa.mail.comcast.net with comcast id HwHZ1g00E1ei1Bg5DwujYs; Fri, 11 Mar 2011 20:54:43 +0000 Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id Hwue1g0102JQnJT3kwufiQ; Fri, 11 Mar 2011 20:54:42 +0000 From: "David Harrington" To: "'Martin Bjorklund'" References: <20110309.170234.199713540.mbj@tail-f.com><20110309202555.GA43502@elstar.local><795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> In-Reply-To: <20110309.220955.117242983.mbj@tail-f.com> Date: Fri, 11 Mar 2011 15:54:29 -0500 Message-ID: <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: Acvenl0ywJvWQ8oWQjC0nmTXrIvNowBZgHAA Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 20:53:26 -0000 Hi Martin, That doesn't quite satisfy my DISCUSS, but we're getting close. > > Expected usage appears to include embedding in XML documents, YANG > > data models, native CLI handling, and matching (such as > during lookup > > in an access control system, whether proprietary or standardized). 1) Randy has raised a good point about one of the expected usages - matching. I think the normalization issue will need to be addressed. Access control specifications must know what the acceptable values and matching algorithms are for the netconf username. It makes sense for that to be defined in 4741bis. 2) The second part of your (old and new) text says that netconf transport protocol specs MUST explain how they derive the netconf username from the authentication mechanisms used. I think that requirement will be problmeatic, because most IETF security protocols, like SSH and TLS, are typically required to be able to support a range of existing authentication mechanisms and be able to support new authentication mechanisms as they are developed (algorithm-agility). I recommend that 4741bis state that it the responsibility of the netconf transport implementation (as compared to the security implementation that the netconf transport uses) to provide a netconf username in a format that meets the requirements (that the WG is currently deciding on) regarding character set, normalization, etc. How the transport protocol derives that from the authentication mechanism used is implementation-dependent. I think the transport protocol specification (e.g., 4742bis) should specify a **predictable** value-format for the username it provides, so an operator and/or access control implementation can know what to expect for the username format and value. How it derives that from the output of SSH is implementation-dependent. The discussion in 4741bis only talks about what the transport protocols provide as the result of the authentication process - from incoming connections presumably. The username hides the details of the authentication parameters. What happens if a netconf application wants to send a message, and no session exists yet? what information needs to be provided to the specific transport model to create the session? 4741bis and specific transport protocol specs should set some ground rules about what the transport expects to be provided (needs to have provided), such as a netconf username in a particular format, for creating sessions. Hope this helps, dbh > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, March 09, 2011 4:10 PM > To: ietfdbh@comcast.net > Cc: j.schoenwaelder@jacobs-university.de; phil@juniper.net; > iesg@ietf.org; netconf@ietf.org; > netconf-chairs@tools.ietf.org; > draft-ietf-netconf-4741bis@tools.ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on > draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > Hi David, > > "David Harrington" wrote: > > Hi, > > > > The crux of my discuss for 4741bis is that the netconf username will > > be used by other things, such as CLIs, scripts, YANG, etc. > and should > > be in a format compatible with expected usage. > > Expected usage appears to include embedding in XML documents, YANG > > data models, native CLI handling, and matching (such as > during lookup > > in an access control system, whether proprietary or standardized). > > Agreed. > > > I don't care whether the format of the netconf username is > compatible > > with section 2.2 of the XML specification, or with RFC 6020's string > > data type, or ascii, or some other choice of the WG (although I > > recommend using something standardized). > > > > The (implicit) expectation should be made explicit in documentation > > (and I think 4741bis makes the most sense to define the expected > > format of a netconf username). > > Would the following change resolve your DISCUSS? > > I suggest we add a sentence: > > The username is a string of characters that match the "Char" > production from section 2.2 of [1]. > > OLD: > > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The algorithm used to derive the username is > transport protocol specific and in addition specific to the > authentication mechanism used by the transport protocol. NETCONF > transport protocols therefore MUST explain how a NETCONF > username is > derived from the authentication mechanisms supported by > the transport > protocol. > > NEW: > > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The username is a string of characters that > match the "Char" production from section 2.2 of [1]. The algorithm > used to derive the username is transport protocol specific and in > addition specific to the authentication mechanism used by the > transport protocol. NETCONF transport protocols therefore MUST > explain how a NETCONF username is derived from the authentication > mechanisms supported by the transport protocol. > > > > /martin > From j.schoenwaelder@jacobs-university.de Fri Mar 11 13:51:35 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022DE3A690A; Fri, 11 Mar 2011 13:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 zFhCBZMU5vpE; Fri, 11 Mar 2011 13:51:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BC8493A68F3; Fri, 11 Mar 2011 13:51:33 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C13B5C0040; Fri, 11 Mar 2011 22:52:52 +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 4PsRTg1zQoZo; Fri, 11 Mar 2011 22:52:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB5FC000C; Fri, 11 Mar 2011 22:52:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EC47216EEBF8; Fri, 11 Mar 2011 22:52:45 +0100 (CET) Date: Fri, 11 Mar 2011 22:52:45 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20110311215245.GA63607@elstar.local> Mail-Followup-To: David Harrington , 'Martin Bjorklund' , phil@juniper.net, iesg@ietf.org, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 21:51:35 -0000 On Fri, Mar 11, 2011 at 03:54:29PM -0500, David Harrington wrote: [...] I like to hear from an _operator_ that SSH is causing them problems to deliver predicatable user names, making access control unpredictable. SSH came along in the 1995s and since then it is heavily used on all Unix-based systems and since a large number of years (10?) as well on non-Unix platforms, routers, switches access points, ... There is a significant deployed proof that "it works", many mission critical systems that also do access control (all Unix systems do) have been built around it. Do you really believe all this is fundamentally broken since SSH does not provide predictable user names? Seriously? /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 Fri Mar 11 14:15:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D6D3A6814; Fri, 11 Mar 2011 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 iSZ5SAIC9QOE; Fri, 11 Mar 2011 14:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C543A6A35; Fri, 11 Mar 2011 14:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311221502.18544.73700.idtracker@localhost> Date: Fri, 11 Mar 2011 14:15:02 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-access-control-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 22:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol Access Control Model Author(s) : A. Bierman, M. Bjorklund Filename : draft-ietf-netconf-access-control-03.txt Pages : 53 Date : 2011-03-11 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment, which promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content. This document discusses requirements for a suitable access control model, and provides one solution which meets these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-access-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11141433.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Sun Mar 13 01:27:48 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2E43A6AF5; Sun, 13 Mar 2011 01:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 gFrSnXGPfzYT; Sun, 13 Mar 2011 01:27:47 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 55A323A694C; Sun, 13 Mar 2011 01:27:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFMtcU2HCzI1/2dsb2JhbACYaY18dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.62,310,1297054800"; d="scan'208";a="236493562" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Mar 2011 05:29:07 -0400 X-IronPort-AV: E=Sophos;i="4.62,310,1297054800"; d="scan'208";a="617936343" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Mar 2011 05:29:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 10:28:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: To our Japanese colleagues Thread-Index: AcvhYQzJGrE9C+IBQEKjO+tgzA4f5g== From: "Romascanu, Dan (Dan)" To: Cc: netconf Subject: [Netconf] To our Japanese colleagues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 13 Mar 2011 09:27:48 -0000 Hi, We have all been following the news coming from Japan in the last few days. Our thoughts and worries are with our colleagues in Japan and with the whole Japanese nation which was struck so badly by the earthquake and the tsunamis that followed. In November 2009 we were the guests of Japan and of the city of Hiroshima and enjoyed the hospitality of our Japanese hosts who made of that event one of the best IETF meetings ever. We also have in our area many colleagues from Japan and their work and contributions are highly appreciated. We hope that they are all well, and that their families and lives were not directly impacted by this tragedy. We hope to hear news from them and see them all at the coming IETF meetings.=20 Dan From mbj@tail-f.com Sun Mar 13 14:03:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6D13A6BA8 for ; Sun, 13 Mar 2011 14:03:12 -0700 (PDT) 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 uC5ye-jUHY3I for ; Sun, 13 Mar 2011 14:03:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EF3513A6BAB for ; Sun, 13 Mar 2011 14:03:10 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EE07876C352 for ; Sun, 13 Mar 2011 22:04:31 +0100 (CET) Date: Sun, 13 Mar 2011 22:04:29 +0100 (CET) Message-Id: <20110313.220429.177715851.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] nacm proposal X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 13 Mar 2011 21:03:12 -0000 Hi, Below is a proposal for some changes to NACM to make it easier to use, that I will present in Prague. It is common to think and configure role based access control in terms of features or tasks. A task/feature can be 'routing', 'system', or 'vpn-admin' etc. There are two problems involved when such tasks are mapped to nacm. One problem is that it is difficult to understand which individual rules in larger configurations belong together, because there is just a single list with all rules (of a certain type). This makes it more difficult to maintain the rules. The other problem is that a certain task might involve rules of different types, thus the rules will be spread out in up to four different lists (module-rule, rpc-rule, data-rule, and notification-rule), which makes it even more difficult to understand and maintain the rules. The following proposal changes the structure of the rules a bit, in order to make it easier to create, understand, and maintain access control rules. It does not change the underlying execution model of rules; i.e. it is equivalent in expressive power to the current document. The idea is that we introduce named "rule-lists". A rule-list is a named collection of rules, and it can be shared among different groups. Instead of four different rules lists, there is just one, where the different rule types are done with a choice. Here's an example, using a YANG-like syntax for the content, instead of XML: rule-list networking { allowed-group [ wheel admin ]; rule allow-ietf-interface { module-name "ietf-interface"; access-rights *; action permit; } rule deny-reset { module-name "acme-ethernet-interface"; rpc-name "reset-interface"; access-rights [ execute ]; action deny; } rule allow-acme-ethernet { path "/if:interfaces/if:interface/acme:eth-config"; access-rights [ read update notify ]; action permit; } } Using this, a "task" can be represented as a rule-list, and a large configuration can be broken down into manageable tasks. Here's a compact representation of the rule-list: +--rw nacm +--rw rule-list [name] +--rw name string +--rw allowed-group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(rpc) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(path) | +--rw path schema-instance-identifier +--rw access-rights union +--rw action nacm-action-type And the YANG definition of the rule-list: container nacm { list rule-list { key "name"; ordered-by user; description "A named list of access control rules."; leaf name { type string { length "1..255"; } description "Arbitrary name assigned to this access control rule list."; } leaf-list allowed-group { type union { type nacm-matchall-string-type; type nacm-group-name-type; } min-elements 1; description "List of administrative groups which will be assigned the associated access rights for the content specified by the associated path. The string '*' indicates that all configured administrative groups apply to the entry."; } list rule { key "name"; ordered-by user; description "Rules are processed in user-defined order until a match is found. A rule matches if 'module-name' and 'rule-type' matches the request. If a rule matches, the 'action' leaf determines if access is granted or not."; leaf name { type string { length "1..255"; } description "Arbitrary name assigned to the access control rule."; } // match on these leafs... leaf module-name { type union { type nacm-matchall-string-type; type string; } default "*"; description "This leaf matches if it has the value '*', or if the object being accessed is defined in the module with the specified module name."; } choice rule-type { description "The choice matches if all leafs present in the rule matches the request. If no leafs are present, the choice matches the request."; case rpc { leaf rpc-name { type union { type nacm-matchall-string-type; type string; } description "This leaf matches if its value equals the requested RPC operation name."; } } case notification { leaf notification-name { type union { type nacm-matchall-string-type; type string; } description "This leaf matches if its value equals the requested notification name."; } } case path { leaf path { type schema-instance-identifier; mandatory true; description "Schema Instance Identifier associated with the data node controlled by this rule. Configuration data or state data instance identifiers start with a top-level data node. A complete instance identifier is required for this type of path value. The special value '/' refers to all possible database contents."; } } } leaf access-rights { type union { type nacm-matchall-string-type; type nacm-rights-type; } mandatory true; description "List of access rights granted to specified administrative groups for the content specified by the associated path."; } leaf action { type nacm-action-type; mandatory true; description "The access control action associated with the rule. If a rule is determined to match a particular request, then this object is used to determine whether to permit or deny the request."; } } } } Open issues: 1. Should it be possible for a rule-list to contain not just other rules, but also other rule-lists? This would make it easier to build rule-lists out of smaller reusable pieces. 2. Would it be useful with any objects to help debug nacm? E.g. an rpc to get all rules for a given group, or an rpc to check if a certain path will be permitted or denied for a given group, which also returns a trace of the rules tried that the execution pattern can be traced? /martin From tomoyuki.iijima.fg@hitachi.com Sun Mar 13 16:09:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6E43A690A for ; Sun, 13 Mar 2011 16:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImcgYfL-M393 for ; Sun, 13 Mar 2011 16:09:04 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id B40223A6A2E for ; Sun, 13 Mar 2011 16:09:03 -0700 (PDT) Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id D807F37AC2; Mon, 14 Mar 2011 08:10:25 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id p2DNAPLg018795; Mon, 14 Mar 2011 08:10:25 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2DNAO2F007634; Mon, 14 Mar 2011 08:10:25 +0900 X-AuditID: b753bd60-a3cb9ba000004916-a9-4d7d4ee06711 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id B793A204315; Mon, 14 Mar 2011 08:10:24 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2DNAK47176360; Mon, 14 Mar 2011 08:10:20 +0900 Message-ID: <4D7D4EE4.5050605@hitachi.com> Date: Mon, 14 Mar 2011 08:10:28 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> <4D7735EE.900@hitachi.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> <4D78A0A1.7050502@hitachi.com> <20110310120212.GB45896@elstar.local> In-Reply-To: <20110310120212.GB45896@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 13 Mar 2011 23:09:04 -0000 Dear Juergen, Thank you for your comments. > This seems the wrong approach to me. Perhaps the goal should rather be > to declare NETCONF/SOAP historic and replace it with an Experimental > WebSocket transport. ;-) Yes, replacing a non-mandatory NETCONF/SOAP/HTTP with Experimental NETCONF/WebSocket might be an option. WebSocket is sure to be used widely since it can replace Ajax and Comet, which are arleady used widely. But, it's true that the number of companies that provide SOAP-based management system is increasing. In this regard, I thought making NETCONF/SOAP historic might harm NETCONF's deployment. That's why I've limited the scope. But, I know your argument makes sense. Kind regards, Juergen Schoenwaelder wrote: > On Thu, Mar 10, 2011 at 06:57:53PM +0900, Tomoyuki Iijima wrote: > >>> - Why do you think an additional transport binding is >>> necessary? BEEP is also bi-directional. >> Yes, according to RFC4743, when exchanging NETCONF messages over >> SOAP/HTTP, a network device can send NETCONF Notification over >> SOAP/BEEP. To the best of my knowledge, however, BEEP is not widely >> adopted. And, preparing both HTTP and BEEP for NETCONF/SOAP is >> onerous. In contrast, WebSocket is expected to be used widely and is >> an extension of HTTP. > > Every standards-track transport causes maintenance costs. Instead of > working on another transport for an "expected to be used widely" > protocol, I would rather spent time discussing whether some of the > existing standards-track transports should be made experimental or > historic. OK, I see that your I-D claims "Intended status: > Informational" but this sounds more like Experimental to me. > > That said, I am somewhat concerned about the idea to create a > transport that can only handle a certain type of NETCONF messages. > This seems the wrong approach to me. Perhaps the goal should rather be > to declare NETCONF/SOAP historic and replace it with an Experimental > WebSocket transport. ;-) > > /js (who is not making friends today) > -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory TEL: 045-860-2156 (ext. 874-6059) E-mail: tomoyuki.iijima.fg@hitachi.com From Internet-Drafts@ietf.org Mon Mar 14 14:45:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1FA3A6F99; Mon, 14 Mar 2011 14:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 PRoXhhS2DKlS; Mon, 14 Mar 2011 14:45:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAF23A6F81; Mon, 14 Mar 2011 14:45:06 -0700 (PDT) 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.12 Message-ID: <20110314214506.28151.98244.idtracker@localhost> Date: Mon, 14 Mar 2011 14:45:06 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-10.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, 14 Mar 2011 21:45:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-10.txt Pages : 121 Date : 2011-03-14 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as Remote Procedure Calls (RPC). This document obsoletes RFC 4741. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-4741bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14143806.I-D@ietf.org> --NextPart-- From glenn@cysols.com Mon Mar 14 15:39:43 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F278D3A6BED for ; Mon, 14 Mar 2011 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akFzhtNo5qIu for ; Mon, 14 Mar 2011 15:39:42 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id EE0C53A6B8B for ; Mon, 14 Mar 2011 15:39:41 -0700 (PDT) Received: from [192.168.0.94] (cysvpn07.priv.cysol.co.jp [192.168.0.94]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id p2EMehEo052166 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Mar 2011 07:40:44 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4D7E996B.1090907@cysols.com> Date: Tue, 15 Mar 2011 07:40:43 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: netconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Netconf] From Glenn@Sendai. Re: To our Japanese colleagues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 14 Mar 2011 22:39:43 -0000 Hi Dan, Thanks for the mail. I am OK. Doing fine under the circumstances. It was a Big Bad earthquake. Made worse by the TsuNami. I live and work far from the sea (about 20Kms away). So the TsuNami did not affect me. Some of my office staff live closer to the sea. We have not yet been able to confirm the well being of all, as of now. The quakes are still coming in an endless string. I believe that the worst is over. The lifeline is disrupted- water, food, gasoline, telephone, gas, electricity, all gone. The office building is barely usable. Power cannot be fully restored as there seems to be massive electricity leakage due to water seepage. But slowly things are recovering. I have electricity back in my home. And, we just managed to patch the network connectivity in our office. Supplies are low but spirits are high! Cheers, Glenn (2011/03/13 18:28), Romascanu, Dan (Dan) wrote: > Hi, > > We have all been following the news coming from Japan in the last few > days. Our thoughts and worries are with our colleagues in Japan and > with the whole Japanese nation which was struck so badly by the > earthquake and the tsunamis that followed. In November 2009 we were the > guests of Japan and of the city of Hiroshima and enjoyed the hospitality > of our Japanese hosts who made of that event one of the best IETF > meetings ever. We also have in our area many colleagues from Japan and > their work and contributions are highly appreciated. We hope that they > are all well, and that their families and lives were not directly > impacted by this tragedy. We hope to hear news from them and see them > all at the coming IETF meetings. > > Dan > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Mon Mar 14 15:57:22 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263493A6F3C for ; Mon, 14 Mar 2011 15:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.135, 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 pPOBI1tYVYym for ; Mon, 14 Mar 2011 15:57:20 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id C26353A6BCB for ; Mon, 14 Mar 2011 15:57:20 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p2EMuho8030697; Mon, 14 Mar 2011 15:58:43 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id v1uptg11w-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2011 15:58:43 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 14 Mar 2011 16:01:13 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 14 Mar 2011 15:58:42 -0700 From: Andy Bierman To: Tomoyuki Iijima , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf Date: Mon, 14 Mar 2011 15:58:41 -0700 Thread-Topic: [Netconf] Draft NETCONF Session Agenda for IETF 80 Thread-Index: Acvh09oiUVn06ykHQ36VcJJe31eSGAAxVGYw Message-ID: References: <80A0822C5E9A4440A5117C2F4CD36A6401BD4D57@DEMUEXC006.nsn-intra.net> <4D7735EE.900@hitachi.com> <80A0822C5E9A4440A5117C2F4CD36A6401C0A630@DEMUEXC006.nsn-intra.net> <4D78A0A1.7050502@hitachi.com> <20110310120212.GB45896@elstar.local> <4D7D4EE4.5050605@hitachi.com> In-Reply-To: <4D7D4EE4.5050605@hitachi.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=2011-03-14_05:2011-03-14, 2011-03-14, 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-1012030000 definitions=main-1103140166 Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 14 Mar 2011 22:57:22 -0000 Hi, I am interested in hearing a brief summary about this draft, and how it might work as a complete NETCONF transport. The WebSocket API does not appear to be very far along in the standards process. Is it going to be an RFC? http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 It might be better to wait until this is published before working on yet another transport. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Tomoyuki Iijima Sent: Sunday, March 13, 2011 4:10 PM To: Ersue, Mehmet (NSN - DE/Munich); Netconf Subject: Re: [Netconf] Draft NETCONF Session Agenda for IETF 80 Dear Juergen, Thank you for your comments. > This seems the wrong approach to me. Perhaps the goal should rather be > to declare NETCONF/SOAP historic and replace it with an Experimental > WebSocket transport. ;-) Yes, replacing a non-mandatory NETCONF/SOAP/HTTP with Experimental=20 NETCONF/WebSocket might be an option. WebSocket is sure to be used=20 widely since it can replace Ajax and Comet, which are arleady used=20 widely. But, it's true that the number of companies that provide=20 SOAP-based management system is increasing. In this regard, I thought=20 making NETCONF/SOAP historic might harm NETCONF's deployment. That's why=20 I've limited the scope. But, I know your argument makes sense. Kind regards, Juergen Schoenwaelder wrote: > On Thu, Mar 10, 2011 at 06:57:53PM +0900, Tomoyuki Iijima wrote: >=20 >>> - Why do you think an additional transport binding is >>> necessary? BEEP is also bi-directional. >> Yes, according to RFC4743, when exchanging NETCONF messages over >> SOAP/HTTP, a network device can send NETCONF Notification over >> SOAP/BEEP. To the best of my knowledge, however, BEEP is not widely >> adopted. And, preparing both HTTP and BEEP for NETCONF/SOAP is >> onerous. In contrast, WebSocket is expected to be used widely and is >> an extension of HTTP. >=20 > Every standards-track transport causes maintenance costs. Instead of > working on another transport for an "expected to be used widely" > protocol, I would rather spent time discussing whether some of the > existing standards-track transports should be made experimental or > historic. OK, I see that your I-D claims "Intended status: > Informational" but this sounds more like Experimental to me. >=20 > That said, I am somewhat concerned about the idea to create a > transport that can only handle a certain type of NETCONF messages. > This seems the wrong approach to me. Perhaps the goal should rather be > to declare NETCONF/SOAP historic and replace it with an Experimental > WebSocket transport. ;-) >=20 > /js (who is not making friends today) >=20 --=20 Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory TEL: 045-860-2156 (ext. 874-6059) E-mail: tomoyuki.iijima.fg@hitachi.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From Internet-Drafts@ietf.org Mon Mar 14 17:45:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D763A6A94; Mon, 14 Mar 2011 17:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 AGCxNqvuN9YE; Mon, 14 Mar 2011 17:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3183A696C; Mon, 14 Mar 2011 17:45:02 -0700 (PDT) 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.12 Message-ID: <20110315004502.6446.84866.idtracker@localhost> Date: Mon, 14 Mar 2011 17:45:02 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-08.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, 15 Mar 2011 00:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-08.txt Pages : 13 Date : 2011-03-14 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-rfc4742bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14173604.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Tue Mar 15 02:37:48 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BAD3A6C5B; Tue, 15 Mar 2011 02:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 tz4C6pOmt+Wr; Tue, 15 Mar 2011 02:37:46 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 17D243A6C4D; Tue, 15 Mar 2011 02:37:45 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PzQiX-0006u4-Gb; Tue, 15 Mar 2011 10:39:07 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PzQiX-0006o5-4f; Tue, 15 Mar 2011 10:39:05 +0100 Message-ID: <4D7F33B8.10209@bwijnen.net> Date: Tue, 15 Mar 2011 10:39:04 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: David Harrington References: <20110301230555.15990.2719.idtracker@localhost> In-Reply-To: <20110301230555.15990.2719.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd439f10eb9968d39f4befda78fe62bf70f Cc: netconf , The IESG , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 09:37:48 -0000 David, as you do know I think (at least my memory says that you were in the NETCONF session where this was discussed), the WG has extensively discussed the issue of "how to derive/extract the username from the SSH layer". We then had major consensus (not full consensus, I believe you indeed objected somewhat) that "implementation dependent" was the way to go. Over the last few weeks, the WG has also discussed your DISCUSS, and yet more people have expressed that "implementation dependent" is the best we can do in this situation. If anything needs to be done, then it seems that SSH needs to be "fixed". See wg email thread extracts below. However, we have tried to address your DISCUSS with the following text changes, so that at least at the NETCONF level we do as much as we can. PLEASE reconsider your DISCUSS and see if you can clear it with the following changes that have been posted in new revisions of the 4741bis and 4742bis documents: For 4741bis, add one sentence and change "MUST explain how" into "MUST provide". Exact change: OLD: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. NETCONF transport protocols therefore MUST explain how a NETCONF username is derived from the authentication mechanisms supported by the transport protocol. NEW: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from section 2.2 of [W3C.REC-xml-20001006] . The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. The transport protocol MUST provide a username to be used by the other NETCONF layers. for rfc4742bis, the proposed change is: OLD: How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent. NEW: The username provided by the SSH implementation will be made available to the NETCONF message layer as the NETCONF username without modification. If the username does not comply to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not representable in XML, the SSH session MUST be dropped. Any transformations applied to the authenticated identity of the SSH client made by the SSH server (e.g., via authentication services or mappings to system accounts) are outside the scope of this document. We have also addressed your other discuss points and most of your remarks/comments. The complete diffs are here: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-netconf-4741bis-10-from-09.diff.html http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc4742bis/draft-ietf-netconf-rfc4742bis-08-from-07.diff.html Bert Wijnen Document shepherd 4741bis Mehmet Ersue Document shepherd 4742bis -------- Original Message -------- Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Date: Thu, 10 Mar 2011 11:01:41 -0800 From: Randy Presuhn To: Hi - > From: "Juergen Schoenwaelder" > To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: > Sent: Thursday, March 10, 2011 10:33 AM > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > > "How the NETCONF Server extracts the user name from the SSH layer is > > implementation-dependent." > > > > What SSH transport document could say is e.g. (but not much more): > > > > " There is no standard way for an application running on an SSH > > server to determine a user name for the current session. How the > > NETCONF Server extracts the user name from the SSH layer is > > therefore implementation-dependent. > > > > The user name provided by the SSH implementation will be made > > available to NETCONF message layer as NETCONF username without > > any modification. Any transformations applied to the authenticated > > user name by the SSH layer are outside the scope of this document." > > > > However this would be insufficient with the MUST statement in 4741bis > > above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis > > cannot provide Let's get real. Even though "implementation-dependent" isn't the most satisfying way of describing how something happens, there are times (and this is probably one) where it's the only reasonable way, unless one is willing to accept that any effort to further specify matters will almost inevitably end up over-constraining implementations. ... > I maintain the statement that a NETCONF transport that does not > provide a username is unacceptable - or we give up on access > control. Agreed. "Implementation-dependent" may be distasteful, but the alternative of abandoning access control would be throwing the baby out with the bathwater. > The issue is also not that SSH does not provide a username - > the issue is that documenting exactly how this is done without > restricting SSH authentication protocols and/or AAA systems is > difficult. Since the easy way forward of declaring this implementation > dependent does not seem to fly, someone has to cast creative text that > says a bit more than "this implementation dependent" without saying > too much. This is what we should discuss, not the MUST provide > username requirement in 4741bis. I agree that the username requirement is not what should be under discussion. I reluctantly agree that if this group is unwilling to let the implementation-dependent sleeping dog lie, the only alternative is to spell out and get agreement on the "blessed" set of implementation- dependent things that might be done to produce a username. And I strongly agree that that exercise will need to take care not to say too much - an over-specification here could cause as much trouble as the under-specification that caused the mess in the first place. Randy -----In a later email (dated 3/11/2011) Randy further stated: There are apparently different expectations of what satisfies a requirement to explain how something is done. For me, "it's implementation dependent" is a perfectly reasonable way to address such a requirement when the realities of deployed infrastructure don't permit a more detailed description. Ugly? Yes, but the alternative is to "fix" SSH, and that seems far outside this group's charter. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bwijnen@ripe.net Tue Mar 15 02:56:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501723A6B9F for ; Tue, 15 Mar 2011 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3c5iz3RNACXE for ; Tue, 15 Mar 2011 02:56:32 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 5EE003A69E3 for ; Tue, 15 Mar 2011 02:56:32 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PzR0k-0007G1-OK; Tue, 15 Mar 2011 10:57:56 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PzR0k-0008WJ-Kz; Tue, 15 Mar 2011 10:57:54 +0100 Message-ID: <4D7F3822.6010002@ripe.net> Date: Tue, 15 Mar 2011 10:57:54 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dan ROmascanu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -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: 5ef2bffdfa2294c21c35da1b4f77885e86c194f4b3ef72b058bcacf8b511a940 Cc: Netconf Subject: [Netconf] revision 10 of 4741bis ready to clear discusses. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Mar 2011 09:56:33 -0000 Dan, The editors/authors have worked hard to try and address all DISCUSSes and COMMENTs. As a result, we believe the document did indeed improve. I have send explicit emails to David Harrington and Alexey Melnikov to ask them to clear their DISCUSS. Will you pls follow up with them to try and get their DISCUSSes cleared asap? the DIFFs are here: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-netconf-4741bis-10-from-09.diff.html Thanks, Bert Wijnen document shepherd From bertietf@bwijnen.net Tue Mar 15 03:21:54 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D593A6BBD; Tue, 15 Mar 2011 03:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 WcA6XGXHmu8o; Tue, 15 Mar 2011 03:21:53 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 157F63A69E3; Tue, 15 Mar 2011 03:21:52 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PzRPF-0008Bv-98; Tue, 15 Mar 2011 11:23:14 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PzRPF-00063P-4m; Tue, 15 Mar 2011 11:23:13 +0100 Message-ID: <4D7F3E10.6050806@bwijnen.net> Date: Tue, 15 Mar 2011 11:23:12 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Alexey Melnikov References: <20110315094214.27061.45421.idtracker@localhost> In-Reply-To: <20110315094214.27061.45421.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47d01bfee682c7ed90fc511117b5cd68f Cc: Netconf , The IESG , netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] Alexey Melnikov's Yes on draft-ietf-netconf-4741bis-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 10:21:55 -0000 Inline On 3/15/11 10:42 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-netconf-4741bis-10: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am balloting Yes, but please check a couple of remaining comments. > Thank you. > 4.3. Element > > error-tag: Contains a string identifying the error condition. See > Appendix A for allowed values. > > Is the list of error conditions extensible? If yes, where can they be found? If not, it would be better to be explicit about this, in particular the document should mention that addition of a new error tag value would require capability version increment. > Mmm... My understanding was that this was addressed. See email between you and Martin: 4.3. Element > >> > >> error-tag: Contains a string identifying the error condition. See > >> Appendix A for allowed values. > >> > >>Is the list of error conditions extensible? If yes, where can they be found? > >> > > > >No. These are fixed in the Appendex, and in the XSD. > > So is that still not good enough? > I think an explicit statement that any changes to the list need a new > capability name (version) would be good. > > > Additionally, can you please check if any issues from > need > to be addressed? Yes, most of these issues are already address in -09. /martin > 7.8. > > Negative Response: > > An element is included in the if the > request cannot be completed for any reason. > > How is this possible? What can the client do next if the operation fails? > The discussion between you and MArtin: 7.8. > > Negative Response: > > An element is included in the if the > request cannot be completed for any reason. > > How is this possible? What can the client do next if the operation fails? Good catch. The only reason would be if the request is mal-formed, e.g. contains a unexpected parameter: 42 so i guess that is the explanation. Was that not sufficient? Martin, did we add some other text that would make this clear? > [I haven't checked if the following were addressed:] > I am also agreeing with David's DISCUSS points # 1 and # 2, and I also think that Peter's Comment point # 1 is worth being DISCUSS level. > > We have also responded to David's DISCUSS< see my posting (with copy to IESG list) this morning. We hope he will clear his DISCUSS too. I also believe we have addressed Peter's 1st comment, see changes to section 3. Bert Wijnen document shepherd From lhotka@cesnet.cz Tue Mar 15 03:49:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560923A6BC3; Tue, 15 Mar 2011 03:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 5MEIhXpjL9Ml; Tue, 15 Mar 2011 03:49:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A83053A6BB5; Tue, 15 Mar 2011 03:49:01 -0700 (PDT) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 98C5A2CDE058; Tue, 15 Mar 2011 11:50:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> Date: Tue, 15 Mar 2011 11:50:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) Cc: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 10:49:03 -0000 On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >=20 >> Let me re-ask the question with an example. >> How are implementations required to treat the sequence >> U+0061 U+0308 and U+00E4 in user names? Are they >> identical, different, or is the answer implementation-specific? >> (Both are "=E4".) >=20 > See why I avoid these characters. ;-) I see your point but whatever > the answer is, it really needs to be answered for the YANG string data > type. I don't think the YANG string type has to be changed. As long as we deal = with strings inside NETCONF protocol messages, everything is fine. The = present problem is with strings that are obtained via other channels and = this is out of scope for YANG. Lada >=20 > Right now, 4741bis does not really do anything with the user name, > except requiring that transports provide one. I know, this is a rather > poor excuse. Well, that said, there are of course protocol functions > that do comparisons like the subtree filter. I guess we need to check > what XPATH has to say about this - well xpath 2.0 provides > normalization functions and requires NFC. Is there some sort of a > guideline which normalization form is preferred in IETF standards? >=20 > /js >=20 > --=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 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Tue Mar 15 04:53:07 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F5D3A6B2E; Tue, 15 Mar 2011 04:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyOfwTH93eHI; Tue, 15 Mar 2011 04:53:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 800563A6D61; Tue, 15 Mar 2011 04:53:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2FBsOM4004331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2011 12:54:25 +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 p2FBsNRR023217; Tue, 15 Mar 2011 12:54:23 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 12:54: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: Tue, 15 Mar 2011 12:54:21 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C6E568@DEMUEXC006.nsn-intra.net> In-Reply-To: <4D7F33B8.10209@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4742bis RFC Editors notes WAS:RE: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: Acvi9OIGwPHkqUtTR9ungcyUtIw6LwAEcCow References: <20110301230555.15990.2719.idtracker@localhost> <4D7F33B8.10209@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "David Harrington" , "The IESG" , "netconf" X-OriginalArrivalTime: 15 Mar 2011 11:54:23.0024 (UTC) FILETIME=[B9B6EB00:01CBE307] Cc: draft-ietf-netconf-4742bis@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: [Netconf] 4742bis RFC Editors notes WAS:RE: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:53:07 -0000 Hi All, unfortunately there are two bugs in 4742bis v08, which need=20 to be added to the RFC Editors notes. I assume Dan will change=20 the IESG write-up page soon. Change 1: =3D=3D=3D=3D=3D=3D Appendix A) from v07 got somehow deleted and needs to be=20 added again. Change 2: =3D=3D=3D=3D=3D=3D The text in Section 3.1 contains MUST statements copied from 4741 and is inappropriate. As requested by Alexey we had=20 changed the formulation but forgot to update the Write-up page. -------------------------------------------------------------------- RFC Editors notes for draft-ietf-netconf-rfc4742bis-08.txt: OLD (v08): [empty] NEW: Appendix A. Changes from RFC 4742 =09 =09 This section lists major changes between this document and RFC 4742. =09 =09 o Introduced the new Chunked Framing Mechanism to solve known security issues with the EOM framing. =09 =09 o Extended text in Security Considerations, added text on EOM issues. =09 =09 o Added examples to show new chunked encoding properly, highlighted =09 the location of new lines. =09 =09 o Stated that the extraction of the SSH user name by a NETCONF server is implementation-dependent. =09 =09 o Changed use of the terms client/server, manager/agent to SSH client/server and NETCONF client/server. =09 =09 o Consistently used the term operation, instead of command or message. =09 =09 o Integrated previously-approved errata from =09 http://rfc-editor.org/errata_search.php?rfc=3D4742 3. Section 3.1. OLD (v08): As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST indicate its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server. As [I-D.ietf-netconf-4741bis] states the NETCONF client must also send an XML document containing a element to indicate the NETCONF client's capabilities to the NETCONF server. The document containing the element MUST be the first XML document that the NETCONF client sends after the NETCONF session is established. NEW: As specified in [I-D.ietf-netconf-4741bis] the NETCONF server indicates its=20 capabilities by sending an XML document containing a element as=20 soon as the NETCONF session is established. The NETCONF client can parse=20 this message to determine which NETCONF capabilities are supported by the=20 NETCONF server. As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client also=20 sends an XML document containing a element to indicate the NETCONF=20 client's capabilities to the NETCONF server. The document containing the=20 element is the first XML document that the NETCONF client sends=20 after the NETCONF session is established. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert (IETF) Wijnen > Sent: Tuesday, March 15, 2011 10:39 AM > To: David Harrington > Cc: netconf; The IESG; netconf-chairs@tools.ietf.org; draft-ietf- > netconf-4741bis@tools.ietf.org > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) >=20 > David, >=20 > as you do know I think (at least my memory says that you were > in the NETCONF session where this was discussed), the WG > has extensively discussed the issue of "how to derive/extract > the username from the SSH layer". We then had major consensus > (not full consensus, I believe you indeed objected somewhat) > that "implementation dependent" was the way to go. >=20 > Over the last few weeks, the WG has also discussed your DISCUSS, > and yet more people have expressed that "implementation dependent" > is the best we can do in this situation. >=20 > If anything needs to be done, then it seems that SSH needs to > be "fixed". See wg email thread extracts below. >=20 > However, we have tried to address your DISCUSS with the > following text changes, so that at least at the NETCONF > level we do as much as we can. >=20 > PLEASE reconsider your DISCUSS and see if you can clear it > with the following changes that have been posted in new > revisions of the 4741bis and 4742bis documents: >=20 > For 4741bis, add one sentence and change "MUST explain how" into > "MUST provide". Exact change: >=20 > OLD: >=20 > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The algorithm used to derive the username is > transport protocol specific and in addition specific to the > authentication mechanism used by the transport protocol. NETCONF > transport protocols therefore MUST explain how a NETCONF username > is > derived from the authentication mechanisms supported by the > transport > protocol. >=20 > NEW: >=20 > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The username is a string of characters that > match > the "Char" production from section 2.2 of [W3C.REC-xml-20001006] . > The algorithm used to derive the username is transport protocol > specific and in addition specific to the authentication mechanism > used by the transport protocol. The transport protocol MUST > provide > a username to be used by the other NETCONF layers. >=20 >=20 > for rfc4742bis, the proposed change is: >=20 > OLD: > How the NETCONF Server extracts the SSH user name from the SSH > layer > is implementation-dependent. >=20 > NEW: > The username provided by the SSH implementation will be made > available to the NETCONF message layer as the NETCONF username > without modification. If the username does not comply to the NETCONF > requirements on usernames [I-D.ietf-netconf-4741bis] , i.e., the > username is not representable in XML, the SSH session MUST be > dropped. Any transformations applied to the authenticated identity > of the SSH client made by the SSH server (e.g., via authentication > services or mappings to system accounts) are outside the scope of > this document. >=20 >=20 > We have also addressed your other discuss points and most of your > remarks/comments. > The complete diffs are here: > http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf- > netconf-4741bis-10-from-09.diff.html > http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc4742bis/draft- > ietf-netconf-rfc4742bis-08-from-07.diff.html >=20 > Bert Wijnen > Document shepherd 4741bis > Mehmet Ersue > Document shepherd 4742bis >=20 > -------- Original Message -------- > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) > Date: Thu, 10 Mar 2011 11:01:41 -0800 > From: Randy Presuhn > To: >=20 >=20 >=20 > Hi - >=20 > > From: "Juergen Schoenwaelder" > > To: "Ersue, Mehmet (NSN - DE/Munich)" > > Cc: > > Sent: Thursday, March 10, 2011 10:33 AM > > Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf- > netconf-4741bis-09: (with DISCUSS and COMMENT) > ... > > > "How the NETCONF Server extracts the user name from the SSH layer > is > > > implementation-dependent." > > > > > > What SSH transport document could say is e.g. (but not much > more): > > > > > > " There is no standard way for an application running on an SSH > > > server to determine a user name for the current session. How > the > > > NETCONF Server extracts the user name from the SSH layer is > > > therefore implementation-dependent. > > > > > > The user name provided by the SSH implementation will be made > > > available to NETCONF message layer as NETCONF username > without > > > any modification. Any transformations applied to the > authenticated > > > user name by the SSH layer are outside the scope of this > document." > > > > > > However this would be insufficient with the MUST statement in > 4741bis > > > above. IMO 4741bis shouldn't impose to 4742bis something, which > 4742bis > > > cannot provide >=20 > Let's get real. Even though "implementation-dependent" isn't the most > satisfying way of describing how something happens, there are times > (and this is probably one) where it's the only reasonable way, unless > one is willing to accept that any effort to further specify matters > will almost > inevitably end up over-constraining implementations. >=20 > ... > > I maintain the statement that a NETCONF transport that does not > > provide a username is unacceptable - or we give up on access > > control. >=20 > Agreed. "Implementation-dependent" may be distasteful, but the > alternative of abandoning access control would be throwing the > baby out with the bathwater. >=20 > > The issue is also not that SSH does not provide a username - > > the issue is that documenting exactly how this is done without > > restricting SSH authentication protocols and/or AAA systems is > > difficult. Since the easy way forward of declaring this > implementation > > dependent does not seem to fly, someone has to cast creative text > that > > says a bit more than "this implementation dependent" without saying > > too much. This is what we should discuss, not the MUST provide > > username requirement in 4741bis. >=20 > I agree that the username requirement is not what should be > under discussion. I reluctantly agree that if this group is unwilling > to let > the implementation-dependent sleeping dog lie, the only alternative is > to spell out and get agreement on the "blessed" set of implementation- > dependent things that might be done to produce a username. And I > strongly agree that that exercise will need to take care not to say too > much - an over-specification here could cause as much trouble as the > under-specification that caused the mess in the first place. >=20 > Randy >=20 > -----In a later email (dated 3/11/2011) Randy further stated: >=20 > There are apparently different expectations of what satisfies > a requirement to explain how something is done. For me, > "it's implementation dependent" is a perfectly reasonable way > to address such a requirement when the realities of deployed > infrastructure don't permit a more detailed description. Ugly? > Yes, but the alternative is to "fix" SSH, and that seems far > outside this group's charter. >=20 > Randy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Mar 15 05:26:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8F93A6B2B for ; Tue, 15 Mar 2011 05:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIyE1a0VEzmZ for ; Tue, 15 Mar 2011 05:26:32 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 20EAA3A694E for ; Tue, 15 Mar 2011 05:26:31 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PzTLs-00056h-38 for netconf@ietf.org; Tue, 15 Mar 2011 13:27:53 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PzTLr-0003yD-T9 for netconf@ietf.org; Tue, 15 Mar 2011 13:27:52 +0100 Message-ID: <4D7F5B47.1000503@bwijnen.net> Date: Tue, 15 Mar 2011 13:27:51 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: netconf@ietf.org References: <20110314214506.28151.98244.idtracker@localhost> In-Reply-To: <20110314214506.28151.98244.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42b7c4aae4a8adda5a7bd21307dbde797 Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-4741bis-10.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, 15 Mar 2011 12:26:33 -0000 Netconf WG participants, this new revision was created to address a few IESG DISCUSSes and a series of IESG COMMENTS. I believe that it is still inline with the WG consensus on the document we submitted to our AD and for qhich we requested RFC publication. In any event, while we're following up with our AD and the DISCUSS holding ADs, pls take a look at the diffs and let us know if you see anything strange. http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-netconf-4741bis-10-from-09.diff.html Thanks to the authors/Editors Bert Wijnen document shepherd. On 3/14/11 10:45 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > > Title : Network Configuration Protocol (NETCONF) > Author(s) : R. Enns, et al. > Filename : draft-ietf-netconf-4741bis-10.txt > Pages : 121 > Date : 2011-03-14 > > The Network Configuration Protocol (NETCONF) defined in this document > provides mechanisms to install, manipulate, and delete the > configuration of network devices. It uses an Extensible Markup > Language (XML)-based data encoding for the configuration data as well > as the protocol messages. The NETCONF protocol operations are > realized as Remote Procedure Calls (RPC). This document obsoletes > RFC 4741. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-10.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 randy_presuhn@mindspring.com Tue Mar 15 14:29:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389123A6EBD; Tue, 15 Mar 2011 14:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 m15lCOjL+V19; Tue, 15 Mar 2011 14:29:01 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 26BAF3A6EB5; Tue, 15 Mar 2011 14:29:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fZaEqn9R9T6upzbl/VPl7OMNo5ZzApVwoL6GhBN68pR7YYCNFjQtKmOII+aedd/F; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Pzbou-0004jm-6A; Tue, 15 Mar 2011 17:30:24 -0400 Message-ID: <003601cbe360$9f3c8420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Ladislav Lhotka" , "Juergen Schoenwaelder" References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> Date: Tue, 15 Mar 2011 14:30:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3828a20089cb13cf4765b3149442c02ffda350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Cc: iesg@ietf.org, ietfdbh@comcast.net, netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:29:02 -0000 Hi - > From: "Ladislav Lhotka" > To: "Juergen Schoenwaelder" > Cc: "Randy Presuhn" ; ; ; ; ; > Sent: Tuesday, March 15, 2011 2:50 AM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: > > > On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: > > > >> Let me re-ask the question with an example. > >> How are implementations required to treat the sequence > >> U+0061 U+0308 and U+00E4 in user names? Are they > >> identical, different, or is the answer implementation-specific? > >> (Both are "ä".) > > > > See why I avoid these characters. ;-) I see your point but whatever > > the answer is, it really needs to be answered for the YANG string data > > type. > > I don't think the YANG string type has to be changed. As long as > we deal with strings inside NETCONF protocol messages, > everything is fine. The present problem is with strings that are > obtained via other channels and this is out of scope for YANG. "Other channels" isn't the question. Is the a string consisting of the sequence U+0061 U+0308 equal to one consisting of U+00E4? Are two configurations which differ only in this way "the same" configuration? Randy From mbj@tail-f.com Tue Mar 15 14:34:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE0D3A6B45 for ; Tue, 15 Mar 2011 14:34:10 -0700 (PDT) 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 H6YWEfHlQucb for ; Tue, 15 Mar 2011 14:34:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 105B73A6975 for ; Tue, 15 Mar 2011 14:34:10 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 543FC76C379; Tue, 15 Mar 2011 22:35:34 +0100 (CET) Date: Tue, 15 Mar 2011 22:35:32 +0100 (CET) Message-Id: <20110315.223532.129389367.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003601cbe360$9f3c8420$6801a8c0@oemcomputer> References: <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:34:11 -0000 Hi, [pruning the send list a bit] "Randy Presuhn" wrote: > Hi - > = > > From: "Ladislav Lhotka" > > To: "Juergen Schoenwaelder" > > Cc: "Randy Presuhn" ; ; > > ; > ; ; > > Sent: Tuesday, March 15, 2011 2:50 AM > > Subject: Re: [Netconf] David Harrington's Discuss > > ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > > > > On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: > > > > > On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: > > > > > >> Let me re-ask the question with an example. > > >> How are implementations required to treat the sequence > > >> U+0061 U+0308 and U+00E4 in user names? Are they > > >> identical, different, or is the answer implementation-specific? > > >> (Both are "=E4".) > > > > > > See why I avoid these characters. ;-) I see your point but whatev= er > > > the answer is, it really needs to be answered for the YANG string= data > > > type. > > > > I don't think the YANG string type has to be changed. As long as > > we deal with strings inside NETCONF protocol messages, > > everything is fine. The present problem is with strings that are > > obtained via other channels and this is out of scope for YANG. > = > "Other channels" isn't the question. > Is the a string consisting of the sequence U+0061 U+0308 equal > to one consisting of U+00E4? Are two configurations which differ > only in this way "the same" configuration? How does this work with normal SSH and e.g. RADIUS? /martin From randy_presuhn@mindspring.com Tue Mar 15 15:08:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E193A6E34 for ; Tue, 15 Mar 2011 15:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOd-XmWQssSL for ; Tue, 15 Mar 2011 15:08:01 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 654D63A6E06 for ; Tue, 15 Mar 2011 15:08:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eTd/rEXSbHt0Plqb2CuUmL2OIlYUj6DqywbtULJLLptwac4vaq2aaEW6swvD1DQL; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PzcQg-0003zR-I9 for netconf@ietf.org; Tue, 15 Mar 2011 18:09:26 -0400 Message-ID: <000401cbe366$14662940$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de><96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz><003601cbe360$9f3c8420$6801a8c0@oemcomputer> <20110315.223532.129389367.mbj@tail-f.com> Date: Tue, 15 Mar 2011 15:09:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382bff3602507df43753bdaf9c758eeffed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:08:02 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, March 15, 2011 1:35 PM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > > "Other channels" isn't the question. > > Is the a string consisting of the sequence U+0061 U+0308 equal > > to one consisting of U+00E4? Are two configurations which differ > > only in this way "the same" configuration? > > How does this work with normal SSH and e.g. RADIUS? I repeat, "other channels" isn't the question. But to answer *your* question, RFC 6065 (the isms AAA / VACM integration) would treat these two sequences as *not* identical, if that was what the AAA infrastructure considered to be the user name. I'm *not* going to argue that that is "right". In many ways it's quite broken, but it's a consequence of how Unicode support happened in SNMP-land, where normalization would have to have been done by whatever entity provisioned things in the first place. Making it "un-broken" there would have required breaking too many other things. Randy From mbj@tail-f.com Tue Mar 15 15:15:34 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A785B3A6B30 for ; Tue, 15 Mar 2011 15:15:34 -0700 (PDT) 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 3TORXJ0tcypa for ; Tue, 15 Mar 2011 15:15:34 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D16D83A6BD3 for ; Tue, 15 Mar 2011 15:15:33 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DD5CF76C320; Tue, 15 Mar 2011 23:16:58 +0100 (CET) Date: Tue, 15 Mar 2011 23:16:56 +0100 (CET) Message-Id: <20110315.231656.16527007.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000401cbe366$14662940$6801a8c0@oemcomputer> References: <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <20110315.223532.129389367.mbj@tail-f.com> <000401cbe366$14662940$6801a8c0@oemcomputer> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:15:34 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Tuesday, March 15, 2011 1:35 PM > > Subject: Re: [Netconf] David Harrington's Discuss > > ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > ... > > > "Other channels" isn't the question. > > > Is the a string consisting of the sequence U+0061 U+0308 equal > > > to one consisting of U+00E4? Are two configurations which differ > > > only in this way "the same" configuration? > > > > How does this work with normal SSH and e.g. RADIUS? > > I repeat, "other channels" isn't the question. > > But to answer *your* question, RFC 6065 (the isms AAA / VACM > integration) would treat these two sequences as *not* identical, if that > was what the AAA infrastructure considered to be the user name. I was thinking about e.g. a CLI user that presents a user name to SSH, and SSH uses RADIUS to authenticate. Will RADIUS perform any normalization? I suppose not. Then I don't see why NETCONF would impose a normalization procedure. So I think that these two sequences also in NETCONF would be treated as different. Do you think that this is a problem? /martin From biermana@Brocade.com Tue Mar 15 15:17:14 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593B83A6B49 for ; Tue, 15 Mar 2011 15:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.123, 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 YiIUqgMJ5PLK for ; Tue, 15 Mar 2011 15:17:13 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 9E55B3A6B30 for ; Tue, 15 Mar 2011 15:17:13 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p2FMHDZV008833; Tue, 15 Mar 2011 15:18:39 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id v2drgr5mw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2011 15:18:38 -0700 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, 15 Mar 2011 15:21:07 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 15 Mar 2011 15:18:38 -0700 From: Andy Bierman To: Randy Presuhn , "netconf@ietf.org" Date: Tue, 15 Mar 2011 15:18:37 -0700 Thread-Topic: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: AcvjXa4oRHPPKfWGQVK5TnaIjBKHWAAAN6rg Message-ID: References: <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de><96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz><003601cbe360$9f3c8420$6801a8c0@oemcomputer> <20110315.223532.129389367.mbj@tail-f.com> <000401cbe366$14662940$6801a8c0@oemcomputer> In-Reply-To: <000401cbe366$14662940$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-15_03:2011-03-14, 2011-03-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103150166 Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:17:14 -0000 Hi, I think Martin is asking why you think this is a NETCONF-specific issue. I would think string normalization of UTF-8 is a generic problem, and not specific to NETCONF whatsoever. Why would a NETCONF server do some 1-off special transformation, instead of following rules written for every protocol? Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Randy Presuhn Sent: Tuesday, March 15, 2011 4:10 PM To: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741= bis-09: (with DISCUSS and COMMENT) Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, March 15, 2011 1:35 PM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-47= 41bis-09: (with DISCUSS and COMMENT) ... > > "Other channels" isn't the question. > > Is the a string consisting of the sequence U+0061 U+0308 equal > > to one consisting of U+00E4? Are two configurations which differ > > only in this way "the same" configuration? > > How does this work with normal SSH and e.g. RADIUS? I repeat, "other channels" isn't the question. But to answer *your* question, RFC 6065 (the isms AAA / VACM integration) would treat these two sequences as *not* identical, if that was what the AAA infrastructure considered to be the user name. I'm *not* going to argue that that is "right". In many ways it's quite broken, but it's a consequence of how Unicode support happened in SNMP-land, where normalization would have to have been done by whatever entity provisioned things in the first place. Making it=20 "un-broken" there would have required breaking too many other things. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Mar 15 16:01:28 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088D93A6F0B for ; Tue, 15 Mar 2011 16:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 ddL2s8ZQccIi for ; Tue, 15 Mar 2011 16:01:27 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 7B3493A6F01 for ; Tue, 15 Mar 2011 16:01:26 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PzdGI-00027q-UV; Wed, 16 Mar 2011 00:02:50 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PzdGI-0004BV-Ad; Wed, 16 Mar 2011 00:02:46 +0100 Message-ID: <4D7FF016.5010905@bwijnen.net> Date: Wed, 16 Mar 2011 00:02:46 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: David Harrington References: <20110315211623.16173.4123.idtracker@localhost> In-Reply-To: <20110315211623.16173.4123.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e1c30043c96a171b00f8549182535824 Cc: Netconf Subject: Re: [Netconf] David Harrington's Yes on draft-ietf-netconf-4741bis-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:01:28 -0000 Thanks Dave, Bert document shepherd On 3/15/11 10:16 PM, David Harrington wrote: > David Harrington has entered the following ballot position for > draft-ietf-netconf-4741bis-10: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I cleared > > > From randy_presuhn@mindspring.com Tue Mar 15 16:13:52 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22A83A6ECA for ; Tue, 15 Mar 2011 16:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 Q3CwYGjAnqNW for ; Tue, 15 Mar 2011 16:13:52 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D84A73A6D7E for ; Tue, 15 Mar 2011 16:13:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=c8sHhUv6YwqjKE9dRRP5OjwL8iSS90ToI0pi9UZPn0+JtXQePyPsjRexTv4JNqR0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.222] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PzdSP-0001s7-B4 for netconf@ietf.org; Tue, 15 Mar 2011 19:15:17 -0400 Message-ID: <001501cbe36f$4666ac40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003601cbe360$9f3c8420$6801a8c0@oemcomputer><20110315.223532.129389367.mbj@tail-f.com><000401cbe366$14662940$6801a8c0@oemcomputer> <20110315.231656.16527007.mbj@tail-f.com> Date: Tue, 15 Mar 2011 16:15:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b38246c48f43972926964d82f8ae4299be32350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.222 Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:13:52 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, March 15, 2011 2:16 PM > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > I was thinking about e.g. a CLI user that presents a user name to > SSH, and SSH uses RADIUS to authenticate. Will RADIUS perform any > normalization? I suppose not. Then I don't see why NETCONF would > impose a normalization procedure. So I think that these two sequences > also in NETCONF would be treated as different. Do you think that this > is a problem? It needs to be a conscious decision. The bottom line is that "Schönwälder" can be represented in UTF-8 by four different byte sequences, and user interfaces don't typically give users much (if any) control over which one is used. It doesn't take too much imagination to think up difficulties if a system considers all four to be different. Of course, one might say that that's an acceptable trade-off. It just needs to be a conscious design decision. I don't know specifically about RADIUS, but, for example, RFC 5802 is quite explicit in its use of normalization forms. Randy From lhotka@cesnet.cz Wed Mar 16 00:17:36 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066B43A681E; Wed, 16 Mar 2011 00:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 GK7WlhpTsit3; Wed, 16 Mar 2011 00:17:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D07E33A681A; Wed, 16 Mar 2011 00:17:34 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 68AF82CDE057; Wed, 16 Mar 2011 08:18:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <003601cbe360$9f3c8420$6801a8c0@oemcomputer> Date: Wed, 16 Mar 2011 08:18:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1082) Cc: iesg@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, ietfdbh@comcast.net, netconf-chairs@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 07:17:36 -0000 On Mar 15, 2011, at 11:30 PM, Randy Presuhn wrote: > Hi - >=20 >> From: "Ladislav Lhotka" >> To: "Juergen Schoenwaelder" >> Cc: "Randy Presuhn" ; = ; ; > ; ; = >> Sent: Tuesday, March 15, 2011 2:50 AM >> Subject: Re: [Netconf] David Harrington's Discuss = ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) >>=20 >> On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: >>=20 >>> On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >>>=20 >>>> Let me re-ask the question with an example. >>>> How are implementations required to treat the sequence >>>> U+0061 U+0308 and U+00E4 in user names? Are they >>>> identical, different, or is the answer implementation-specific? >>>> (Both are "=E4".) >>>=20 >>> See why I avoid these characters. ;-) I see your point but whatever >>> the answer is, it really needs to be answered for the YANG string = data >>> type. >>=20 >> I don't think the YANG string type has to be changed. As long as >> we deal with strings inside NETCONF protocol messages, >> everything is fine. The present problem is with strings that are >> obtained via other channels and this is out of scope for YANG. >=20 > "Other channels" isn't the question. > Is the a string consisting of the sequence U+0061 U+0308 equal > to one consisting of U+00E4? Are two configurations which differ > only in this way "the same" configuration? Neither XML 1.0 nor YANG assumes any character model normalization, so = IMO the two sequences are different. Lada >=20 > Randy >=20 >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Mar 16 01:03:37 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043F93A684B for ; Wed, 16 Mar 2011 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 SSkrSvGAHWcz for ; Wed, 16 Mar 2011 01:03:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D941F3A6844 for ; Wed, 16 Mar 2011 01:03:35 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 024202CDE057; Wed, 16 Mar 2011 09:04:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <001501cbe36f$4666ac40$6801a8c0@oemcomputer> Date: Wed, 16 Mar 2011 09:04:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <122F06E5-73CD-45C3-A8AE-3E76E92B6EA8@cesnet.cz> References: <003601cbe360$9f3c8420$6801a8c0@oemcomputer><20110315.223532.129389367.mbj@tail-f.com><000401cbe366$14662940$6801a8c0@oemcomputer> <20110315.231656.16527007.mbj@tail-f.com> <001501cbe36f$4666ac40$6801a8c0@oemcomputer> To: Randy Presuhn X-Mailer: Apple Mail (2.1082) Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 08:03:37 -0000 On Mar 16, 2011, at 1:15 AM, Randy Presuhn wrote: > The bottom line is that "Sch=F6nw=E4lder" can be represented in UTF-8 > by four different byte sequences, and user interfaces don't typically > give users much (if any) control over which one is used. It doesn't > take too much imagination to think up difficulties if a system > considers all four to be different. Of course, one might say that = that's > an acceptable trade-off. It just needs to be a conscious design > decision. We already have a similar case with IP addresses: "::1" and "::0:1" are = different as generic strings but equivalent as IPv6 addresses, and the = "ipv6-address" type in RFC 6021 defines a unique canonical form. = Therefore, it could be left to the access control module to define a = type like "username" whose canonical form *may* involve character model = normalization. My point is that there is no need to change the definition of the = "string" built-in type. Lada=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Wed Mar 16 01:14:45 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513BD3A6870 for ; Wed, 16 Mar 2011 01:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 3swjomAeQ4ec for ; Wed, 16 Mar 2011 01:14:44 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id C632A3A684A for ; Wed, 16 Mar 2011 01:14:42 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Pzltk-00081Z-Ee; Wed, 16 Mar 2011 09:16:06 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Pzltk-0001gM-A0; Wed, 16 Mar 2011 09:16:04 +0100 Message-ID: <4D8071C3.5080202@bwijnen.net> Date: Wed, 16 Mar 2011 09:16:03 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Randy Presuhn References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> In-Reply-To: <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4d68b61c5cbb6ec9a1fd8344d5039919a Cc: ietfdbh@comcast.net, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 08:14:45 -0000 Hi all, I have taken off IESG and the log for 4741bis email addresses. The topic was/is not part of any IESG DISCUSS or COMMENT. I did this, because I am not sure this is a problem we should try to address in this revision of rfc4741bis. AS Lada stated, we can (for now at least I think) assume that two different sequences are different users. As far as we know, it has not caused any practical problem. Perfect is the enemy of good (enough). I (personally) would not want to hold up this document any longer in order to try and make sure everyone understands the details of this thread/discussion and is able to express an informed opinion on what to do. I suggest that for now we conclude: it is a conscious OK to consider two different character sequences as different usernames. If anyone dis-agrees, please speak up asap. Bert Wijnen document shepherd On 3/16/11 8:18 AM, Ladislav Lhotka wrote: > On Mar 15, 2011, at 11:30 PM, Randy Presuhn wrote: > >> Hi - >> >>> From: "Ladislav Lhotka" >>> To: "Juergen Schoenwaelder" >>> Cc: "Randy Presuhn";;; >> ;; >>> Sent: Tuesday, March 15, 2011 2:50 AM >>> Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) >>> >>> On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: >>> >>>> On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >>>> >>>>> Let me re-ask the question with an example. >>>>> How are implementations required to treat the sequence >>>>> U+0061 U+0308 and U+00E4 in user names? Are they >>>>> identical, different, or is the answer implementation-specific? >>>>> (Both are "ä".) >>>> See why I avoid these characters. ;-) I see your point but whatever >>>> the answer is, it really needs to be answered for the YANG string data >>>> type. >>> I don't think the YANG string type has to be changed. As long as >>> we deal with strings inside NETCONF protocol messages, >>> everything is fine. The present problem is with strings that are >>> obtained via other channels and this is out of scope for YANG. >> "Other channels" isn't the question. >> Is the a string consisting of the sequence U+0061 U+0308 equal >> to one consisting of U+00E4? Are two configurations which differ >> only in this way "the same" configuration? > Neither XML 1.0 nor YANG assumes any character model normalization, so IMO the two sequences are different. > > Lada > >> Randy >> >> > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mehmet.ersue@nsn.com Wed Mar 16 04:07:25 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED2A3A6961 for ; Wed, 16 Mar 2011 04:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+9wVUV3MTV5 for ; Wed, 16 Mar 2011 04:07:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D55503A695F for ; Wed, 16 Mar 2011 04:07:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2GB8mBF022144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Mar 2011 12:08:48 +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 p2GB8Zcd001804 for ; Wed, 16 Mar 2011 12:08:44 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 12:08: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, 16 Mar 2011 12:08:28 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401C6EDBC@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session Agenda for IETF 80 Thread-Index: AcvjynoflJw/7tGlSeG/xRS26xCdkQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 16 Mar 2011 11:08:30.0026 (UTC) FILETIME=[7B3682A0:01CBE3CA] Subject: [Netconf] Session Agenda for IETF 80 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Mar 2011 11:07:25 -0000 Dear NETCONF WG, we uploaded the proposed agenda for the NETCONF session in Prague. http://www.ietf.org/proceedings/80/agenda/netconf.txt Please let us know if you have any comment. Mehmet=20 From ietfc@btconnect.com Wed Mar 16 04:13:03 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F873A696F for ; Wed, 16 Mar 2011 04:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nbAuETOBBDO for ; Wed, 16 Mar 2011 04:13:02 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 0CEDE3A696B for ; Wed, 16 Mar 2011 04:13:01 -0700 (PDT) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2bthomr07.btconnect.com with SMTP id CIG42219; Wed, 16 Mar 2011 11:14:06 +0000 (GMT) Message-ID: <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert \(IETF\) Wijnen" , "Randy Presuhn" References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer><7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> Date: Wed, 16 Mar 2011 11:09:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.4D809B72.001B, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D809B84.0289,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: ietfdbh@comcast.net, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 11:13:03 -0000 ----- Original Message ----- From: "Bert (IETF) Wijnen" To: "Randy Presuhn" Cc: ; Sent: Wednesday, March 16, 2011 9:16 AM Hi all, I have taken off IESG and the log for 4741bis email addresses. The topic was/is not part of any IESG DISCUSS or COMMENT. I did this, because I am not sure this is a problem we should try to address in this revision of rfc4741bis. AS Lada stated, we can (for now at least I think) assume that two different sequences are different users. As far as we know, it has not caused any practical problem. Perfect is the enemy of good (enough). I (personally) would not want to hold up this document any longer in order to try and make sure everyone understands the details of this thread/discussion and is able to express an informed opinion on what to do. I suggest that for now we conclude: it is a conscious OK to consider two different character sequences as different usernames. I have no problem with Netconf not specifying a normalisation scheme for Unicode. As Juergen said, SSH has been working without it for years. But... lack of normalisation is a vector for attack, phishing and such like, so I think that the fact that normalisation is not specified, that multiple user names which appear identical on display are in fact different, needs adding to the security considerations, as, for example, in RFC3629. Tom Petch If anyone dis-agrees, please speak up asap. Bert Wijnen document shepherd On 3/16/11 8:18 AM, Ladislav Lhotka wrote: > On Mar 15, 2011, at 11:30 PM, Randy Presuhn wrote: > >> Hi - >> >>> From: "Ladislav Lhotka" >>> To: "Juergen Schoenwaelder" >>> Cc: "Randy Presuhn";;; >> ;; >>> Sent: Tuesday, March 15, 2011 2:50 AM >>> Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) >>> >>> On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: >>> >>>> On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >>>> >>>>> Let me re-ask the question with an example. >>>>> How are implementations required to treat the sequence >>>>> U+0061 U+0308 and U+00E4 in user names? Are they >>>>> identical, different, or is the answer implementation-specific? >>>>> (Both are "ä".) >>>> See why I avoid these characters. ;-) I see your point but whatever >>>> the answer is, it really needs to be answered for the YANG string data >>>> type. >>> I don't think the YANG string type has to be changed. As long as >>> we deal with strings inside NETCONF protocol messages, >>> everything is fine. The present problem is with strings that are >>> obtained via other channels and this is out of scope for YANG. >> "Other channels" isn't the question. >> Is the a string consisting of the sequence U+0061 U+0308 equal >> to one consisting of U+00E4? Are two configurations which differ >> only in this way "the same" configuration? > Neither XML 1.0 nor YANG assumes any character model normalization, so IMO the two sequences are different. > > Lada > >> Randy >> >> > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Wed Mar 16 04:17:40 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED263A6953 for ; Wed, 16 Mar 2011 04:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 ktBq-sY+ahIq for ; Wed, 16 Mar 2011 04:17:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 339823A6952 for ; Wed, 16 Mar 2011 04:17:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FEC2C001E; Wed, 16 Mar 2011 12:19:05 +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 pc5DB+rOSHLG; Wed, 16 Mar 2011 12:19:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E6BBC002A; Wed, 16 Mar 2011 12:19:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 391AD16FC49D; Wed, 16 Mar 2011 12:19:03 +0100 (CET) Date: Wed, 16 Mar 2011 12:19:03 +0100 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20110316111903.GA772@elstar.local> Mail-Followup-To: "t.petch" , "Bert (IETF) Wijnen" , Randy Presuhn , ietfdbh@comcast.net, netconf@ietf.org References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietfdbh@comcast.net, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 16 Mar 2011 11:17:40 -0000 On Wed, Mar 16, 2011 at 11:09:00AM +0100, t.petch wrote: > I have no problem with Netconf not specifying a normalisation scheme > for Unicode. As Juergen said, SSH has been working without it for > years. But... lack of normalisation is a vector for attack, > phishing and such like, so I think that the fact that normalisation > is not specified, that multiple user names which appear identical on > display are in fact different, needs adding to the security > considerations, as, for example, in RFC3629. But that text can go into the NACM document - NETCONF itself so far is not using the username. /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 Mar 16 10:18:11 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1793A69DE for ; Wed, 16 Mar 2011 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.160, 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 9-PthzGZbr7k for ; Wed, 16 Mar 2011 10:18:10 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 2326A3A69D9 for ; Wed, 16 Mar 2011 10:18:09 -0700 (PDT) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2beaomr08.btconnect.com with SMTP id CCM23440; Wed, 16 Mar 2011 17:19:29 +0000 (GMT) Message-ID: <01b501cbe3f5$41d59480$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> <20110316111903.GA772@elstar.local> Date: Wed, 16 Mar 2011 17:14:37 +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.0A0B0303.4D80F121.0051, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4D80F123.00B4,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: ietfdbh@comcast.net, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:18:11 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t.petch" Cc: "Bert (IETF) Wijnen" ; "Randy Presuhn" ; ; Sent: Wednesday, March 16, 2011 12:19 PM > On Wed, Mar 16, 2011 at 11:09:00AM +0100, t.petch wrote: > > > I have no problem with Netconf not specifying a normalisation scheme > > for Unicode. As Juergen said, SSH has been working without it for > > years. But... lack of normalisation is a vector for attack, > > phishing and such like, so I think that the fact that normalisation > > is not specified, that multiple user names which appear identical on > > display are in fact different, needs adding to the security > > considerations, as, for example, in RFC3629. > > But that text can go into the NACM document - NETCONF itself so far is > not using the username. Weeelll, um. RFC4742 does make reference to the extraction of the user name and we have been having this DISCUSSion for the past fortnight, so I think that 4742bis should capture the current thinking with at least the first sentence below lest we have a rerun in six months time eg This memo does not specify any normalization of the user name as provided by or to the SSH layer. The same character display can be generated by different UTF-8 byte sequences which may give rise to the potential for attacks. See [RFC3629] for more details. Tom Petch > > /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 Wed Mar 16 10:35:21 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C603A69FB for ; Wed, 16 Mar 2011 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, 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 Ati61fUKUlQ3 for ; Wed, 16 Mar 2011 10:35:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B24383A69F2 for ; Wed, 16 Mar 2011 10:35:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18636C001E; Wed, 16 Mar 2011 18:36:47 +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 5g8dy2FVIJw3; Wed, 16 Mar 2011 18:36:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2041DC000F; Wed, 16 Mar 2011 18:36:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0852416FD0A2; Wed, 16 Mar 2011 18:36:45 +0100 (CET) Date: Wed, 16 Mar 2011 18:36:45 +0100 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20110316173645.GA1468@elstar.local> Mail-Followup-To: "t.petch" , "Bert (IETF) Wijnen" , Randy Presuhn , ietfdbh@comcast.net, netconf@ietf.org References: <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> <20110316111903.GA772@elstar.local> <01b501cbe3f5$41d59480$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b501cbe3f5$41d59480$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietfdbh@comcast.net, netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 16 Mar 2011 17:35:22 -0000 On Wed, Mar 16, 2011 at 05:14:37PM +0100, t.petch wrote: > This memo does not specify any normalization of the user name as > provided by or to the SSH layer. The same character display can be > generated by different UTF-8 byte sequences which may give rise to > the potential for attacks. See [RFC3629] for more details. This text would actually be wrong since there is no mandate whatsoever that the username is encoded in UTF-8 when it is picked up. Randy's comment concerned comparions. I maintain my position that NETCONF, more precisely 4741bis and 4742bis, does not do any comparisons of the username. NACM will do so if there is a risk of "surprising" comparisions, it should be fine this in NACM. If you have other concerns about the usage of XML encoded in UTF-8 in NETCONF, you should start a new thread (and perhaps check that other protocols using XML do explicitely deal with your concern). /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 Mar 16 11:40:34 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27843A69F4 for ; Wed, 16 Mar 2011 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8WL931gFtvk for ; Wed, 16 Mar 2011 11:40:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 996C03A68C8 for ; Wed, 16 Mar 2011 11:40:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2GIfZZn025988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2011 19:41:35 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2GIfVgG010182; Wed, 16 Mar 2011 19:41:35 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 19:41:30 +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, 16 Mar 2011 19:41:27 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401CA59A2@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Our Sympathy is with our Japanese Colleagues Thread-Index: AcvkCcI/F7lkzWUSSz+1624VRqHMkw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Tomoyuki Iijima" , "ext Glenn M. Keeni" X-OriginalArrivalTime: 16 Mar 2011 18:41:31.0001 (UTC) FILETIME=[C4562690:01CBE409] Cc: netconf Subject: [Netconf] Our Sympathy is with our Japanese Colleagues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Mar 2011 18:40:34 -0000 Dear Tomoyuki, Glenn, please be sure of our worries and sympathy for this extraordinary=20 tragedy happening in Japan. We are all following the news and our=20 thoughts are with you and the Japanese nation. We hope that you are all well, and your families and their lives are=20 not directly impacted by this disaster. We would be happy to hear=20 from you and to see all Japanese attendees at the coming IETF=20 meeting.=20 Mehmet & Bert NETCONF WG Co-chairs From tomoyuki.iijima.fg@hitachi.com Wed Mar 16 18:21:22 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496A03A69D8 for ; Wed, 16 Mar 2011 18:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhook+HulnyA for ; Wed, 16 Mar 2011 18:21:20 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id 258903A69EC for ; Wed, 16 Mar 2011 18:21:19 -0700 (PDT) Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id C150E37AC5; Thu, 17 Mar 2011 10:22:44 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id p2H1MiOo006669; Thu, 17 Mar 2011 10:22:44 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2H1MhUK015678; Thu, 17 Mar 2011 10:22:44 +0900 X-AuditID: b753bd60-a38c7ba0000066fd-6c-4d8162632ade Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id A260B774273; Thu, 17 Mar 2011 10:22:43 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2H1Md18249368; Thu, 17 Mar 2011 10:22:39 +0900 Message-ID: <4D81625F.3080803@hitachi.com> Date: Thu, 17 Mar 2011 10:22:39 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6401CA59A2@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401CA59A2@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: netconf Subject: Re: [Netconf] Our Sympathy is with our Japanese Colleagues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Mar 2011 01:21:22 -0000 Dear Mehmet, Bert, and Dan, Thank you for your kindness. > not directly impacted by this disaster. We would be happy to hear > from you and to see all Japanese attendees at the coming IETF I was affected by the earthquake, but fortunately I'm fine. I'm working in the Tokyo area, which is far south from the epicenter. And we are used to earthquakes. But this earthquake was different. It shook violently and I had a fear of death for the first time. I feel some inconveniences now, but it's minor when I think of victims. All of your countries have dispatched rescue teams and relief funds immediately after the earthquake. We are appreciating those benevolence. Finally, thank you for allocating a time slot in the agenda. I think I can go there as scheduled. Kind regards, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Tomoyuki, Glenn, > > please be sure of our worries and sympathy for this extraordinary > tragedy happening in Japan. We are all following the news and our > thoughts are with you and the Japanese nation. > > We hope that you are all well, and your families and their lives are > not directly impacted by this disaster. We would be happy to hear > from you and to see all Japanese attendees at the coming IETF > meeting. > > Mehmet & Bert > NETCONF WG Co-chairs > > . -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory TEL: 045-860-2156 (ext. 874-6059) E-mail: tomoyuki.iijima.fg@hitachi.com From wjhns1@hardakers.net Thu Mar 17 10:58:20 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227D43A6A09; Thu, 17 Mar 2011 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzkGAOz6uZa6; Thu, 17 Mar 2011 10:58:19 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 520B33A69FE; Thu, 17 Mar 2011 10:58:19 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id F18FD22E45; Thu, 17 Mar 2011 10:59:25 -0700 (PDT) From: Wes Hardaker To: David Harrington References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> <20110311215245.GA63607@elstar.local> Date: Thu, 17 Mar 2011 10:59:25 -0700 In-Reply-To: <20110311215245.GA63607@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Mar 2011 22:52:45 +0100") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:58:20 -0000 >>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder said: JS> Do you really believe all this is fundamentally broken since SSH JS> does not provide predictable user names? Seriously? Juergen, Though I actually agree that this is likely a non-issue, I don't think you can compare the past history of SSH with the new usages. Most of the previous SSH usage has *only* been for command-line logins where you rarely need to know, once you're inside, what your user name is and even if you do it likely wasn't needed by the global system. IE, there was never a set of configuration that needed to be pushed into every device that should match everywhere such that 'bob' was 'bob' everywhere and not 'b0b' somewhere else where the access control configuration settings prevented him from operating on that device. So, having said that, even though I'm not sure you can easily extrapolate the past history forward into the future of netconf (and other protocols leveraging SSH as a tunneling platform), I still don't think it's going to be a problem. And if it is, I think the implementations will likely be fixed quickly. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Mar 17 11:45:37 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1E73A6ADD; Thu, 17 Mar 2011 11:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 6RwJFnOIHuZ7; Thu, 17 Mar 2011 11:45:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 710453A6A33; Thu, 17 Mar 2011 11:45:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24A44C0016; Thu, 17 Mar 2011 19:47:04 +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 Uox4ELFljEl3; Thu, 17 Mar 2011 19:47:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54396C0015; Thu, 17 Mar 2011 19:47:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A292A1701F1B; Thu, 17 Mar 2011 19:47:02 +0100 (CET) Date: Thu, 17 Mar 2011 19:47:02 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20110317184702.GA5792@elstar.local> Mail-Followup-To: Wes Hardaker , David Harrington , netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, netconf-chairs@tools.ietf.org, iesg@ietf.org References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> <20110311215245.GA63607@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: iesg@ietf.org, David Harrington , netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 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, 17 Mar 2011 18:45:38 -0000 On Thu, Mar 17, 2011 at 10:59:25AM -0700, Wes Hardaker wrote: > >>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder said: > > JS> Do you really believe all this is fundamentally broken since SSH > JS> does not provide predictable user names? Seriously? > > Juergen, > > Though I actually agree that this is likely a non-issue, I don't think > you can compare the past history of SSH with the new usages. Most of > the previous SSH usage has *only* been for command-line logins where you > rarely need to know, once you're inside, what your user name is and even > if you do it likely wasn't needed by the global system. IE, there was > never a set of configuration that needed to be pushed into every device > that should match everywhere such that 'bob' was 'bob' everywhere and > not 'b0b' somewhere else where the access control configuration settings > prevented him from operating on that device. I (like many others) happen to use SSH for lots of system administration tasks, also often across domain boundaries, where accounts have different names and all this works reasonably well _because there are mechanisms to translate names_. If I setup RADIUS to rewrite bob to b0b, then this is done for a reason. If I do not want to remember that I have to authenticate as b0b@example.com, I configure my client to do the translation automatically. The same goes for the selection of keys and so on and so on. If the resulting username (or account name for that matter) on one device is bob and on another b0b, that this is something config can't ignore. If you copy files across Unix systems, you better pay attention to the owner names and or uids (depending on what you use during the unpacking process). This is how it has been for a long time and this will continue to be so, also with NETCONF access control rules. Back to the topic of the discussion: The claim was that the username ending up on the server side is unpredictable. I believe this is not correct. The username is predictable but the result of a potentially complex transformation that is outside of the scope of NETCONF and also outside the scope of SSH since it may involve authentication systems external to SSH. And the reason we have these transformations is the need to deal with real-world complexity, in particular when dealing with domain boundaries. Pretenting this complexity does not exist or even more ruling this out in a specification would in my view have been a _major_ mistake. /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 Mar 17 12:37:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C463A6A5F; Thu, 17 Mar 2011 12:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 rtauDzyLpkxT; Thu, 17 Mar 2011 12:37:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 069003A6A1E; Thu, 17 Mar 2011 12:37:17 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2941F2CDE057; Thu, 17 Mar 2011 20:38:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20110317184702.GA5792@elstar.local> Date: Thu, 17 Mar 2011 20:38:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E26B396-AB8E-4EBC-B652-DA869EA45317@cesnet.cz> References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> <20110311215245.GA63607@elstar.local> <20110317184702.GA5792@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) Cc: netconf@ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org, David Harrington , netconf-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 19:37:26 -0000 On Mar 17, 2011, at 7:47 PM, Juergen Schoenwaelder wrote: > On Thu, Mar 17, 2011 at 10:59:25AM -0700, Wes Hardaker wrote: >>>>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder = said: >>=20 >> JS> Do you really believe all this is fundamentally broken since SSH >> JS> does not provide predictable user names? Seriously? >>=20 >> Juergen, >>=20 >> Though I actually agree that this is likely a non-issue, I don't = think >> you can compare the past history of SSH with the new usages. Most of >> the previous SSH usage has *only* been for command-line logins where = you >> rarely need to know, once you're inside, what your user name is and = even >> if you do it likely wasn't needed by the global system. IE, there = was >> never a set of configuration that needed to be pushed into every = device >> that should match everywhere such that 'bob' was 'bob' everywhere and >> not 'b0b' somewhere else where the access control configuration = settings >> prevented him from operating on that device. >=20 > I (like many others) happen to use SSH for lots of system > administration tasks, also often across domain boundaries, where > accounts have different names and all this works reasonably well > _because there are mechanisms to translate names_. If I setup RADIUS > to rewrite bob to b0b, then this is done for a reason. If I do not > want to remember that I have to authenticate as b0b@example.com, I > configure my client to do the translation automatically. The same goes > for the selection of keys and so on and so on. >=20 > If the resulting username (or account name for that matter) on one > device is bob and on another b0b, that this is something config can't > ignore. If you copy files across Unix systems, you better pay > attention to the owner names and or uids (depending on what you use > during the unpacking process). This is how it has been for a long time > and this will continue to be so, also with NETCONF access control > rules. >=20 > Back to the topic of the discussion: The claim was that the username > ending up on the server side is unpredictable. I believe this is not > correct. The username is predictable but the result of a potentially > complex transformation that is outside of the scope of NETCONF and > also outside the scope of SSH since it may involve authentication > systems external to SSH. And the reason we have these transformations > is the need to deal with real-world complexity, in particular when > dealing with domain boundaries. Pretenting this complexity does not > exist or even more ruling this out in a specification would in my view > have been a _major_ mistake. +1. In fact, since the user must already have logged in through SSH, it = shouldn't be such a big deal for the server to find out who the user = really is from the OS perspective. How this identity translates to = NETCONF credentials is a different (and inherently system-dependent) = matter. Lada >=20 > /js >=20 > --=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 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Thu Mar 17 16:48:27 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402E83A69B9 for ; Thu, 17 Mar 2011 16:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VHmSIx3Hla5 for ; Thu, 17 Mar 2011 16:48:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BC2323A68BD for ; Thu, 17 Mar 2011 16:48:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2HNnoHE004512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2011 00:49:50 +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 p2HNnojO030482; Fri, 18 Mar 2011 00:49:50 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 00:49:49 +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, 18 Mar 2011 00:49:48 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401CA61E6@DEMUEXC006.nsn-intra.net> In-Reply-To: <7E26B396-AB8E-4EBC-B652-DA869EA45317@cesnet.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Thread-Index: Acvk2voPzaZaXG61TOelEF6V3/iFVAAIknWg References: <20110309.170234.199713540.mbj@tail-f.com><20110309202555.GA43502@elstar.local><795EF5C74EF246A593C43298AA44C877@davidPC><20110309.220955.117242983.mbj@tail-f.com><6D1CCDF72A4040E48D9D661B7D9C5583@davidPC><20110311215245.GA63607@elstar.local><20110317184702.GA5792@elstar.local> <7E26B396-AB8E-4EBC-B652-DA869EA45317@cesnet.cz> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 17 Mar 2011 23:49:49.0990 (UTC) FILETIME=[01019C60:01CBE4FE] Cc: ext David B Harrington Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 23:48:27 -0000 Hi All, the DISCUSSes have been already cleared. As Bert=20 suggested please do not CC iesg for this discussion.=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ladislav Lhotka > Sent: Thursday, March 17, 2011 8:39 PM > To: Juergen Schoenwaelder > Cc: netconf@ietf.org; draft-ietf-netconf-4741bis@tools.ietf.org; David > Harrington; netconf-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf- > 4741bis-09: (with DISCUSS and COMMENT) >=20 >=20 > On Mar 17, 2011, at 7:47 PM, Juergen Schoenwaelder wrote: >=20 > > On Thu, Mar 17, 2011 at 10:59:25AM -0700, Wes Hardaker wrote: > >>>>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder > said: > >> > >> JS> Do you really believe all this is fundamentally broken since SSH > >> JS> does not provide predictable user names? Seriously? > >> > >> Juergen, > >> > >> Though I actually agree that this is likely a non-issue, I don't > think > >> you can compare the past history of SSH with the new usages. Most > of > >> the previous SSH usage has *only* been for command-line logins where > you > >> rarely need to know, once you're inside, what your user name is and > even > >> if you do it likely wasn't needed by the global system. IE, there > was > >> never a set of configuration that needed to be pushed into every > device > >> that should match everywhere such that 'bob' was 'bob' everywhere > and > >> not 'b0b' somewhere else where the access control configuration > settings > >> prevented him from operating on that device. > > > > I (like many others) happen to use SSH for lots of system > > administration tasks, also often across domain boundaries, where > > accounts have different names and all this works reasonably well > > _because there are mechanisms to translate names_. If I setup RADIUS > > to rewrite bob to b0b, then this is done for a reason. If I do not > > want to remember that I have to authenticate as b0b@example.com, I > > configure my client to do the translation automatically. The same > goes > > for the selection of keys and so on and so on. > > > > If the resulting username (or account name for that matter) on one > > device is bob and on another b0b, that this is something config can't > > ignore. If you copy files across Unix systems, you better pay > > attention to the owner names and or uids (depending on what you use > > during the unpacking process). This is how it has been for a long > time > > and this will continue to be so, also with NETCONF access control > > rules. > > > > Back to the topic of the discussion: The claim was that the username > > ending up on the server side is unpredictable. I believe this is not > > correct. The username is predictable but the result of a potentially > > complex transformation that is outside of the scope of NETCONF and > > also outside the scope of SSH since it may involve authentication > > systems external to SSH. And the reason we have these transformations > > is the need to deal with real-world complexity, in particular when > > dealing with domain boundaries. Pretenting this complexity does not > > exist or even more ruling this out in a specification would in my > view > > have been a _major_ mistake. >=20 > +1. >=20 > In fact, since the user must already have logged in through SSH, it > shouldn't be such a big deal for the server to find out who the user > really is from the OS perspective. How this identity translates to > NETCONF credentials is a different (and inherently system-dependent) > matter. >=20 > Lada >=20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Fri Mar 18 01:35:55 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197563A67DB for ; Fri, 18 Mar 2011 01:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ru4mjY77o9sr for ; Fri, 18 Mar 2011 01:35:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 405023A66B4 for ; Fri, 18 Mar 2011 01:35:53 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 854ED76C4E8; Fri, 18 Mar 2011 09:37:21 +0100 (CET) Date: Fri, 18 Mar 2011 09:37:19 +0100 (CET) Message-Id: <20110318.093719.161548721.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110316111903.GA772@elstar.local> References: <4D8071C3.5080202@bwijnen.net> <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> <20110316111903.GA772@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] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 08:35:55 -0000 Juergen Schoenwaelder wrote: > On Wed, Mar 16, 2011 at 11:09:00AM +0100, t.petch wrote: > > > I have no problem with Netconf not specifying a normalisation scheme > > for Unicode. As Juergen said, SSH has been working without it for > > years. But... lack of normalisation is a vector for attack, > > phishing and such like, so I think that the fact that normalisation > > is not specified, that multiple user names which appear identical on > > display are in fact different, needs adding to the security > > considerations, as, for example, in RFC3629. > > But that text can go into the NACM document - NETCONF itself so far is > not using the username. +1. 4741bis doesn't use it, and 6022 simply reports it. /martin From bertietf@bwijnen.net Fri Mar 18 02:48:56 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42E53A6A4B for ; Fri, 18 Mar 2011 02:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ie38tNum7oCN for ; Fri, 18 Mar 2011 02:48:55 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 17E143A6A06 for ; Fri, 18 Mar 2011 02:48:53 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Q0WJx-0006Ct-Di for netconf@ietf.org; Fri, 18 Mar 2011 10:50:21 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Q0WJx-0007oj-8P for netconf@ietf.org; Fri, 18 Mar 2011 10:50:13 +0100 Message-ID: <4D832AD5.1010102@bwijnen.net> Date: Fri, 18 Mar 2011 10:50:13 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: netconf@ietf.org References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> In-Reply-To: <4D8071C3.5080202@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4c6b044116e43285d8f24eca88c270683 Subject: [Netconf] draft-ietf-netconf-4741bis-10 is finished and ready to go to RFC-Editor X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Mar 2011 09:48:56 -0000 From the discussion on the below in which only a few have participated sofar, we (WG chairs) conclude that we are done with 4741bis and that if any text is needed to address this, then it would probably go into one of the NACM documents, but not in 4741bis. Both chairs (as technical contributors) also support this position. Bert and Mehmet On 3/16/11 9:16 AM, Bert (IETF) Wijnen wrote: -------- Original Message -------- Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) Date: Wed, 16 Mar 2011 09:16:03 +0100 From: Bert (IETF) Wijnen To: Randy Presuhn CC: ietfdbh@comcast.net, netconf@ietf.org > Hi all, > > I have taken off IESG and the log for 4741bis email addresses. > The topic was/is not part of any IESG DISCUSS or COMMENT. > > I did this, because I am not sure this is a problem we should try to address > in this revision of rfc4741bis. > AS Lada stated, we can (for now at least I think) assume that two different > sequences are different users. As far as we know, it has not caused any > practical problem. > > Perfect is the enemy of good (enough). I (personally) would not want to hold > up this document any longer in order to try and make sure everyone understands > the details of this thread/discussion and is able to express an informed > opinion on what to do. > > I suggest that for now we conclude: it is a conscious OK to consider two > different character sequences as different usernames. > > If anyone dis-agrees, please speak up asap. > > Bert Wijnen > document shepherd > > > On 3/16/11 8:18 AM, Ladislav Lhotka wrote: >> On Mar 15, 2011, at 11:30 PM, Randy Presuhn wrote: >> >>> Hi - >>> >>>> From: "Ladislav Lhotka" >>>> To: "Juergen Schoenwaelder" >>>> Cc: "Randy Presuhn";;; >>> ;; >>>> Sent: Tuesday, March 15, 2011 2:50 AM >>>> Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) >>>> >>>> On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: >>>> >>>>> On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >>>>> >>>>>> Let me re-ask the question with an example. >>>>>> How are implementations required to treat the sequence >>>>>> U+0061 U+0308 and U+00E4 in user names? Are they >>>>>> identical, different, or is the answer implementation-specific? >>>>>> (Both are "ä".) >>>>> See why I avoid these characters. ;-) I see your point but whatever >>>>> the answer is, it really needs to be answered for the YANG string data >>>>> type. >>>> I don't think the YANG string type has to be changed. As long as >>>> we deal with strings inside NETCONF protocol messages, >>>> everything is fine. The present problem is with strings that are >>>> obtained via other channels and this is out of scope for YANG. >>> "Other channels" isn't the question. >>> Is the a string consisting of the sequence U+0061 U+0308 equal >>> to one consisting of U+00E4? Are two configurations which differ >>> only in this way "the same" configuration? >> Neither XML 1.0 nor YANG assumes any character model normalization, so IMO the two sequences are different. >> >> Lada >> >>> Randy >>> >>> >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C From wjhns1@hardakers.net Fri Mar 18 07:31:57 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8013A690A; Fri, 18 Mar 2011 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuvNPFjUXmXh; Fri, 18 Mar 2011 07:31:56 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 9DDFF3A68F9; Fri, 18 Mar 2011 07:31:56 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id E7B6823661; Fri, 18 Mar 2011 07:33:04 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> <20110311215245.GA63607@elstar.local> <20110317184702.GA5792@elstar.local> Date: Fri, 18 Mar 2011 07:33:04 -0700 In-Reply-To: <20110317184702.GA5792@elstar.local> (Juergen Schoenwaelder's message of "Thu, 17 Mar 2011 19:47:02 +0100") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: iesg@ietf.org, David Harrington , netconf@ietf.org, netconf-chairs@tools.ietf.org, draft-ietf-netconf-4741bis@tools.ietf.org Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:31:57 -0000 >>>>> On Thu, 17 Mar 2011 19:47:02 +0100, Juergen Schoenwaelder said: JS> Back to the topic of the discussion: The claim was that the username JS> ending up on the server side is unpredictable. I believe this is not JS> correct. Trying to keep on topic (IE, ignoring the rest of the post): I think there are two different parts of that statement. From a standards perspective: the user name isn't predictable, because nothing says it has to be. From a real world and implementation point of view: it is, because all the implementations behave the same way. So, I agree it's a non-issue in the real-world and I support the current text because I think it's sufficient. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Fri Mar 18 07:32:33 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC8E3A690A for ; Fri, 18 Mar 2011 07:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPXA4YXq74b7 for ; Fri, 18 Mar 2011 07:32:32 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 3D2ED3A68D5 for ; Fri, 18 Mar 2011 07:32:32 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A380A23661; Fri, 18 Mar 2011 07:33:40 -0700 (PDT) From: Wes Hardaker To: "Ersue\, Mehmet \(NSN - DE\/Munich\)" References: <20110309.170234.199713540.mbj@tail-f.com> <20110309202555.GA43502@elstar.local> <795EF5C74EF246A593C43298AA44C877@davidPC> <20110309.220955.117242983.mbj@tail-f.com> <6D1CCDF72A4040E48D9D661B7D9C5583@davidPC> <20110311215245.GA63607@elstar.local> <20110317184702.GA5792@elstar.local> <7E26B396-AB8E-4EBC-B652-DA869EA45317@cesnet.cz> <80A0822C5E9A4440A5117C2F4CD36A6401CA61E6@DEMUEXC006.nsn-intra.net> Date: Fri, 18 Mar 2011 07:33:40 -0700 In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401CA61E6@DEMUEXC006.nsn-intra.net> (Mehmet Ersue's message of "Fri, 18 Mar 2011 00:49:48 +0100") Message-ID: User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: ext David B Harrington , netconf Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:32:33 -0000 >>>>> On Fri, 18 Mar 2011 00:49:48 +0100, "Ersue, Mehmet (NSN - DE/Munich)" said: "M(> the DISCUSSes have been already cleared. As Bert "M(> suggested please do not CC iesg for this discussion. I hate it when I read the rest of the thread too late. -- Wes Hardaker Cobham Analytic Solutions From ietfc@btconnect.com Fri Mar 18 11:10:46 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6D43A6A29 for ; Fri, 18 Mar 2011 11:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, 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 eu2U-U5qWGmC for ; Fri, 18 Mar 2011 11:10:45 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 59BB83A6A07 for ; Fri, 18 Mar 2011 11:10:42 -0700 (PDT) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2bthomr14.btconnect.com with SMTP id CDJ10600; Fri, 18 Mar 2011 18:12:08 +0000 (GMT) Message-ID: <00f701cbe58e$effc57c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" References: <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> <001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net> <20110316111903.GA772@elstar.local> <01b501cbe3f5$41d59480$4001a8c0@gateway.2wire.net> <20110316173645.GA1468@elstar.local> Date: Fri, 18 Mar 2011 18:07:09 +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.0A0B0301.4D83A073.00BF, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4D83A07A.0126,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:10:46 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t.petch" Cc: "Bert (IETF) Wijnen" ; "Randy Presuhn" ; ; Sent: Wednesday, March 16, 2011 6:36 PM > On Wed, Mar 16, 2011 at 05:14:37PM +0100, t.petch wrote: > > > This memo does not specify any normalization of the user name as > > provided by or to the SSH layer. The same character display can be > > generated by different UTF-8 byte sequences which may give rise to > > the potential for attacks. See [RFC3629] for more details. > > This text would actually be wrong since there is no mandate whatsoever > that the username is encoded in UTF-8 when it is picked up. > > Randy's comment concerned comparions. I maintain my position that > NETCONF, more precisely 4741bis and 4742bis, does not do any > comparisons of the username. NACM will do so if there is a risk of > "surprising" comparisions, it should be fine this in NACM. > > If you have other concerns about the usage of XML encoded in UTF-8 in > NETCONF, you should start a new thread (and perhaps check that other > protocols using XML do explicitely deal with your concern). Juergen My primary concern, snipped from the extract above, is that the IESG wanted us to specify normalisation, the rough consensus as I see it is the Netconf does not do normalisation, therefore it would be good to record that in the I-D, lest this discussion crops up again in 6 (and 12 and 18 and ...:-) months. Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Mar 18 11:28:23 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB373A6A08 for ; Fri, 18 Mar 2011 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 MCEPdgi2HKPa for ; Fri, 18 Mar 2011 11:28:22 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8BAD83A69B7 for ; Fri, 18 Mar 2011 11:28:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kHvV/bv6CaIN6VUhG+QmixUwKc0oMaAn5b8a0ASfwJYHDOcJxuyagiyrf237LSgu; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.120] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Q0eQp-00061D-Rv for netconf@ietf.org; Fri, 18 Mar 2011 14:29:52 -0400 Message-ID: <000601cbe5a2$eb186be0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110309203436.GB43502@elstar.local><002c01cbded6$7567dde0$6801a8c0@oemcomputer><20110310070305.GA44468@elstar.iuhb02.iu-bremen.de><96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz><003601cbe360$9f3c8420$6801a8c0@oemcomputer><7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz><4D8071C3.5080202@bwijnen.net><001301cbe3c2$3716e900$4001a8c0@gateway.2wire.net><20110316111903.GA772@elstar.local><01b501cbe3f5$41d59480$4001a8c0@gateway.2wire.net><20110316173645.GA1468@elstar.local> <00f701cbe58e$effc57c0$4001a8c0@gateway.2wire.net> Date: Fri, 18 Mar 2011 11:30:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382640139a0393a910566697f0ce2625e00350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.120 Subject: Re: [Netconf] David Harrington's Discussondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:28:24 -0000 Hi - > From: "t.petch" > To: "Juergen Schoenwaelder" > Cc: > Sent: Friday, March 18, 2011 9:07 AM > Subject: Re: [Netconf] David Harrington's Discussondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) ... > My primary concern, snipped from the extract above, is that the IESG > wanted us to specify normalisation, the rough consensus as I see it > is the Netconf does not do normalisation, therefore it would be good > to record that in the I-D, lest this discussion crops up again in 6 (and > 12 and 18 and ...:-) months. ... I raised the normalization question; I don't recall seeing it in the IESG comments. Although I raised the issue, I don't support changing the text at this time. Even a seemingly innocuous statement like "NETCONF doesn't do normalization" is at odds with what some people have said on this list about their expectations, at least as far as *system* behaviour is concerned. Consequently I think the question needs additional implementation and (un)interoperability experience before it can properly be nailed down one way or the other, and this iteration should not be delayed while that learning is taking place. Randy From charliek@microsoft.com Sun Mar 20 23:30:05 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C173A67B1 for ; Sun, 20 Mar 2011 23:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+vh80VvXIUL for ; Sun, 20 Mar 2011 23:30:02 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 30E533A67CC for ; Sun, 20 Mar 2011 23:30:02 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 20 Mar 2011 23:31:34 -0700 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.22]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Sun, 20 Mar 2011 23:31:34 -0700 From: Charlie Kaufman To: "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-access-control-02 Thread-Index: AcvnhFqYRK//jHBzQpuJAtEsIb1Kfw== Date: Mon, 21 Mar 2011 06:31:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 21 Mar 2011 01:18:48 -0700 Subject: [Netconf] Comments on draft-ietf-netconf-access-control-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Mar 2011 06:30:05 -0000 I was recently reminded that I am listed as security advisor to the netconf= group and that there is an access control document that should be reviewed= by a security advisor. I probably shouldn't be security advisor to this gr= oup, and that might get corrected through other channels. An important role of a security advisor is to try to keep a group out of tr= ouble in the sense of having someone from the security space come in and di= srupt things at the last minute. That mostly involves not stepping on certa= in land mines along the way. I don't believe this document is likely to gen= erate such excitement (though you can never know for sure). Here are some t= houghts based in part on my experience in security and in part on what I've= seen blow up in IETF. I apologize for reviewing what I see now is the prev= ious version, but I doubt much has changed that would affect my comments. Access control is always messy. Authentication can be based on cryptographi= c algorithms and can be correct or have subtle bugs, and people "enjoy" spe= nding time debating arcane details around key sizes, approved algorithms, a= nd which of two equivalent variations is "better". Access control, on the o= ther hand, is a matter of figuring out how to be able to express all the th= ings you need to be able to express without making the statements so large = that no one can ever check them. Section 2 says "It should be easy to do si= mple things and hard to do complex things, instead of hard to do everything= ". The usual statement of that is that it should be easy to do simple thing= s and possible to do complex things. But in access control, nothing is ever= simple. What you really want is for it to be easy to do the things people = most frequently want to do and possible to do anything important. It's really a question of the scope of declarations. The "simplest" access = control model would be for each item and each operation on that item, a lis= t of the users permitted to perform that operation on that item is listed. = It's simple, but it's not easy because the volume of activity you would hav= e to go through to state a complete policy would be infeasible. The trick t= o a good access control model is correctly anticipating the groups of thing= s administrators are going to want to apply the same rules to and the group= s of users that administrators are going to want to give the same rights to= . I don't understand the full range of things NETCONF is likely to be used fo= r to say whether what's proposed here is a good model, but let me point out= some things that make me uneasy: Section 2.2 para 4: "Default access control policy needs to be as secure as= possible". There is a constant debate over whether the default access cont= rol policy should be the most locked down configuration anyone would possib= ly want or the policy people are most likely to want. This item seems to be= talking more about bootstrap situations: what should the policy be when yo= u take a new device out of the box and plug it in. Usually there is no safe= way to take a new device out of the box and safely put it on an open netwo= rk and configure it from there. That's because at that point, the device ca= n't distinguish a good guy from a bad guy. Usually, it's necessary to do so= me minimal configuration through some local (non-network) interface before = putting the device on the network or taking advantage of some special purpo= se hack like printing a factory password on the bottom of the device. Reset= ting to factory settings usually requires some physical access. Section 2.3 para 3: "YANG modules should be designed so that different acce= ss levels for input parameters to protocol operations is not required". Thi= s is saying that the permission to do something should be determined by the= operation and the object and not by any parameters. It sounds obvious, but= it actually constrains how operations are defined. It means that you can't= have a "generic" operation on an object that based on a parameter might be= a read or a write. It means that if there is a normal range of values for = a configuration parameter, it's not possible to require a higher level of a= uthority to set a value to outside the normal range than to set it within t= he normal range. If the operations that you have already defined follow thi= s pattern, and you don't anticipate new operations that break the pattern, = making such a restriction simplifies the access control model. But it's not= free. Section 2.4 para 5: "The non-volatile startup configuration needs to be loa= ded into the running configuration without applying any access control rule= s". The is a "restore factory settings" operation, which must be possible e= ven if the running configuration is arbitrarily broken in ways that would p= revent such an operation, but it is still a highly privileged operation... = doing this would require some sort of physical device override and dependin= g on what else is going on might require alarms, real time delays, or somet= hing else to make sure it is not part of an attack. Section 2.4.2 "Data nodes to which the client does not have 'read' access .= .. are silently omitted from the message." You need to decide w= hether this is done for convenience or for security. It says that if you tr= y to read a group of values and you don't have permission to read some of t= hem, those values are not returned. This can be a convenience measure becau= se you don't need to interrupt the return of a list with an error saying th= e permission is denied. Or it can be a security measure in that you can't l= earn of the existence of parameters unless you have permission to read them= . If you try to delete such an item, do you get a different error depending= on whether it exists or not? (i.e. access denied vs. named object not foun= d). It also can have bad side effects as noted at the end of section 2.4.4:= if you do a backup by reading everything, but some stuff is left out becau= se you did not have permission to read it, it would be good to get notified= at backup time that your backup has failed rather than discovering it at r= ecovery time when the objects you did not have permission to read are not r= estored. In section 2.4.3, by giving permissions on the base objects rather than on = the procedures that manipulate them, you lose some capabilities you might w= ant. For example, if you wanted to allow someone to move quotas around betw= een objects they controlled but not increase the total quotas of all of his= objects, you could write a "macro" procedure to do that. But if the permis= sions are enforced on all of the base objects independently, you could not = give out such "reshuffle" permissions. The use of the term "superuser" might turn out to be a land mine, in that t= here are lots of people who have gotten into lots of different kinds of tro= uble with such a feature, and calling it that is calling their attention to= it. Ideally, a system would be designed so that under normal circumstances= all administrators - even the most powerful ones - are configured to have = the permissions they need. You still need a mechanism for overriding those = permissions to deal with the case of misconfiguration where no one is autho= rized to perform some needed operation. You might be better off calling tha= t an "emergency recovery user" rather than superuser, clearly carrying the = implication that it is not for routine use. (That's just a word to the wise= ... in all probability you can use the term superuser and no one will compl= ain). In section 3.2.5, there is discussion of a global on/off switch for certain= categories of access control rule enforcement. It doesn't say whether when= access control is "off" whether all actions are allowed or whether all are= denied. I suspect from context that all are allowed. Clearly these are ext= remely dangerous settings; I would guess they exist for some sort of emerge= ncy recovery situation. I don't understand why there are four categories...= if you're going to throw security to the wind because the nuclear plant is= melting down and you want to allow anyone in the world to try to fix it, t= hat would argue for one big switch not four. It's also questionable whether= you want the feature at all. It would be equivalent to making all users su= perusers (er... emergency recovery users). A global switch that turned off = all ability to remotely change configuration settings regardless of credent= ials presented might make sense, but that didn't appear to be what was bein= g called for. In section 3.3.1: "There is no requirement to enforce access control rules = before or while the non-volatile configuration data is processed and loaded= into the running configuration". I hope that doesn't mean what it looks li= ke to me. You certainly don't want to say that while configuration data is = being loaded from a non-volatile store that anyone can in parallel make any= changes they want without access controls being applied. To the contrary, = I would expect you would want to lock out all other changes during the load= process. Restoring an old non-volatile configuration is an example of an o= peration you might want someone to be able to do even if they don't have pe= rmission to update all of the entries in the configuration independently. The document does not seem to deal with things that are "read-only data" wh= ere it makes no sense to try to modify it over the network because it is co= mputed by the system as a reflection of the system's state. Someone might b= e configured with permission to update such data, but an update wouldn't wo= rk. You should say whether you want to model that as an access control fail= ure or have the update silently ignored, or whatever. An example might be t= he case where you've done a complete backup of configuration state. When tr= ying to restore it, the read-only values can't be restored. What is the sys= tem supposed to do? Section 3.4.3 there are labels for "secure" and "very-secure". Reading the = text, it would appear that "very-secure" really means that reading the data= is security sensitive (as opposed to secure, where only updating it is sen= sitive). That's probably going to confuse people. You might consider read-s= ecure. Of for the pair "read-sensitive" and "write-sensitive". In the construction of "groups", there are really two kinds of groups: ther= e are groups of people, where you want to give all members of the group the= same permissions. These groups might naturally be defined by a more global= authentication system, where when someone authenticates you find out not j= ust who they are but get a list of groups they belong to. Alternately, you = might define the groups locally. The second kind of group is constructed to= fill the need that is often called a "role" in the access control communit= y. That is for the case where there are some things on the server where you= always want to control access to them in the same way. To do that, you wou= ld always define the group locally, and you would specify what users and ex= ternally defined groups are members of this locally defined group. For example, you might create an "administrators" group and a "performance = monitors" group locally and give those groups the appropriate access to ran= ges of resources. The intent would be that you would never update the polic= y concerning which of these groups had access to which resources, but you w= ould change the membership in the groups. You would not want such groups de= fined remotely because someone would be unlikely to be an administrator eve= rywhere. The set of administrators for each instance of the system would be= different. The ability to have group memberships defined either internally or external= ly is already allowed by the spec; you might want to make it explicit. Good luck with this. --Charlie From bertietf@bwijnen.net Mon Mar 21 01:49:54 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3EF3A67FB for ; Mon, 21 Mar 2011 01:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 vuEIj2OWPcfJ for ; Mon, 21 Mar 2011 01:49:53 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 8B8D63A67F9 for ; Mon, 21 Mar 2011 01:49:51 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Q1ap2-0006Ht-QS; Mon, 21 Mar 2011 09:51:21 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Q1ap2-0000CC-Kb; Mon, 21 Mar 2011 09:50:44 +0100 Message-ID: <4D871165.5020401@bwijnen.net> Date: Mon, 21 Mar 2011 09:50:45 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: 86ab03e524994f79ca2c75a176445dd46222fff71ad807ef67faf2aa0aae450c Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-access-control-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Mar 2011 08:49:55 -0000 Thanks Charlie. I trust that the editors/authors of the document will come back with a re= action. And other WG participantsm, Please chime in with your own viewponts/opini= ons/comments. Bert On 3/21/11 7:31 AM, Charlie Kaufman wrote: > I was recently reminded that I am listed as security advisor to the net= conf group and that there is an access control document that should be re= viewed by a security advisor. I probably shouldn't be security advisor to= this group, and that might get corrected through other channels. > > An important role of a security advisor is to try to keep a group out o= f trouble in the sense of having someone from the security space come in = and disrupt things at the last minute. That mostly involves not stepping = on certain land mines along the way. I don't believe this document is lik= ely to generate such excitement (though you can never know for sure). Her= e are some thoughts based in part on my experience in security and in par= t on what I've seen blow up in IETF. I apologize for reviewing what I see= now is the previous version, but I doubt much has changed that would aff= ect my comments. > > Access control is always messy. Authentication can be based on cryptogr= aphic algorithms and can be correct or have subtle bugs, and people "enjo= y" spending time debating arcane details around key sizes, approved algor= ithms, and which of two equivalent variations is "better". Access control= , on the other hand, is a matter of figuring out how to be able to expres= s all the things you need to be able to express without making the statem= ents so large that no one can ever check them. Section 2 says "It should = be easy to do simple things and hard to do complex things, instead of har= d to do everything". The usual statement of that is that it should be eas= y to do simple things and possible to do complex things. But in access co= ntrol, nothing is ever simple. What you really want is for it to be easy = to do the things people most frequently want to do and possible to do any= thing important. > > It's really a question of the scope of declarations. The "simplest" acc= ess control model would be for each item and each operation on that item,= a list of the users permitted to perform that operation on that item is = listed. It's simple, but it's not easy because the volume of activity you= would have to go through to state a complete policy would be infeasible.= The trick to a good access control model is correctly anticipating the g= roups of things administrators are going to want to apply the same rules = to and the groups of users that administrators are going to want to give = the same rights to. > > I don't understand the full range of things NETCONF is likely to be use= d for to say whether what's proposed here is a good model, but let me poi= nt out some things that make me uneasy: > > Section 2.2 para 4: "Default access control policy needs to be as secur= e as possible". There is a constant debate over whether the default acces= s control policy should be the most locked down configuration anyone woul= d possibly want or the policy people are most likely to want. This item s= eems to be talking more about bootstrap situations: what should the polic= y be when you take a new device out of the box and plug it in. Usually th= ere is no safe way to take a new device out of the box and safely put it = on an open network and configure it from there. That's because at that po= int, the device can't distinguish a good guy from a bad guy. Usually, it'= s necessary to do some minimal configuration through some local (non-netw= ork) interface before putting the device on the network or taking advanta= ge of some special purpose hack like printing a factory password on the b= ottom of the device. Resetting to factory settings usually requires some = physical access. > > Section 2.3 para 3: "YANG modules should be designed so that different = access levels for input parameters to protocol operations is not required= ". This is saying that the permission to do something should be determine= d by the operation and the object and not by any parameters. It sounds ob= vious, but it actually constrains how operations are defined. It means th= at you can't have a "generic" operation on an object that based on a para= meter might be a read or a write. It means that if there is a normal rang= e of values for a configuration parameter, it's not possible to require a= higher level of authority to set a value to outside the normal range tha= n to set it within the normal range. If the operations that you have alre= ady defined follow this pattern, and you don't anticipate new operations = that break the pattern, making such a restriction simplifies the access c= ontrol model. But it's not free. > > Section 2.4 para 5: "The non-volatile startup configuration needs to be= loaded into the running configuration without applying any access contro= l rules". The is a "restore factory settings" operation, which must be po= ssible even if the running configuration is arbitrarily broken in ways th= at would prevent such an operation, but it is still a highly privileged o= peration... doing this would require some sort of physical device overrid= e and depending on what else is going on might require alarms, real time = delays, or something else to make sure it is not part of an attack. > > Section 2.4.2 "Data nodes to which the client does not have 'read' acce= ss ... are silently omitted from the message." You need to de= cide whether this is done for convenience or for security. It says that i= f you try to read a group of values and you don't have permission to read= some of them, those values are not returned. This can be a convenience m= easure because you don't need to interrupt the return of a list with an e= rror saying the permission is denied. Or it can be a security measure in = that you can't learn of the existence of parameters unless you have permi= ssion to read them. If you try to delete such an item, do you get a diffe= rent error depending on whether it exists or not? (i.e. access denied vs.= named object not found). It also can have bad side effects as noted at t= he end of section 2.4.4: if you do a backup by reading everything, but so= me stuff is left out because you did not have permission to read it, it w= ould be good to get notified at backup time that your backup has failed r= ather than discovering it at recovery time when the objects you did not h= ave permission to read are not restored. > > In section 2.4.3, by giving permissions on the base objects rather than= on the procedures that manipulate them, you lose some capabilities you m= ight want. For example, if you wanted to allow someone to move quotas aro= und between objects they controlled but not increase the total quotas of = all of his objects, you could write a "macro" procedure to do that. But i= f the permissions are enforced on all of the base objects independently, = you could not give out such "reshuffle" permissions. > > The use of the term "superuser" might turn out to be a land mine, in th= at there are lots of people who have gotten into lots of different kinds = of trouble with such a feature, and calling it that is calling their atte= ntion to it. Ideally, a system would be designed so that under normal cir= cumstances all administrators - even the most powerful ones - are configu= red to have the permissions they need. You still need a mechanism for ove= rriding those permissions to deal with the case of misconfiguration where= no one is authorized to perform some needed operation. You might be bett= er off calling that an "emergency recovery user" rather than superuser, c= learly carrying the implication that it is not for routine use. (That's j= ust a word to the wise... in all probability you can use the term superus= er and no one will complain). > > In section 3.2.5, there is discussion of a global on/off switch for cer= tain categories of access control rule enforcement. It doesn't say whethe= r when access control is "off" whether all actions are allowed or whether= all are denied. I suspect from context that all are allowed. Clearly the= se are extremely dangerous settings; I would guess they exist for some so= rt of emergency recovery situation. I don't understand why there are four= categories... if you're going to throw security to the wind because the = nuclear plant is melting down and you want to allow anyone in the world t= o try to fix it, that would argue for one big switch not four. It's also = questionable whether you want the feature at all. It would be equivalent = to making all users superusers (er... emergency recovery users). A global= switch that turned off all ability to remotely change configuration sett= ings regardless of credentials presented might make sense, but that didn'= t appear to be what was being called for. > > In section 3.3.1: "There is no requirement to enforce access control ru= les before or while the non-volatile configuration data is processed and = loaded into the running configuration". I hope that doesn't mean what it = looks like to me. You certainly don't want to say that while configuratio= n data is being loaded from a non-volatile store that anyone can in paral= lel make any changes they want without access controls being applied. To = the contrary, I would expect you would want to lock out all other changes= during the load process. Restoring an old non-volatile configuration is = an example of an operation you might want someone to be able to do even i= f they don't have permission to update all of the entries in the configur= ation independently. > > The document does not seem to deal with things that are "read-only data= " where it makes no sense to try to modify it over the network because it= is computed by the system as a reflection of the system's state. Someone= might be configured with permission to update such data, but an update w= ouldn't work. You should say whether you want to model that as an access = control failure or have the update silently ignored, or whatever. An exam= ple might be the case where you've done a complete backup of configuratio= n state. When trying to restore it, the read-only values can't be restore= d. What is the system supposed to do? > > Section 3.4.3 there are labels for "secure" and "very-secure". Reading = the text, it would appear that "very-secure" really means that reading th= e data is security sensitive (as opposed to secure, where only updating i= t is sensitive). That's probably going to confuse people. You might consi= der read-secure. Of for the pair "read-sensitive" and "write-sensitive". > > In the construction of "groups", there are really two kinds of groups: = there are groups of people, where you want to give all members of the gro= up the same permissions. These groups might naturally be defined by a mor= e global authentication system, where when someone authenticates you find= out not just who they are but get a list of groups they belong to. Alter= nately, you might define the groups locally. The second kind of group is = constructed to fill the need that is often called a "role" in the access = control community. That is for the case where there are some things on th= e server where you always want to control access to them in the same way.= To do that, you would always define the group locally, and you would spe= cify what users and externally defined groups are members of this locally= defined group. > > For example, you might create an "administrators" group and a "performa= nce monitors" group locally and give those groups the appropriate access = to ranges of resources. The intent would be that you would never update t= he policy concerning which of these groups had access to which resources,= but you would change the membership in the groups. You would not want su= ch groups defined remotely because someone would be unlikely to be an adm= inistrator everywhere. The set of administrators for each instance of the= system would be different. > > The ability to have group memberships defined either internally or exte= rnally is already allowed by the spec; you might want to make it explicit= =2E > > Good luck with this. > > --Charlie > > > > From biermana@Brocade.com Mon Mar 21 09:44:39 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8BE28C16D for ; Mon, 21 Mar 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.114, 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 XFYn4HQiXi15 for ; Mon, 21 Mar 2011 09:44:38 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 089B628C16A for ; Mon, 21 Mar 2011 09:44:37 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p2LGfsT8005185; Mon, 21 Mar 2011 09:46:10 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id v5tj5rvfd-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2011 09:46:10 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Mar 2011 09:53:29 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 21 Mar 2011 09:45:44 -0700 From: Andy Bierman To: Martin Bjorklund , "netconf@ietf.org" Date: Mon, 21 Mar 2011 09:45:44 -0700 Thread-Topic: [Netconf] nacm proposal Thread-Index: AcvhwlhIGUTkUJDgT3uq8mClTw6BjAGIjjRA Message-ID: References: <20110313.220429.177715851.mbj@tail-f.com> In-Reply-To: <20110313.220429.177715851.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=2011-03-21_05:2011-03-16, 2011-03-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103210103 Subject: Re: [Netconf] nacm proposal X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Mar 2011 16:44:39 -0000 Hi, I like this new proposal, but I have 1 more optimization to suggest: It would be good if the same rule could apply to multiple accessible nodes to reduce configuration complexity. Specifically, in the choice rule-type, if there were leaf-lists instead of leafs (leaf-list rpc-name, notification-name, path), as in this example: rule-list write-config { allowed-group [ wheel admin ]; rule allow-editops { module-name ietf-netconf; rpc-name edit-config; rpc-name copy-config; rpc-name delete-config; rpc-name commit; rpc-name discard-changes; access-rights [exec]; action permit; } } rule-list read-config { allowed-group *; module-name ietf-netconf; rpc-name get; rpc-name get-config; access-rights [exec]; action permit; } rule-list deny-edit-catch-all { allowed-group *; module-name ietf-netconf; rpc-name *; access-rights [exec]; action deny; } Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Sunday, March 13, 2011 2:04 PM To: netconf@ietf.org Subject: [Netconf] nacm proposal Hi, Below is a proposal for some changes to NACM to make it easier to use, that I will present in Prague. It is common to think and configure role based access control in terms of features or tasks. A task/feature can be 'routing', 'system', or 'vpn-admin' etc. There are two problems involved when such tasks are mapped to nacm.=20 One problem is that it is difficult to understand which individual rules in larger configurations belong together, because there is just a single list with all rules (of a certain type). This makes it more difficult to maintain the rules. The other problem is that a certain task might involve rules of different types, thus the rules will be spread out in up to four different lists (module-rule, rpc-rule, data-rule, and notification-rule), which makes it even more difficult to understand and maintain the rules. The following proposal changes the structure of the rules a bit, in order to make it easier to create, understand, and maintain access control rules. It does not change the underlying execution model of rules; i.e. it is equivalent in expressive power to the current document. The idea is that we introduce named "rule-lists". A rule-list is a named collection of rules, and it can be shared among different groups. Instead of four different rules lists, there is just one, where the different rule types are done with a choice. Here's an example, using a YANG-like syntax for the content, instead of XML: rule-list networking { allowed-group [ wheel admin ]; rule allow-ietf-interface { module-name "ietf-interface"; access-rights *; action permit; } rule deny-reset { module-name "acme-ethernet-interface"; rpc-name "reset-interface"; access-rights [ execute ]; action deny; } rule allow-acme-ethernet { path "/if:interfaces/if:interface/acme:eth-config"; access-rights [ read update notify ]; action permit; } } Using this, a "task" can be represented as a rule-list, and a large configuration can be broken down into manageable tasks. Here's a compact representation of the rule-list: +--rw nacm +--rw rule-list [name] +--rw name string +--rw allowed-group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(rpc) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(path) | +--rw path schema-instance-identifier +--rw access-rights union +--rw action nacm-action-type And the YANG definition of the rule-list: container nacm { list rule-list { key "name"; ordered-by user; description "A named list of access control rules."; leaf name { type string { length "1..255"; } description "Arbitrary name assigned to this access control rule list."; } leaf-list allowed-group { type union { type nacm-matchall-string-type; type nacm-group-name-type; } min-elements 1; description "List of administrative groups which will be assigned the associated access rights for the content specified by the associated path. The string '*' indicates that all configured administrative groups apply to the entry."; } =20 list rule { key "name"; ordered-by user; description "Rules are processed in user-defined order until a match is found. A rule matches if 'module-name' and 'rule-type' matches the request. If a rule matches, the 'action' leaf determines if access is granted or not."; leaf name { type string { length "1..255"; } description "Arbitrary name assigned to the access control rule."; } =20 // match on these leafs... leaf module-name { type union { type nacm-matchall-string-type; type string; } default "*"; description "This leaf matches if it has the value '*', or if the object being accessed is defined in the module with the specified module name."; } choice rule-type { description "The choice matches if all leafs present in the rule matches the request. If no leafs are present, the choice matches the request."; case rpc { leaf rpc-name { type union { type nacm-matchall-string-type; type string; } description "This leaf matches if its value equals the requested RPC operation name."; } } case notification { leaf notification-name { type union { type nacm-matchall-string-type; type string; } description "This leaf matches if its value equals the requested notification name."; } } case path { leaf path { type schema-instance-identifier; mandatory true; description "Schema Instance Identifier associated with the data node controlled by this rule. Configuration data or state data instance identifiers start with a top-level data node. A complete instance identifier is required for this type of path value. The special value '/' refers to all possible database contents."; } } } leaf access-rights { type union { type nacm-matchall-string-type; type nacm-rights-type; } mandatory true; description "List of access rights granted to specified administrative groups for the content specified by the associated path."; } leaf action { type nacm-action-type; mandatory true; description "The access control action associated with the rule. If a rule is determined to match a particular request, then this object is used to determine whether to permit or deny the request."; } } } } Open issues: 1. Should it be possible for a rule-list to contain not just other rules, but also other rule-lists? This would make it easier to build rule-lists out of smaller reusable pieces. 2. Would it be useful with any objects to help debug nacm? E.g. an rpc to get all rules for a given group, or an rpc to check if a certain path will be permitted or denied for a given group, which also returns a trace of the rules tried that the execution pattern can be traced? =20 /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From alexey.melnikov@isode.com Fri Mar 25 01:18:39 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52F728C0EA; Fri, 25 Mar 2011 01:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 Y5k0Thk-OJK7; Fri, 25 Mar 2011 01:18:18 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0442C3A6982; Fri, 25 Mar 2011 01:18:18 -0700 (PDT) Received: from [192.168.192.13] (feldconf.feld.cvut.cz [147.32.192.240]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 Mar 2011 08:19:52 +0000 Message-ID: <4D8B57C6.9000207@isode.com> Date: Thu, 24 Mar 2011 15:40:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Bert (IETF) Wijnen" References: <20110315094214.27061.45421.idtracker@localhost> <4D7F3E10.6050806@bwijnen.net> In-Reply-To: <4D7F3E10.6050806@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-netconf-4741bis@tools.ietf.org, Netconf , netconf-chairs@tools.ietf.org, The IESG Subject: Re: [Netconf] Alexey Melnikov's Yes on draft-ietf-netconf-4741bis-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 08:18:39 -0000 Bert (IETF) Wijnen wrote: > Inline > > On 3/15/11 10:42 AM, Alexey Melnikov wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-netconf-4741bis-10: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I am balloting Yes, but please check a couple of remaining comments. >> > Thank you. > >> 4.3. Element >> >> error-tag: Contains a string identifying the error condition. See >> Appendix A for allowed values. >> >> Is the list of error conditions extensible? If yes, where can they be >> found? If not, it would be better to be explicit about this, in >> particular the document should mention that addition of a new error >> tag value would require capability version increment. >> > Mmm... My understanding was that this was addressed. > See email between you and Martin: > > 4.3. Element > > >> > > >> error-tag: Contains a string identifying the error > condition. See > > >> Appendix A for allowed values. > > >> > > >>Is the list of error conditions extensible? If yes, where can > they be found? > > >> > > > > > >No. These are fixed in the Appendex, and in the XSD. > > > > > So is that still not good enough? I would like to see a sentence on this in Section 4.3. > > I think an explicit statement that any changes to the list need > a new > > capability name (version) would be good. > > > > Additionally, can you please check if any issues from > > > > need > > to be addressed? > > Yes, most of these issues are already address in -09. > > > /martin > >> 7.8. >> >> Negative Response: >> >> An element is included in the if the >> request cannot be completed for any reason. >> >> How is this possible? What can the client do next if the operation >> fails? > > The discussion between you and MArtin: > > 7.8. > > > Negative Response: > > > An element is included in > the if the > > request cannot be completed for any reason. > > > How is this possible? What can the client do next if the > operation fails? > > Good catch. The only reason would be if the request is mal-formed, > e.g. contains a unexpected parameter: > > > 42 > > > so i guess that is the explanation. > Was that not sufficient? > > Martin, did we add some other text that would make this clear? I haven't seen any change in the document. >> [I haven't checked if the following were addressed:] >> I am also agreeing with David's DISCUSS points # 1 and # 2, and I >> also think that Peter's Comment point # 1 is worth being DISCUSS level. > > > We have also responded to David's DISCUSS< see my posting (with copy > to IESG list) this morning. > We hope he will clear his DISCUSS too. > > I also believe we have addressed Peter's 1st comment, see changes to > section 3. Ok, great. From bertietf@bwijnen.net Fri Mar 25 02:01:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209AB3A6985; Fri, 25 Mar 2011 02:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 JyO2ptp0ZhGV; Fri, 25 Mar 2011 02:01:41 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 586FF3A6839; Fri, 25 Mar 2011 02:01:39 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Q32vF-0006gf-E6; Fri, 25 Mar 2011 10:03:11 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Q32vF-0001ZR-9Z; Fri, 25 Mar 2011 10:03:09 +0100 Message-ID: <4D8C5A4D.3010801@bwijnen.net> Date: Fri, 25 Mar 2011 10:03:09 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <20110315094214.27061.45421.idtracker@localhost> <4D7F3E10.6050806@bwijnen.net> <4D8B57C6.9000207@isode.com> In-Reply-To: <4D8B57C6.9000207@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f7b9b25c42329401f0a8d8412890b265 Cc: draft-ietf-netconf-4741bis@tools.ietf.org, Netconf , netconf-chairs@tools.ietf.org, The IESG Subject: Re: [Netconf] Alexey Melnikov's Yes on draft-ietf-netconf-4741bis-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 09:01:42 -0000 Inline, On 3/24/11 3:40 PM, Alexey Melnikov wrote: > Bert (IETF) Wijnen wrote: > >> Inline >> >> On 3/15/11 10:42 AM, Alexey Melnikov wrote: >> >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-netconf-4741bis-10: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I am balloting Yes, but please check a couple of remaining comments. >>> >> Thank you. >> >>> 4.3. Element >>> >>> error-tag: Contains a string identifying the error condition. See >>> Appendix A for allowed values. >>> >>> Is the list of error conditions extensible? If yes, where can they be found? If not, it would be better to be explicit about >>> this, in particular the document should mention that addition of a new error tag value would require capability version increment. >>> >> Mmm... My understanding was that this was addressed. >> See email between you and Martin: >> >> 4.3. Element >> > >> >> > >> error-tag: Contains a string identifying the error condition. See >> > >> Appendix A for allowed values. >> > >> >> > >>Is the list of error conditions extensible? If yes, where can they be found? >> > >> > > >> > >No. These are fixed in the Appendex, and in the XSD. >> > > >> >> So is that still not good enough? > > I would like to see a sentence on this in Section 4.3. > Mmmm with all due respect, I do not really see why that is needed. We have it in the specific definition in Appendix A, and I think that "See Appendix A for allowed values" is a pretty definite statement, is it not. Why add more text aka "extensions are not possible"? We could also add "and there it never rains in California"... sorry, couldn't resist. >> > I think an explicit statement that any changes to the list need a new >> > capability name (version) would be good. >> > > > Additionally, can you please check if any issues from >> > need >> > to be addressed? >> >> Yes, most of these issues are already address in -09. >> >> >> /martin >> >>> 7.8. >>> >>> Negative Response: >>> >>> An element is included in the if the >>> request cannot be completed for any reason. >>> >>> How is this possible? What can the client do next if the operation fails? >> >> The discussion between you and MArtin: >> >> 7.8. >> > > Negative Response: >> > > An element is included in the if the >> > request cannot be completed for any reason. >> > > How is this possible? What can the client do next if the operation fails? >> >> Good catch. The only reason would be if the request is mal-formed, >> e.g. contains a unexpected parameter: >> >> >> 42 >> >> >> so i guess that is the explanation. >> Was that not sufficient? >> >> Martin, did we add some other text that would make this clear? > > I haven't seen any change in the document. > I reread this thread and the section 7.8 and discussed it with Martin, The close session allows a client to nicely close a session after which it can terminate the session/connection. We actually expect that many clients may not even check if there is an error (or any) return message. The client decides it is done (for whatever reason), then informs the server that it is going to close the session, so the server can (if possible) cleanup and that is it. In any event, I bet that the client then terminates the session/connection. It seems so logical to me that I do not really see we need to add any text here. Bert document shepherd. From bertietf@bwijnen.net Fri Mar 25 02:06:12 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF8E3A6985 for ; Fri, 25 Mar 2011 02:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 uWyYe7ISijHC for ; Fri, 25 Mar 2011 02:06:11 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id EB4583A6839 for ; Fri, 25 Mar 2011 02:06:10 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Q32zg-0006mq-4I for netconf@ietf.org; Fri, 25 Mar 2011 10:07:45 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest184.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Q32zf-0001yj-V5 for netconf@ietf.org; Fri, 25 Mar 2011 10:07:44 +0100 Message-ID: <4D8C5B5F.5030002@bwijnen.net> Date: Fri, 25 Mar 2011 10:07:43 +0100 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: netconf@ietf.org References: <201103091334.p29DYX1F016190@idle.juniper.net> <003c01cbde84$f7e01be0$6801a8c0@oemcomputer> <20110309203436.GB43502@elstar.local> <002c01cbded6$7567dde0$6801a8c0@oemcomputer> <20110310070305.GA44468@elstar.iuhb02.iu-bremen.de> <96352571-5E2F-4BB8-8446-918DD8558F4D@cesnet.cz> <003601cbe360$9f3c8420$6801a8c0@oemcomputer> <7BF2D607-99F0-41D9-9D10-4B08E414609F@cesnet.cz> <4D8071C3.5080202@bwijnen.net> <4D832AD5.1010102@bwijnen.net> In-Reply-To: <4D832AD5.1010102@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4a20cbcfb63bcae2249fb90f7a898a4e4 Subject: Re: [Netconf] draft-ietf-netconf-4741bis-10 is finished and ready to go to RFC-Editor X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2011 09:06:12 -0000 OK, having had a few more "support" statements I conclude that we have consensus to move forward and not make any more changes. I will move forward and ask Dan to send the documents on to the RFC-Editor. As you can see on the netconf list, Alexey still wanted 2 small (editorial) changes, but they are considered IESG COMMENTS, and I think it is not needed (as you can see in my response to Aleaxey). Bert document shepherd On 3/18/11 10:50 AM, Bert (IETF) Wijnen wrote: > From the discussion on the below in which only a few have participated sofar, > we (WG chairs) conclude that we are done with 4741bis and that if any text > is needed to address this, then it would probably go into one of > the NACM documents, but not in 4741bis. > > Both chairs (as technical contributors) also support this position. > > Bert and Mehmet > > On 3/16/11 9:16 AM, Bert (IETF) Wijnen wrote: > -------- Original Message -------- > Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) > Date: Wed, 16 Mar 2011 09:16:03 +0100 > From: Bert (IETF) Wijnen > To: Randy Presuhn > CC: ietfdbh@comcast.net, netconf@ietf.org > > >> Hi all, >> >> I have taken off IESG and the log for 4741bis email addresses. >> The topic was/is not part of any IESG DISCUSS or COMMENT. >> >> I did this, because I am not sure this is a problem we should try to address >> in this revision of rfc4741bis. >> AS Lada stated, we can (for now at least I think) assume that two different >> sequences are different users. As far as we know, it has not caused any >> practical problem. >> >> Perfect is the enemy of good (enough). I (personally) would not want to hold >> up this document any longer in order to try and make sure everyone understands >> the details of this thread/discussion and is able to express an informed >> opinion on what to do. >> >> I suggest that for now we conclude: it is a conscious OK to consider two >> different character sequences as different usernames. >> >> If anyone dis-agrees, please speak up asap. >> >> Bert Wijnen >> document shepherd >> >> >> On 3/16/11 8:18 AM, Ladislav Lhotka wrote: >>> On Mar 15, 2011, at 11:30 PM, Randy Presuhn wrote: >>> >>>> Hi - >>>> >>>>> From: "Ladislav Lhotka" >>>>> To: "Juergen Schoenwaelder" >>>>> Cc: "Randy Presuhn";;; >>>> ;; >>>>> Sent: Tuesday, March 15, 2011 2:50 AM >>>>> Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) >>>>> >>>>> On Mar 10, 2011, at 8:03 AM, Juergen Schoenwaelder wrote: >>>>> >>>>>> On Wed, Mar 09, 2011 at 07:51:35PM -0800, Randy Presuhn wrote: >>>>>> >>>>>>> Let me re-ask the question with an example. >>>>>>> How are implementations required to treat the sequence >>>>>>> U+0061 U+0308 and U+00E4 in user names? Are they >>>>>>> identical, different, or is the answer implementation-specific? >>>>>>> (Both are "ä".) >>>>>> See why I avoid these characters. ;-) I see your point but whatever >>>>>> the answer is, it really needs to be answered for the YANG string data >>>>>> type. >>>>> I don't think the YANG string type has to be changed. As long as >>>>> we deal with strings inside NETCONF protocol messages, >>>>> everything is fine. The present problem is with strings that are >>>>> obtained via other channels and this is out of scope for YANG. >>>> "Other channels" isn't the question. >>>> Is the a string consisting of the sequence U+0061 U+0308 equal >>>> to one consisting of U+00E4? Are two configurations which differ >>>> only in this way "the same" configuration? >>> Neither XML 1.0 nor YANG assumes any character model normalization, so IMO the two sequences are different. >>> >>> Lada >>> >>>> Randy >>>> >>>> >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From iesg-secretary@ietf.org Fri Mar 25 06:53:15 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8C53A68B1; Fri, 25 Mar 2011 06:53:15 -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 0pmFKg3387fi; Fri, 25 Mar 2011 06:53:14 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2BE28C0F4; Fri, 25 Mar 2011 06:53:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110325135314.23044.54263.idtracker@localhost> Date: Fri, 25 Mar 2011 06:53:14 -0700 Cc: Internet Architecture Board , netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Network Configuration Protocol (NETCONF)' to Proposed Standard (draft-ietf-netconf-4741bis-10.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, 25 Mar 2011 13:53:15 -0000 The IESG has approved the following document: - 'Network Configuration Protocol (NETCONF)' (draft-ietf-netconf-4741bis-10.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ Technical Summary The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as Remote Procedure Calls (RPC). This revision of the document clarifies some text and fixes some minor bugs (including reported rfc4741 errata) as found from implementatition experience of rfc4741. Working Group Summary The working group went over several versions of the document. The comments and reviews helped improve the document a lot and brought to consensus on the 6th revision of the document. Document Quality There are several implementations of this protocol, and in fact the rfc4741bis revision is based on implementation experience. Personnel Bert Wijnen is the Document Shepherd for this document? Dan Romascanu is the Responsible Area Director. From dromasca@avaya.com Fri Mar 25 10:14:31 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1A93A67EC for ; Fri, 25 Mar 2011 10:14:31 -0700 (PDT) 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.509, BAYES_00=-2.599, 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 00jCNdIfex3h for ; Fri, 25 Mar 2011 10:14:31 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id AC9AC3A67E5 for ; Fri, 25 Mar 2011 10:14:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.63,244,1299474000"; d="scan'208";a="238551592" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Mar 2011 13:16:04 -0400 X-IronPort-AV: E=Sophos;i="4.63,244,1299474000"; d="scan'208";a="630066413" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Mar 2011 13:16:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Mar 2011 18:15:41 +0100 Message-ID: In-Reply-To: <20110325135314.23044.54263.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'Network Configuration Protocol(NETCONF)' to Proposed Standard (draft-ietf-netconf-4741bis-10.txt) Thread-Index: Acvq9Dnt+yzgHMWWRXu37+N2ykNTIgAG8zgg References: <20110325135314.23044.54263.idtracker@localhost> From: "Romascanu, Dan (Dan)" To: "netconf" Subject: Re: [Netconf] Protocol Action: 'Network Configuration Protocol(NETCONF)' to Proposed Standard (draft-ietf-netconf-4741bis-10.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, 25 Mar 2011 17:14:32 -0000 Hi,=20 Thanks and Congratulations to the editors, contributors, chairs and the whole WG for achieving this target.=20 Regards, Dan=20 =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, March 25, 2011 3:53 PM > To: IETF-Announce > Cc: Internet Architecture Board; netconf mailing list;=20 > netconf chair; RFC Editor > Subject: [Netconf] Protocol Action: 'Network Configuration=20 > Protocol(NETCONF)' to Proposed Standard=20 > (draft-ietf-netconf-4741bis-10.txt) >=20 > The IESG has approved the following document: > - 'Network Configuration Protocol (NETCONF)' > (draft-ietf-netconf-4741bis-10.txt) as a Proposed Standard >=20 > This document is the product of the Network Configuration=20 > Working Group. >=20 > The IESG contact persons are Dan Romascanu and Ron Bonica. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > The Network Configuration Protocol (NETCONF) defined in=20 > this document > provides mechanisms to install, manipulate, and delete the > configuration of network devices. It uses an Extensible Markup > Language (XML)-based data encoding for the configuration=20 > data as well > as the protocol messages. The NETCONF protocol operations are > realized as Remote Procedure Calls (RPC). >=20 > This revision of the document clarifies some text and > fixes some minor bugs (including reported rfc4741 errata) > as found from implementatition experience of rfc4741. >=20 >=20 > Working Group Summary >=20 > The working group went over several versions of the > document. The comments and reviews helped improve the > document a lot and brought to consensus on the > 6th revision of the document. >=20 > Document Quality >=20 > There are several implementations of this protocol, and in fact > the rfc4741bis revision is based on implementation > experience.=20 >=20 > Personnel >=20 > Bert Wijnen is the Document Shepherd for this document? Dan=20 > Romascanu is the Responsible Area Director. =20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From iesg-secretary@ietf.org Fri Mar 25 10:42:28 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B19F3A680C; Fri, 25 Mar 2011 10:42:28 -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 oOxX-uuO-5Wd; Fri, 25 Mar 2011 10:42:26 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58AE93A680A; Fri, 25 Mar 2011 10:42:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110325174226.15086.9307.idtracker@localhost> Date: Fri, 25 Mar 2011 10:42:26 -0700 Cc: Internet Architecture Board , netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' to Proposed Standard (draft-ietf-netconf-rfc4742bis-08.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, 25 Mar 2011 17:42:28 -0000 The IESG has approved the following document: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' (draft-ietf-netconf-rfc4742bis-08.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/ Technical Summary This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. Working Group Summary This document has been longly discussed in the Working Group, including several WG Last Calls. The comments and reviews helped to improve the document a lot and the current version reflects the consensus of the WG. The document incorporates all accepted errata against RFC4742. After a long debate the WG decided to have the way a NETCONF Server extracts the SSH user name from the SSH layer as implementation-dependent. There was a long discussion on the handling of the EOM character sequence. As the workgroup had only a mandate for bug fixing the workgroup first agreed to keep using the EOM sequence to avoid incompatibility with existing implementations. After the discussion on this issue in IETF #79 a few WG members proposed to figure out if a proper framing solution can be found now, while being backwards compatible with the rfc4742. The old EOM framing has been seen as not secure enough: - RFC4742 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. NETCONF co-chairs agreed to consider a solution only if there is a real WG consensus (i.e. near 100%) on such a change. First a possible solution has been discussed in a small team, which included most of the implementers for NETCONF-related tools and protocol code. The solution proposes to encode all NETCONF messages with a chunked framing (similar but not equal to HTTP chunked framing). The document still uses the EOM sequence for the initial message to avoid incompatibility with existing implementations. NETCONF co-chairs asked the AD to hold the documents for 4741bis and 4742bis for a short period of time and the result of the discussion in the small team has been sent to the WG for consensus. Some of the discussion points were: - The proposal makes it a little bit harder to do just an SSH-session and then do cut-and-paste input. The implementers 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. - It came out that less experienced implementers find it as helpful to see the "invisible LineFeed" in the examples. The WG concluded that '\n' is the most common character for this purpose. One WG member though was against '\n' and wanted to use '}', which has been noted. - One WG member didn't want to stick the usage of the Chunked Framing Mechanism to capability "base:1.1" only and wanted rather to state ":base:1.1 or later". The WG concluded that we should stick to "base:1.1" and extend it with a new version, which most likely will introduce other changes. The changes have been accepted by the WG with some additional discussion and bug fixing. As the result of the WG discussion the WG co-chairs concluded near FULL consensus on the proposed edits and started a WGLC. The WGLC did raise only minor issues. After a short discussion in a small team including the WG co-chairs, the editor of 4742bis Margaret Wasserman, editors of 4741bis Martin Bjorklund, Andy Bierman and Juergen Schoenwaelder the document shepherd sent the collected bug fixing and change requests to NETCONF ML and announced it as the result of the WG last call. Document Quality Since SSH is mandatory transport for NETCONF there are numerous implementations of RFC 4742. It is expected that existing implementations will be updated based on the 4742bis document once it gets published as proposed standard. Personnel Mehmet Ersue is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note Please make the following changes: 1. Please reinstate Appendix A from version 07 (accidentally dropped) Appendix A. Changes from RFC 4742 This section lists major changes between this document and RFC 4742. o Introduced the new Chunked Framing Mechanism to solve known security issues with the EOM framing. o Extended text in Security Considerations, added text on EOM issues. o Added examples to show new chunked encoding properly, highlighted the location of new lines. o Added text for NETCONF username handling following the requirements on usernames in [I-D.ietf-netconf-4741bis]. o Changed use of the terms client/server, manager/agent to SSH client/server and NETCONF client/server. o Consistently used the term operation, instead of command or message. o Integrated previously-approved errata from http://rfc-editor.org/errata_search.php?rfc=4742 2. in Section 3.1. OLD (v08): As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST indicate its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server. As [I-D.ietf-netconf-4741bis] states the NETCONF client must also send an XML document containing a element to indicate the NETCONF client's capabilities to the NETCONF server. The document containing the element MUST be the first XML document that the NETCONF client sends after the NETCONF session is established. NEW: As specified in [I-D.ietf-netconf-4741bis] the NETCONF server indicates its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server. As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client also sends an XML document containing a element to indicate the NETCONF client's capabilities to the NETCONF server. The document containing the element is the first XML document that the NETCONF client sends after the NETCONF session is established. From rohitpobbathi@huawei.com Fri Mar 25 19:49:46 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1A93A6892 for ; Fri, 25 Mar 2011 19:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FR_3TAG_3TAG=1.758, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KnWzuC3ItUH for ; Fri, 25 Mar 2011 19:49:45 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1C5193A6868 for ; Fri, 25 Mar 2011 19:49:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIN002J59950Y@szxga04-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 10:51:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIN00F41995O7@szxga04-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 10:51:05 +0800 (CST) Received: from BLRNSHTIPL8NC ([10.18.1.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIN000H0994UJ@szxml04-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 10:51:05 +0800 (CST) Date: Sat, 26 Mar 2011 08:21:04 +0530 From: Rohit A Pobbathi In-reply-to: <20110216.094031.68035565067234869.mbj@tail-f.com> To: 'Martin Bjorklund' , biermana@Brocade.com Message-id: <15AD05AC74F54E35ADD2244500B0290B@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High Thread-index: AcvNtTtt4ZBzuJwxSzmN7/ZLbq9yeQdqpdUg Cc: netconf@ietf.org Subject: [Netconf] Require Clarifications ///RE: Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Mar 2011 02:49:46 -0000 Dear Martin, Thanks for your inputs to my queries. I still have some questions regarding the handling of EMPTY tag in operation. 1. You have mentioned In an , means that the mtu leaf should be set to the value "", or created if it was of type 'empty'. My Query: Here I am considering mtu leaf as a field in a table. How to treat value "" for a field which is NOT string type ? What if NULL Value for the field is treated as INVALID ? 2. You have mentioned As Juergen wrote, see the with-defaults draft for details. But the short answer is that you need to delete the leaf in order to get the "reset to default" behavior: My Query: Can we provide "operation" at leaf level ? Why there is no mention regarding "rest to default" behaviour in the with-defaults draft document. Thanks & Regards, Rohit **************************************************************************** *********** -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Wednesday, February 16, 2011 2:11 PM To: rohitpobbathi@huawei.com Cc: biermana@Brocade.com; netconf@ietf.org Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation Hi, Rohit A Pobbathi wrote: > Our question in specific is how to handle a SELECTION node (i.e. or > ) in a Request ? would be a "selection node" if it was part of a subtree filter in a or request. In an , means that the mtu leaf should be set to the value "", or created if it was of type 'empty'. > The intention of the SELECTION node in request is to set the > particular element to DEFAULT i.e. to CLEAR the value. > > Is there any mechanism to set the value of Fields to Default in Edit ? As Juergen wrote, see the with-defaults draft for details. But the short answer is that you need to delete the leaf in order to get the "reset to default" behavior: Note that this operation might fail, depending on how defaults are handled by the server, and the contents of the datastore (see with-defaults for details!). If you have a server that supports :base:1.1 (as defined in draft-ietf-netconf-4741bis), you can send: This operation doesn't fail if the mtu doesn't exist. /martin From rohitpobbathi@huawei.com Fri Mar 25 20:17:06 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BCF3A68AD for ; Fri, 25 Mar 2011 20:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FR_3TAG_3TAG=1.758, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7vtW8SAFyWA for ; Fri, 25 Mar 2011 20:17:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 643E53A68A9 for ; Fri, 25 Mar 2011 20:17:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIN00BBGAIUMC@szxga03-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 11:18:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIN00EYYAIUK8@szxga03-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 11:18:30 +0800 (CST) Received: from BLRNSHTIPL8NC ([10.18.1.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIN00G32AIT0U@szxml06-in.huawei.com> for netconf@ietf.org; Sat, 26 Mar 2011 11:18:30 +0800 (CST) Date: Sat, 26 Mar 2011 08:48:29 +0530 From: Rohit A Pobbathi In-reply-to: To: 'Martin Bjorklund' , biermana@Brocade.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High Thread-index: AcvNtTtt4ZBzuJwxSzmN7/ZLbq9yeQdqpdUgAADxr7A= Cc: netconf@ietf.org Subject: Re: [Netconf] Require Clarifications ///RE: Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Mar 2011 03:17:06 -0000 Dear Martin, Further to my queries in below mail, is it right to perform an edit-config operation as below to set a leaf to default "reset to default" ? Ethernet0/0 -- KEY FIELD 1500 -- NON KEY. Need to be merged - NON KEY. Need to reset to default Regards, Rohit -----Original Message----- From: Rohit A Pobbathi [mailto:rohitpobbathi@huawei.com] Sent: Saturday, March 26, 2011 8:21 AM To: 'Martin Bjorklund'; 'biermana@Brocade.com' Cc: 'netconf@ietf.org'; 'ramu.n@huawei.com' Subject: Require Clarifications ///RE: [Netconf] Regarding empty value provided for xml element inedit-config operation Importance: High Dear Martin, Thanks for your inputs to my queries. I still have some questions regarding the handling of EMPTY tag in operation. 1. You have mentioned In an , means that the mtu leaf should be set to the value "", or created if it was of type 'empty'. My Query: Here I am considering mtu leaf as a field in a table. How to treat value "" for a field which is NOT string type ? What if NULL Value for the field is treated as INVALID ? 2. You have mentioned As Juergen wrote, see the with-defaults draft for details. But the short answer is that you need to delete the leaf in order to get the "reset to default" behavior: My Query: Can we provide "operation" at leaf level ? Why there is no mention regarding "rest to default" behaviour in the with-defaults draft document. Thanks & Regards, Rohit **************************************************************************** *********** -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Wednesday, February 16, 2011 2:11 PM To: rohitpobbathi@huawei.com Cc: biermana@Brocade.com; netconf@ietf.org Subject: Re: [Netconf] Regarding empty value provided for xml element inedit-config operation Hi, Rohit A Pobbathi wrote: > Our question in specific is how to handle a SELECTION node (i.e. or > ) in a Request ? would be a "selection node" if it was part of a subtree filter in a or request. In an , means that the mtu leaf should be set to the value "", or created if it was of type 'empty'. > The intention of the SELECTION node in request is to set the > particular element to DEFAULT i.e. to CLEAR the value. > > Is there any mechanism to set the value of Fields to Default in Edit ? As Juergen wrote, see the with-defaults draft for details. But the short answer is that you need to delete the leaf in order to get the "reset to default" behavior: Note that this operation might fail, depending on how defaults are handled by the server, and the contents of the datastore (see with-defaults for details!). If you have a server that supports :base:1.1 (as defined in draft-ietf-netconf-4741bis), you can send: This operation doesn't fail if the mtu doesn't exist. /martin From mbj@tail-f.com Sat Mar 26 03:01:09 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB823A6911 for ; Sat, 26 Mar 2011 03:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 uJPcSNaWVGsm for ; Sat, 26 Mar 2011 03:01:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1DC1C3A690E for ; Sat, 26 Mar 2011 03:01:07 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 963E176C0A1; Sat, 26 Mar 2011 11:02:42 +0100 (CET) Date: Sat, 26 Mar 2011 11:02:39 +0100 (CET) Message-Id: <20110326.110239.194405696.mbj@tail-f.com> To: rohitpobbathi@huawei.com From: Martin Bjorklund In-Reply-To: <15AD05AC74F54E35ADD2244500B0290B@china.huawei.com> References: <20110216.094031.68035565067234869.mbj@tail-f.com> <15AD05AC74F54E35ADD2244500B0290B@china.huawei.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Require Clarifications ///RE: Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Mar 2011 10:01:09 -0000 Hi, Rohit A Pobbathi wrote: > > Dear Martin, > > Thanks for your inputs to my queries. > > I still have some questions regarding the handling of EMPTY tag in > operation. > > 1. You have mentioned > In an , means that the mtu leaf should be set to > the value "", or created if it was of type 'empty'. > > My Query: Here I am considering mtu leaf as a field in a table. > How to treat value "" for a field which is NOT string type ? > What if NULL Value for the field is treated as INVALID ? Assuming that mtu is a leaf of type integer, with a default value, having: in the edit-config means that you're trying to set mtu to "", which is an invalid value if the mtu is an integer. So such a request would fail with error-tag 'invalid-value'. > 2. You have mentioned > As Juergen wrote, see the with-defaults draft for details. But the > short answer is that you need to delete the leaf in order to get the > "reset to default" behavior: > > > > My Query: Can we provide "operation" at leaf level ? > Why there is no mention regarding "rest to default" behaviour in the > with-defaults draft document. The text in that document describes what happens in the different cases, but it doesn't use the term "reset to default". /martin From mbj@tail-f.com Sat Mar 26 03:04:18 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D0C28C0F7 for ; Sat, 26 Mar 2011 03:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, 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 PHRAReL3Krwy for ; Sat, 26 Mar 2011 03:04:17 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 739DD28C100 for ; Sat, 26 Mar 2011 03:04:16 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F69F76C0A4; Sat, 26 Mar 2011 11:05:52 +0100 (CET) Date: Sat, 26 Mar 2011 11:05:50 +0100 (CET) Message-Id: <20110326.110550.20965521.mbj@tail-f.com> To: rohitpobbathi@huawei.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netconf@ietf.org Subject: Re: [Netconf] Require Clarifications ///RE: Regarding empty value provided for xml element inedit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Mar 2011 10:04:18 -0000 Hi, Sorry, I forgot to reply to one question in my previous email: Rohit A Pobbathi wrote: > My Query: Can we provide "operation" at leaf level ? The answer is yes. > > Dear Martin, > > Further to my queries in below mail, is it right to perform an edit-config > operation as below to set a leaf to default "reset to default" ? > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > Ethernet0/0 -- KEY FIELD > 1500 -- NON KEY. > Need > to be merged > - NON KEY. > Need to > reset to default > > > > > Yes, except the prefix should be 'xc' in this case. Also, the 'merge' operation is not necessary, since merge is the default. /martin From bertietf@bwijnen.net Sat Mar 26 06:25:50 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEBC3A6934 for ; Sat, 26 Mar 2011 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLNDqrWHDlls for ; Sat, 26 Mar 2011 06:25:49 -0700 (PDT) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 27B963A686E for ; Sat, 26 Mar 2011 06:25:48 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Q3TWV-000713-EO for netconf@ietf.org; Sat, 26 Mar 2011 14:27:23 +0100 Message-ID: <89850FF924C1423E9B0520F65CC9C6ED@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf" References: <20110325135314.23044.54263.idtracker@localhost> In-Reply-To: Date: Sat, 26 Mar 2011 14:27:18 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: Re: [Netconf] Protocol Actions: 4741bis and 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: Sat, 26 Mar 2011 13:25:50 -0000 I am glad we reached this stage. A few more weks and we will have RFCs! Thanks to all the hard work of the editors and the WG. Thanks Dan for guidinbg these through the IESG. We got LOTs more comments than I had expected. But the documents did improve along the way (or so I think). Bert ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "netconf" Sent: Friday, March 25, 2011 6:15 PM Subject: Re: [Netconf] Protocol Action: 'Network ConfigurationProtocol(NETCONF)' to Proposed Standard(draft-ietf-netconf-4741bis-10.txt) > > > Hi, > > Thanks and Congratulations to the editors, contributors, chairs and the > whole WG for achieving this target. > > Regards, > > Dan > > From mehmet.ersue@nsn.com Sat Mar 26 06:34:28 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9052D28C119 for ; Sat, 26 Mar 2011 06:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4aVmLVNn1bz for ; Sat, 26 Mar 2011 06:34:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 63B5B28C0E4 for ; Sat, 26 Mar 2011 06:34:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2QDa1r7018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Mar 2011 14:36:02 +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 p2QDa1so027731; Sat, 26 Mar 2011 14:36:01 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 14:34:24 +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: Sat, 26 Mar 2011 14:34:21 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401D7097A@DEMUEXC006.nsn-intra.net> In-Reply-To: <89850FF924C1423E9B0520F65CC9C6ED@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Actions: 4741bis and 4742bis Thread-Index: AcvruZAuDoeCkvaORI6BWiykztdlAQAANCMw References: <20110325135314.23044.54263.idtracker@localhost> <89850FF924C1423E9B0520F65CC9C6ED@BertLaptop> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , "netconf" X-OriginalArrivalTime: 26 Mar 2011 13:34:24.0471 (UTC) FILETIME=[85664E70:01CBEBBA] Subject: Re: [Netconf] Protocol Actions: 4741bis and 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: Sat, 26 Mar 2011 13:34:28 -0000 Same from my side. Thank you all. It was hard but worth it. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert Wijnen (IETF) > Sent: Saturday, March 26, 2011 2:27 PM > To: netconf > Subject: Re: [Netconf] Protocol Actions: 4741bis and 4742bis >=20 > I am glad we reached this stage. A few more weks and we will have > RFCs! Thanks to all the hard work of the editors and the WG. > Thanks Dan for guidinbg these through the IESG. > We got LOTs more comments than I had expected. But the > documents did improve along the way (or so I think). >=20 > Bert >=20 > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "netconf" > Sent: Friday, March 25, 2011 6:15 PM > Subject: Re: [Netconf] Protocol Action: 'Network > ConfigurationProtocol(NETCONF)' > to Proposed Standard(draft-ietf-netconf-4741bis-10.txt) >=20 >=20 > > > > > > Hi, > > > > Thanks and Congratulations to the editors, contributors, chairs and > the > > whole WG for achieving this target. > > > > Regards, > > > > Dan > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Sat Mar 26 10:07:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127543A6958 for ; Sat, 26 Mar 2011 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, 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 uSx3DdJZ6c5H for ; Sat, 26 Mar 2011 10:07:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 96CDC28C0F1 for ; Sat, 26 Mar 2011 10:07:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dIhcnB0CmRaCIHkMgjwEkAw X-IronPort-AV: E=Sophos;i="4.63,248,1299474000"; d="scan'208";a="238670690" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Mar 2011 13:08:35 -0400 X-IronPort-AV: E=Sophos;i="4.63,248,1299474000"; d="scan'208";a="601020906" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Mar 2011 13:08:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2011 18:08:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.txt) Thread-Index: AcvrFyc683QEVwtfRbev5jngp7a1FQAwTUqw From: "Romascanu, Dan (Dan)" To: "netconf" Subject: [Netconf] FW: Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.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: Sat, 26 Mar 2011 17:07:04 -0000 =20 Hi,=20 Thanks and Congratulations to the editors, contributors, chairs and the whole WG for achieving this target.=20 Regards, Dan=20 -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, March 25, 2011 7:42 PM To: IETF-Announce Cc: Internet Architecture Board; netconf mailing list; netconf chair; RFC Editor Subject: [Netconf] Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.txt) The IESG has approved the following document: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' (draft-ietf-netconf-rfc4742bis-08.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/ Technical Summary This document describes a method for invoking and running=20 the NETCONF protocol within a Secure Shell (SSH) session=20 as an SSH subsystem. Working Group Summary This document has been longly discussed in the Working Group, including=20 several WG Last Calls. The comments and reviews helped to improve the=20 document a lot and the current version reflects the consensus of the WG.=20 The document incorporates all accepted errata against RFC4742. After a=20 long debate the WG decided to have the way a NETCONF Server extracts=20 the SSH user name from the SSH layer as implementation-dependent. =20 There was a long discussion on the handling of the EOM character sequence.=20 As the workgroup had only a mandate for bug fixing the workgroup first=20 agreed to keep using the EOM sequence to avoid incompatibility with existing=20 implementations. After the discussion on this issue in IETF #79 a few WG=20 members proposed to figure out if a proper framing solution can be found=20 now, while being backwards compatible with the rfc4742.=20 The old EOM framing has been seen as not secure enough: - RFC4742 assumes that the EOM sequence, ]]>]]>, cannot appear in any=20 well-formed XML document, which turned out to be mistaken. =20 - The EOM sequence can cause operational problems and open space for=20 attacks if sent deliberately in RPC messages. NETCONF co-chairs agreed to consider a solution only if there is a real WG=20 consensus (i.e. near 100%) on such a change. First a possible solution has=20 been discussed in a small team, which included most of the implementers=20 for NETCONF-related tools and protocol code. The solution proposes to=20 encode all NETCONF messages with a chunked framing (similar but not equal=20 to HTTP chunked framing). The document still uses the EOM sequence for the=20 initial message to avoid incompatibility with existing implementations. =20 NETCONF co-chairs asked the AD to hold the documents for 4741bis and=20 4742bis for a short period of time and the result of the discussion in the small=20 team has been sent to the WG for consensus.=20 Some of the discussion points were: - The proposal makes it a little bit harder to do just an SSH-session and then do=20 cut-and-paste input. The implementers believe that the proposed solution for=20 proper/decent framing is acceptable and that most implementation can/will=20 provide a simple scripting front-end to allow for some form of cut-and-paste. - It came out that less experienced implementers find it as helpful to see the=20 "invisible LineFeed" in the examples. The WG concluded that '\n' is the most=20 common character for this purpose. One WG member though was against '\n'=20 and wanted to use '}', which has been noted. - One WG member didn't want to stick the usage of the Chunked Framing=20 Mechanism to capability "base:1.1" only and wanted rather to state ":base:1.1=20 or later". The WG concluded that we should stick to "base:1.1" and extend it=20 with a new version, which most likely will introduce other changes.=20 =20 The changes have been accepted by the WG with some additional discussion=20 and bug fixing. As the result of the WG discussion the WG co-chairs concluded=20 near FULL consensus on the proposed edits and started a WGLC. The WGLC=20 did raise only minor issues. After a short discussion in a small team including=20 the WG co-chairs, the editor of 4742bis Margaret Wasserman, editors of 4741bis=20 Martin Bjorklund, Andy Bierman and Juergen Schoenwaelder the document=20 shepherd sent the collected bug fixing and change requests to NETCONF ML=20 and announced it as the result of the WG last call.=20 Document Quality Since SSH is mandatory transport for NETCONF there are numerous implementations of RFC 4742. It is expected that existing implementations=20 will be updated based on the 4742bis document once it gets published as=20 proposed standard. Personnel Mehmet Ersue is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director.=20 RFC Editor Note Please make the following changes:=20 1. Please reinstate Appendix A from version 07 (accidentally dropped) Appendix A. Changes from RFC 4742 =09 =09 This section lists major changes between this document and RFC 4742. =09 =09 o Introduced the new Chunked Framing Mechanism to solve known security issues with the EOM framing. =09 =09 o Extended text in Security Considerations, added text on EOM issues. =09 =09 o Added examples to show new chunked encoding properly, highlighted =09 the location of new lines. =09 =09 o Added text for NETCONF username handling following the requirements on=20 usernames in [I-D.ietf-netconf-4741bis]. =09 o Changed use of the terms client/server, manager/agent to SSH client/server and NETCONF client/server. =09 =09 o Consistently used the term operation, instead of command or message. =09 =09 o Integrated previously-approved errata from =09 http://rfc-editor.org/errata_search.php?rfc=3D4742 2. in Section 3.1. OLD (v08): As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST indicate its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server. As [I-D.ietf-netconf-4741bis] states the NETCONF client must also send an XML document containing a element to indicate the NETCONF client's capabilities to the NETCONF server. The document containing the element MUST be the first XML document that the NETCONF client sends after the NETCONF session is established. NEW: As specified in [I-D.ietf-netconf-4741bis] the NETCONF server indicates its=20 capabilities by sending an XML document containing a element as=20 soon as the NETCONF session is established. The NETCONF client can parse=20 this message to determine which NETCONF capabilities are supported by the=20 NETCONF server. As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client also=20 sends an XML document containing a element to indicate the NETCONF=20 client's capabilities to the NETCONF server. The document containing the=20 element is the first XML document that the NETCONF client sends=20 after the NETCONF session is established. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietf@andybierman.com Sun Mar 27 05:29:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95A328C100 for ; Sun, 27 Mar 2011 05:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=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 dPE+WrfxcIp3 for ; Sun, 27 Mar 2011 05:29:41 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by core3.amsl.com (Postfix) with ESMTP id D31303A6814 for ; Sun, 27 Mar 2011 05:29:40 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2RCVHOv010971 for ; Sun, 27 Mar 2011 08:31:17 -0400 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.64.158] ([130.129.64.158:60847] helo=[130.129.64.158]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 21/AD-28065-11E2F8D4; Sun, 27 Mar 2011 08:31:16 -0400 Message-ID: <4D8F2E0F.8040800@andybierman.com> Date: Sun, 27 Mar 2011 05:31:11 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: 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-access-control-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Mar 2011 12:29:42 -0000 On 03/20/2011 11:31 PM, Charlie Kaufman wrote: Hi, thanks for your review... comments inline. > I was recently reminded that I am listed as security advisor to the netconf group and that there is an access control document that should be reviewed by a security advisor. I probably shouldn't > be security advisor to this group, and that might get corrected through other channels. > > An important role of a security advisor is to try to keep a group out of trouble in the sense of having someone from the security space come in and disrupt things at the last minute. That mostly > involves not stepping on certain land mines along the way. I don't believe this document is likely to generate such excitement (though you can never know for sure). Here are some thoughts based in > part on my experience in security and in part on what I've seen blow up in IETF. I apologize for reviewing what I see now is the previous version, but I doubt much has changed that would affect my > comments. agreed -- most of the changes from -02 to -03 are editorial, such as RFC2119 cleanup. > > Access control is always messy. Authentication can be based on cryptographic algorithms and can be correct or have subtle bugs, and people "enjoy" spending time debating arcane details around key > sizes, approved algorithms, and which of two equivalent variations is "better". Access control, on the other hand, is a matter of figuring out how to be able to express all the things you need to > be able to express without making the statements so large that no one can ever check them. Section 2 says "It should be easy to do simple things and hard to do complex things, instead of hard to > do everything". The usual statement of that is that it should be easy to do simple things and possible to do complex things. But in access control, nothing is ever simple. What you really want is > for it to be easy to do the things people most frequently want to do and possible to do anything important. I will fix the cliche in the text. YANG is a fairly powerful data modeling language. It is much easier to model powerful ACLs and we are optimizing for the most common use cases. > > It's really a question of the scope of declarations. The "simplest" access control model would be for each item and each operation on that item, a list of the users permitted to perform that > operation on that item is listed. It's simple, but it's not easy because the volume of activity you would have to go through to state a complete policy would be infeasible. The trick to a good > access control model is correctly anticipating the groups of things administrators are going to want to apply the same rules to and the groups of users that administrators are going to want to > give the same rights to. > > I don't understand the full range of things NETCONF is likely to be used for to say whether what's proposed here is a good model, but let me point out some things that make me uneasy: I think the NETCONF WG members understand NETCONF and what aspects of the protocol need access control. It is debatable how fine-grained the control needs to be, but the access control enforcement points are fairly well understood. > > Section 2.2 para 4: "Default access control policy needs to be as secure as possible". There is a constant debate over whether the default access control policy should be the most locked down > configuration anyone would possibly want or the policy people are most likely to want. This item seems to be talking more about bootstrap situations: what should the policy be when you take a new > device out of the box and plug it in. Usually there is no safe way to take a new device out of the box and safely put it on an open network and configure it from there. That's because at that > point, the device can't distinguish a good guy from a bad guy. Usually, it's necessary to do some minimal configuration through some local (non-network) interface before putting the device on the > network or taking advantage of some special purpose hack like printing a factory password on the bottom of the device. Resetting to factory settings usually requires some physical access. Requiring a human to physically visit and manipulate every managed device does not really scale well. It may be fine for a SOHO deployment but maybe not much else. The default access control can be more sophisticated if the data model schema contains meta-information about the security sensitivity of particular objects. The operational problem is the need to provide reasonable default access control instead of requiring explicit rules for every possible operation or conceptual datastore object. > > Section 2.3 para 3: "YANG modules should be designed so that different access levels for input parameters to protocol operations is not required". This is saying that the permission to do > something should be determined by the operation and the object and not by any parameters. It sounds obvious, but it actually constrains how operations are defined. It means that you can't have a > "generic" operation on an object that based on a parameter might be a read or a write. It means that if there is a normal range of values for a configuration parameter, it's not possible to > require a higher level of authority to set a value to outside the normal range than to set it within the normal range. If the operations that you have already defined follow this pattern, and you > don't anticipate new operations that break the pattern, making such a restriction simplifies the access control model. But it's not free. NACM is not designed that way. It is layered. That means that no matter what operation is used (nc:edit-config or acme:edit) that access to the conceptual datastore is protected (i.e., data-rules). For 'actions', such as acme:reset, that do not access the conceptual datastore, there is only course-grained control, as you point out. That does mean that generic commands (e.g., acme:action op='reset-all-hardware' or acme:action op='change-my-terminal-line-length') would be a bad design which could not be easily controlled with NACM rules. Not even VACM allows a user to set ifAdminStatus to the value 'up' but not the value 'down'. This is a WG decision that fine-grained access is not needed at the parameter value level. Operationally, all input parameters to an RPC are part of that RPC. It may make sense to say a user is not allowed to provide some of the operation parameters, but this fine-grained access is only provided on the conceptual datastore layer. > > Section 2.4 para 5: "The non-volatile startup configuration needs to be loaded into the running configuration without applying any access control rules". The is a "restore factory settings" > operation, which must be possible even if the running configuration is arbitrarily broken in ways that would prevent such an operation, but it is still a highly privileged operation... doing this > would require some sort of physical device override and depending on what else is going on might require alarms, real time delays, or something else to make sure it is not part of an attack. > We will try to clean up the terminology. This text is meant to apply to the boot initialization phase of the device, before it is active and accepting NETCONF (or any user) sessions. > Section 2.4.2 "Data nodes to which the client does not have 'read' access ... are silently omitted from the message." You need to decide whether this is done for convenience or for > security. It says that if you try to read a group of values and you don't have permission to read some of them, those values are not returned. This can be a convenience measure because you don't > need to interrupt the return of a list with an error saying the permission is denied. Or it can be a security measure in that you can't learn of the existence of parameters unless you have > permission to read them. If you try to delete such an item, do you get a different error depending on whether it exists or not? (i.e. access denied vs. named object not found). It also can have > bad side effects as noted at the end of section 2.4.4: if you do a backup by reading everything, but some stuff is left out because you did not have permission to read it, it would be good to get > notified at backup time that your backup has failed rather than discovering it at recovery time when the objects you did not have permission to read are not restored. > This behavior is needed to make NETCONF filtering usable. This is also how SNMP works. If you get-next into a restricted node, the operation does not fail -- it continues on to the next node the user is allowed to read. If NETCONF subtree or XPath filters needed to be constructed so they never matched a node that the user is not authorized to read, then not only would filtering be almost impossible to use, the user would need to be aware of all the data s/he is not allowed to access. This seems the opposite of what one would want, both from a security and operational POV. > In section 2.4.3, by giving permissions on the base objects rather than on the procedures that manipulate them, you lose some capabilities you might want. For example, if you wanted to allow > someone to move quotas around between objects they controlled but not increase the total quotas of all of his objects, you could write a "macro" procedure to do that. But if the permissions are > enforced on all of the base objects independently, you could not give out such "reshuffle" permissions. We have a CRUDX permissions model. This allows fine-grained control over the NETCONF 'operation' attribute used within nc:edit-config. There is no super-fine-grained control over the YANG 'insert' attributes. I do not understand the use-case you are describing. NACM does not allow control over inserting an entry at the end of a list vs, the middle, vs. just changing the order (insert X after Y, where X already exists == move operation). > > The use of the term "superuser" might turn out to be a land mine, in that there are lots of people who have gotten into lots of different kinds of trouble with such a feature, and calling it that > is calling their attention to it. Ideally, a system would be designed so that under normal circumstances all administrators - even the most powerful ones - are configured to have the permissions > they need. You still need a mechanism for overriding those permissions to deal with the case of misconfiguration where no one is authorized to perform some needed operation. You might be better > off calling that an "emergency recovery user" rather than superuser, clearly carrying the implication that it is not for routine use. (That's just a word to the wise... in all probability you can > use the term superuser and no one will complain). I agree. Perhaps we can come up with some word smithing that will say the device MAY have mechanisms which allow the emergency recovery to be possible. IMO, this has always been a weakness of the IETF. This policy mandates that every device will have a non-standard (i.e. different) mechanism to deal with the initial state and 'locked-out' state. OK for SOHO, but does not scale beyond that. > > In section 3.2.5, there is discussion of a global on/off switch for certain categories of access control rule enforcement. It doesn't say whether when access control is "off" whether all actions > are allowed or whether all are denied. I suspect from context that all are allowed. Clearly these are extremely dangerous settings; I would guess they exist for some sort of emergency recovery > situation. I don't understand why there are four categories... if you're going to throw security to the wind because the nuclear plant is melting down and you want to allow anyone in the world to > try to fix it, that would argue for one big switch not four. It's also questionable whether you want the feature at all. It would be equivalent to making all users superusers (er... emergency > recovery users). A global switch that turned off all ability to remotely change configuration settings regardless of credentials presented might make sense, but that didn't appear to be what was > being called for. This is one detail that was cleaned up in -03. There are not 4 switches that do the same thing. There is a global on/off switch (AFAIK, many real solutions such as firewalls and SELinux have such a switch). Then there are 3 switches to control the default action when no rule is found for a requested operation type (read, write, exec). An operator can decide how to treat each of these request types. Setting them all to 'deny' would be the most secure. The on/off switch is needed to allow a simple way to check if access control is getting in the way (temporarily disable it), rather than requiring the operator to delete all NACM configuration and add it back later. > > In section 3.3.1: "There is no requirement to enforce access control rules before or while the non-volatile configuration data is processed and loaded into the running configuration". I hope that > doesn't mean what it looks like to me. You certainly don't want to say that while configuration data is being loaded from a non-volatile store that anyone can in parallel make any changes they > want without access controls being applied. To the contrary, I would expect you would want to lock out all other changes during the load process. Restoring an old non-volatile configuration is an > example of an operation you might want someone to be able to do even if they don't have permission to update all of the entries in the configuration independently. > We will try to fix the text so it is clear this only applies to the device initialization phase, before the server is accepting user sessions of any kind. > The document does not seem to deal with things that are "read-only data" where it makes no sense to try to modify it over the network because it is computed by the system as a reflection of the > system's state. Someone might be configured with permission to update such data, but an update wouldn't work. You should say whether you want to model that as an access control failure or have the > update silently ignored, or whatever. An example might be the case where you've done a complete backup of configuration state. When trying to restore it, the read-only values can't be restored. > What is the system supposed to do? NETCONF/YANG does not currently support the concept of read-only configuration (i.e., not writable by any user, only writable by the server). We are hoping new work (TBD) will address the complexity of configuration that is never writable by a user (e.g., you cannot add or delete physical interfaces). Currently, the server would just return an access-denied error for such as case. I do not understand the use-case of the system not being able to provide these read-only configuration parameters. By definition, the server knows its own factory default settings. Anything else is a bug in the vendor code. > > Section 3.4.3 there are labels for "secure" and "very-secure". Reading the text, it would appear that "very-secure" really means that reading the data is security sensitive (as opposed to secure, > where only updating it is sensitive). That's probably going to confuse people. You might consider read-secure. Of for the pair "read-sensitive" and "write-sensitive". > I'm not a fan of debating terminology for very long. We will try to come to agreement (if the WG agrees these terms need changing. I agree with you that these terms are too generic now and probably need to be more specific. The terms 'secure' and 'very-secure' have no real semantics at all, but they are easy to remember. > In the construction of "groups", there are really two kinds of groups: there are groups of people, where you want to give all members of the group the same permissions. These groups might > naturally be defined by a more global authentication system, where when someone authenticates you find out not just who they are but get a list of groups they belong to. Alternately, you might > define the groups locally. The second kind of group is constructed to fill the need that is often called a "role" in the access control community. That is for the case where there are some things > on the server where you always want to control access to them in the same way. To do that, you would always define the group locally, and you would specify what users and externally defined groups > are members of this locally defined group. Again, more terminology. Let's say I want to configure the servers by application, because I know I want particular NMS applications deployed. What does the "FooApp" role mean vs. the "BarApp" role? IMO, groups are more generic, but this term has less baggage than the term 'role'. What role is "admin-group-in-chicago' vs. 'admin-group-in-new-york'? > > For example, you might create an "administrators" group and a "performance monitors" group locally and give those groups the appropriate access to ranges of resources. The intent would be that you > would never update the policy concerning which of these groups had access to which resources, but you would change the membership in the groups. You would not want such groups defined remotely > because someone would be unlikely to be an administrator everywhere. The set of administrators for each instance of the system would be different. > These are the easy use cases. > The ability to have group memberships defined either internally or externally is already allowed by the spec; you might want to make it explicit. > OK -- we will look at the text and try to determine what needs to be changed. Perhaps the text about radius support is not clear enough, or made vague intentionally. > Good luck with this. thanks, we'll need it. > > --Charlie Andy From charliek@microsoft.com Mon Mar 28 10:58:24 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2233A67D1 for ; Mon, 28 Mar 2011 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErXj57lpSeB6 for ; Mon, 28 Mar 2011 10:58:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 04EB23A6859 for ; Mon, 28 Mar 2011 10:58:22 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Mar 2011 11:00:00 -0700 Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.17]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 10:59:59 -0700 From: Charlie Kaufman To: Andy Bierman Thread-Topic: [Netconf] Comments on draft-ietf-netconf-access-control-02 Thread-Index: AcvnhFqYRK//jHBzQpuJAtEsIb1KfwFMSyCAAC178mA= Date: Mon, 28 Mar 2011 17:59:59 +0000 Message-ID: References: <4D8F2E0F.8040800@andybierman.com> In-Reply-To: <4D8F2E0F.8040800@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-access-control-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Mar 2011 17:58:24 -0000 Attempting to clarify a couple of points of confusion... (none of this requ= ires a response). --Charlie > > Section 2.2 para 4: "Default access control policy needs to be as=20 > secure as possible". > You responded to a much more complex issue than the simple one I was raisin= g. The statement above is a common one made in the security community witho= ut thinking about its implications. Choosing a default policy is a trade-of= f between security and convenience. The most convenient default is the poli= cy that the most administrators will want... it minimizes the number of set= tings they need to change. The most secure default denies everything and fo= rces virtually all administrators to change it. I was just questioning whet= her that was really what you wanted. It's also possible I misinterpreted what you meant by the statement above. >> In section 2.4.3, by giving permissions on the base objects rather=20 >> than on the procedures that manipulate them, you lose some=20 >> capabilities you might want. For example, if you wanted to allow >> someone to move quotas around between objects they controlled >>but not increase the total quotas of all of his objects, you could write >>a "macro" procedure to do that. But if the permissions are enforced >>on all of the base objects independently, you could not give out such >>"reshuffle" permissions. >We have a CRUDX permissions model. This allows fine-grained control >over the NETCONF 'operation' attribute used within nc:edit-config.=20 >There is no super-fine-grained control over the YANG 'insert' attributes. >I do not understand the use-case you are describing. NACM does not >allow control over inserting an entry at the end of a list vs, the middle, >vs. just changing the order (insert X after Y, where X already exists =3D= =3D >move operation). You misinterpreted my comment. By "moving" a quota, I meant increasing the = numeric value of one attribute while simultaneously decreasing the numeric = of another (related) attribute. There are cases where you want to give some= one permission to make such changes but you don't want to give them permiss= ion to change the sum. (It's possible such scenarios never come up in the c= ontext of NETCONF). An access control model that could specifically enable = such a thing would be intolerably complex, so what many systems do instead = is to give 'eXecute' permission on some procedure, where the procedure has = the ability to change attributes that the user would not be able to change = directly. (Think 'setuid' programs). My reading of your access control mode= l seemed to rule out such procedures (because it seemed to say that the use= r needed the appropriate permissions on all base objects that operations to= uched). That's OK if it's a conscious choice. I just wanted to verify that = it was. >> The document does not seem to deal with things that are "read-only=20 >> data" where it makes no sense to try to modify it over the network=20 >> because it is computed by the system as a reflection of the system's sta= te. >>Someone might be configured with permission to update such data, but >>an update wouldn't work. You should say whether you want to model that >>as an access control failure or have the update silently ignored, or what= ever. >>An example might be the case where you've done a complete backup of >>configuration state. When trying to restore it, the read-only values can'= t >>be restored. >> >> What is the system supposed to do? > >NETCONF/YANG does not currently support the concept of read-only >configuration (i.e., not writable by any user, only writable by the server= ).=20 >We are hoping new work (TBD) will address the complexity of configuration >that is never writable by a user (e.g., you cannot add or delete physical >interfaces). >Currently, the server would just return an access-denied error for such as= case. > >I do not understand the use-case of the system not being able to provide >these read-only configuration parameters. By definition, the server knows = its >own factory default settings. Anything else is a bug in the vendor code. The case I'm worried about is where someone tries to do a backup and restor= e of system state. Reading the system state works fine, but when they try t= o restore it they get access-denied failures for all the items which are re= ad-only. Just as for the case of pretending that data does not exist if the= user does not have permission to read it, it might be convenient if there = were some way to ignore requests to update data if the user does not have p= ermission to update it. For data that is essentially static (like number of= ports), the update request might be ignored only if the data he was attemp= ting to write matched what was already there. But for statistical data (lik= e number of xyzzy operations performed since bootload), some other techniqu= e might be useful. --Charlie From j.schoenwaelder@jacobs-university.de Tue Mar 29 01:12:51 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889513A68BA for ; Tue, 29 Mar 2011 01:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 WXBfrVs6JNfe for ; Tue, 29 Mar 2011 01:12:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0F4A73A6ADC for ; Tue, 29 Mar 2011 01:12:50 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AF6FC0025 for ; Tue, 29 Mar 2011 10:14:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id izcgJHssm5R4; Tue, 29 Mar 2011 10:14:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EE90C0012; Tue, 29 Mar 2011 10:14:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADFEB174B67E; Tue, 29 Mar 2011 10:14:22 +0200 (CEST) Date: Tue, 29 Mar 2011 10:14:22 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20110329081422.GA27060@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] js comments on draft-ietf-netconf-system-notifications-03 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, 29 Mar 2011 08:12:51 -0000 Hi, I have reviewed this document and overall it seems to be a in a very good shape. a) I am not a big fan of the term "netconf system notifications" since system is rather ambiguous. I suggest to replace this phrase with "netconf server notifications". This seems to be also more inline with say 2.1.1, where the document says: [...] to notify a client application that the NETCONF server state has changed. I know, this causes a number of changes (include a name change of the module and of the title of the document) but I am even willing to help with the edits. ;-) b) There are some terminology issue related to the terms 'event' and 'notification'. In my preferred model, an 'event' is something that happens and that can lead to a 'notification'. This seems to be also the terminology used in RFC 5277. There are a number of places where changes are needed, e.g.: This module defines some events for the 'NETCONF' stream to notify a client application that the NETCONF server state has changed. A notification stream carries notifications, not events. "This module defines an YANG data model for use with the NETCONF protocol that allows the NETCONF client to receive common NETCONF system notification events. s/NETCONF system notification events./NETCONF server notifications./ - or - s/NETCONF system notification events./notifications about common NETCONF server events/ This document defines a YANG module for reporting of particular system events. s/of particular system events/NETCONF server events/ c) The security considerations obviously need some more text, likely pointing to the security considerations of 4741bis and RFC 5277. It might be useful to mention that the notifications can be used to detect unexpected NETCONF sessions and unexpected configuration changes. A statement such as "no specific information in this module is considered sensitive" might be problematic, given that the netconf-config-change for example tells you quite a bit about where in the config a change occured. Even session start and end times might be sensitive if you can associate sessions to people. I suggest to simple remove this statement. /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 Tue Mar 29 03:34:40 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA513A6947 for ; Tue, 29 Mar 2011 03:34:40 -0700 (PDT) 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 TRcrUNU1YaqJ for ; Tue, 29 Mar 2011 03:34:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4FF603A6946 for ; Tue, 29 Mar 2011 03:34:35 -0700 (PDT) Received: from localhost (dhcp-44b4.meeting.ietf.org [130.129.68.180]) by mail.tail-f.com (Postfix) with ESMTPSA id 882E576C1D3; Tue, 29 Mar 2011 12:36:12 +0200 (CEST) Date: Tue, 29 Mar 2011 12:36:10 +0200 (CEST) Message-Id: <20110329.123610.258316008.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110329081422.GA27060@elstar.local> References: <20110329081422.GA27060@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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2011 10:34:40 -0000 Hi, Juergen Schoenwaelder wrote: > a) I am not a big fan of the term "netconf system notifications" since > system is rather ambiguous. I suggest to replace this phrase with > "netconf server notifications". I disagree. I'd rather call it "system notifictions over NETCONF" or something, to indicate that the notifications are related to more than just the NETCONF server. The way I see it is that (most of) these *events* happen in the "system", and this document defines NETCONF *notifications* representing these events. [In fact, there's an embryo of a discussion about this in http://www.ietf.org/mail-archive/web/netconf/current/msg06576.html. AFAIK, this was never resolved. Maybe we should start by trying to resolve this issue.] Maybe the term "system" is ambigous, but it seems to have worked for the system group in SNMP. The only notification that is can be said to be tied to the NETCONF server, and not the "system", is netconf-capability-change. But even this is not always true - if the new capability is a new data model, that is not internal to the NETCONF server, is is really a function of the system. If the new capability is something like :xpath, then it is a NETCONF server internal thing. I also have some other comments on this document. o notification netconf-config-change I think the description should state if this notification is generated on a reboot or not. E.g., if running and startup were different when the box rebooted, running has now changed. Do we get a notification in this case? What if a new startup file was used? o list edit in netconf-config-change State that it is ok to omit this list if the diff is not known. Also state that edit entries can be present even if the change is a result of something else than a NETCONF edit-config. o leaf killed-by in netconf-session-end This leaf exists only when the termination-reason is 'killed' (should it be mandatory?). enum killed says: "The session was terminated with the NETCONF operation."; and description of the leaf says: "Session ID that issued the if the session was terminated by this operation."; so the enum is 'killed' only if the session was killed with . Thus the text that says "... if the session was terminated by this operation" is redundant. We already know that the session was terminated by this operation. However, don't we want the termination-reason to be 'killed' if the session was killed from e.g. the CLI? o notification netconf-confirmed-commit s/confirm-commit/confirmed commit/g (?) /martin From j.schoenwaelder@jacobs-university.de Tue Mar 29 03:44:54 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3B43A693E for ; Tue, 29 Mar 2011 03:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 WzsT9ty1Lnwe for ; Tue, 29 Mar 2011 03:44:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E5CA63A68D4 for ; Tue, 29 Mar 2011 03:44:52 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF676C0025; Tue, 29 Mar 2011 12:46:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r1W3R2ItlSYZ; Tue, 29 Mar 2011 12:46:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79910C0009; Tue, 29 Mar 2011 12:46:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF86D174BD4D; Tue, 29 Mar 2011 12:46:25 +0200 (CEST) Date: Tue, 29 Mar 2011 12:46:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110329104625.GA27488@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20110329081422.GA27060@elstar.local> <20110329.123610.258316008.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110329.123610.258316008.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notifications-03 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, 29 Mar 2011 10:44:54 -0000 On Tue, Mar 29, 2011 at 12:36:10PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > a) I am not a big fan of the term "netconf system notifications" since > > system is rather ambiguous. I suggest to replace this phrase with > > "netconf server notifications". > > I disagree. I'd rather call it "system notifictions over NETCONF" or > something, to indicate that the notifications are related to more than > just the NETCONF server. The way I see it is that (most of) these > *events* happen in the "system", and this document defines NETCONF > *notifications* representing these events. But I think this is not true for the notifications the document actually defines. netconf-config-change: Generated when the NETCONF server detects that the or configuration datastore has changed. netconf-capability-change Generated when a is added, deleted, or modified. notification netconf-session-start Generated when a new NETCONF session is started. notification netconf-session-end Generated when a NETCONF session is terminated. netconf-confirmed-commit Generated when a confirmed-commit event occurs. They _all_ seem to be NETCONF server related notifications. > [In fact, there's an embryo of a discussion about this in > http://www.ietf.org/mail-archive/web/netconf/current/msg06576.html. > AFAIK, this was never resolved. Maybe we should start by trying to > resolve this issue.] > > Maybe the term "system" is ambigous, but it seems to have worked for > the system group in SNMP. > > The only notification that is can be said to be tied to the NETCONF > server, and not the "system", is netconf-capability-change. But even > this is not always true - if the new capability is a new data model, > that is not internal to the NETCONF server, is is really a function of > the system. If the new capability is something like :xpath, then it > is a NETCONF server internal thing. You consider netconf-session-start/netconf-session-end is not NETCONF server specific? You consider netconf-confirmed-commit is not NETCONF server specific? A capability change notification says the capabilities supported by the NETCONF server have changed. The newly announced capability may be a system feature change. Perhaps this discussion is just more evidence that we should avoid the word system. ;-) /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 Tue Mar 29 04:40:55 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55663A6914 for ; Tue, 29 Mar 2011 04:40:55 -0700 (PDT) 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 DnpzJeM-Xw+X for ; Tue, 29 Mar 2011 04:40:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 699703A67B6 for ; Tue, 29 Mar 2011 04:40:53 -0700 (PDT) Received: from localhost (dhcp-44b4.meeting.ietf.org [130.129.68.180]) by mail.tail-f.com (Postfix) with ESMTPSA id 2AF5776C1CC; Tue, 29 Mar 2011 13:42:30 +0200 (CEST) Date: Tue, 29 Mar 2011 13:42:28 +0200 (CEST) Message-Id: <20110329.134228.182416665.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110329104625.GA27488@elstar.local> References: <20110329081422.GA27060@elstar.local> <20110329.123610.258316008.mbj@tail-f.com> <20110329104625.GA27488@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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2011 11:40:55 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 29, 2011 at 12:36:10PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > a) I am not a big fan of the term "netconf system notifications" since > > > system is rather ambiguous. I suggest to replace this phrase with > > > "netconf server notifications". > > > > I disagree. I'd rather call it "system notifictions over NETCONF" or > > something, to indicate that the notifications are related to more than > > just the NETCONF server. The way I see it is that (most of) these > > *events* happen in the "system", and this document defines NETCONF > > *notifications* representing these events. > > But I think this is not true for the notifications the document > actually defines. > > netconf-config-change: > > Generated when the NETCONF server detects that the > or configuration datastore has changed. This text clearly says that the notification is generated when the NETCONF server detects the event, which presumably means that the event happens outside the server. > netconf-capability-change > > Generated when a is added, deleted, > or modified. As I said, the capability addition is the way to report that the system e.g. loaded a new module. The event is that the system for example supports a new feature (maybe a licence was installed for 'routing'). > notification netconf-session-start > > Generated when a new NETCONF session is started. > notification netconf-session-end > > Generated when a NETCONF session is terminated. I would like these to have broader scope. I think we've discussed this in the past. I think these notifications could be generated also when a CLI session starts/ends, or a Web session, or whatever. > netconf-confirmed-commit > > Generated when a confirmed-commit event occurs. Devices that support this likely support this in the native system, not just in the NETCONF server. In fact, I don't think you can implement this correctly w/o support from the underlying system (data store etc). I'm pretty sure that the feature is also available in the CLI for such devices. /martin > They _all_ seem to be NETCONF server related notifications. > > > [In fact, there's an embryo of a discussion about this in > > http://www.ietf.org/mail-archive/web/netconf/current/msg06576.html. > > AFAIK, this was never resolved. Maybe we should start by trying to > > resolve this issue.] > > > > Maybe the term "system" is ambigous, but it seems to have worked for > > the system group in SNMP. > > > > The only notification that is can be said to be tied to the NETCONF > > server, and not the "system", is netconf-capability-change. But even > > this is not always true - if the new capability is a new data model, > > that is not internal to the NETCONF server, is is really a function of > > the system. If the new capability is something like :xpath, then it > > is a NETCONF server internal thing. > > You consider netconf-session-start/netconf-session-end is not NETCONF > server specific? You consider netconf-confirmed-commit is not NETCONF > server specific? A capability change notification says the > capabilities supported by the NETCONF server have changed. The newly > announced capability may be a system feature change. > > Perhaps this discussion is just more evidence that we should avoid > the word system. ;-) > > /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 Tue Mar 29 07:13:21 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED00C3A6A26 for ; Tue, 29 Mar 2011 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 htOlLCCRNkJ5 for ; Tue, 29 Mar 2011 07:13:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B5F673A6824 for ; Tue, 29 Mar 2011 07:13:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65222C003A; Tue, 29 Mar 2011 16:14:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31V9zr-vrW-r; Tue, 29 Mar 2011 16:14:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47AA5C0036; Tue, 29 Mar 2011 16:14:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5EFD8174C214; Tue, 29 Mar 2011 16:14:52 +0200 (CEST) Date: Tue, 29 Mar 2011 16:14:51 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110329141451.GA27857@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20110329081422.GA27060@elstar.local> <20110329.123610.258316008.mbj@tail-f.com> <20110329104625.GA27488@elstar.local> <20110329.134228.182416665.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110329.134228.182416665.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notifications-03 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, 29 Mar 2011 14:13:21 -0000 On Tue, Mar 29, 2011 at 01:42:28PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Mar 29, 2011 at 12:36:10PM +0200, Martin Bjorklund wrote: > > > Hi, > > > > > > Juergen Schoenwaelder wrote: > > > > a) I am not a big fan of the term "netconf system notifications" since > > > > system is rather ambiguous. I suggest to replace this phrase with > > > > "netconf server notifications". > > > > > > I disagree. I'd rather call it "system notifictions over NETCONF" or > > > something, to indicate that the notifications are related to more than > > > just the NETCONF server. The way I see it is that (most of) these > > > *events* happen in the "system", and this document defines NETCONF > > > *notifications* representing these events. > > > > But I think this is not true for the notifications the document > > actually defines. > > > > netconf-config-change: > > > > Generated when the NETCONF server detects that the > > or configuration datastore has changed. > > This text clearly says that the notification is generated when the > NETCONF server detects the event, which presumably means that the > event happens outside the server. So you agree that this notification carries the event that the server detected the change, not the change event of the system's configuration itself. Good we agree that this is a NETCONF server notification. ;-) > > netconf-capability-change > > > > Generated when a is added, deleted, > > or modified. > > As I said, the capability addition is the way to report that the > system e.g. loaded a new module. The event is that the system for > example supports a new feature (maybe a licence was installed for > 'routing'). The event carries forward that the NETCONF server supports a new capability or lost a capability. This might be related to a change of the system's features, but it does not necessarily have to be. Nor can you be sure that changes of the system's features always lead to a change of the NETCONF capabilities. > > notification netconf-session-start > > > > Generated when a new NETCONF session is started. > > notification netconf-session-end > > > > Generated when a NETCONF session is terminated. > > I would like these to have broader scope. I think we've discussed this > in the past. I think these notifications could be generated also when a > CLI session starts/ends, or a Web session, or whatever. I doubt it is workable nor desirable to make this an open ended "some interesting transport session started/ended" notification. > > netconf-confirmed-commit > > > > Generated when a confirmed-commit event occurs. > > Devices that support this likely support this in the native system, > not just in the NETCONF server. In fact, I don't think you can > implement this correctly w/o support from the underlying system (data > store etc). I'm pretty sure that the feature is also available in the > CLI for such devices. You have not convinced me yet. ;-) /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 Tue Mar 29 07:36:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63A63A682B for ; Tue, 29 Mar 2011 07:36:02 -0700 (PDT) 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 Z70sbi9HlVdC for ; Tue, 29 Mar 2011 07:36:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C9E653A67D3 for ; Tue, 29 Mar 2011 07:36:00 -0700 (PDT) Received: from localhost (unknown [130.129.68.180]) by mail.tail-f.com (Postfix) with ESMTPSA id 508F976C3D9; Tue, 29 Mar 2011 16:37:37 +0200 (CEST) Date: Tue, 29 Mar 2011 16:37:03 +0200 (CEST) Message-Id: <20110329.163703.215127896.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110329141451.GA27857@elstar.local> References: <20110329104625.GA27488@elstar.local> <20110329.134228.182416665.mbj@tail-f.com> <20110329141451.GA27857@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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2011 14:36:03 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 29, 2011 at 01:42:28PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Mar 29, 2011 at 12:36:10PM +0200, Martin Bjorklund wrote: > > > > Hi, > > > > > > > > Juergen Schoenwaelder wrote: > > > > > a) I am not a big fan of the term "netconf system notifications" since > > > > > system is rather ambiguous. I suggest to replace this phrase with > > > > > "netconf server notifications". > > > > > > > > I disagree. I'd rather call it "system notifictions over NETCONF" or > > > > something, to indicate that the notifications are related to more than > > > > just the NETCONF server. The way I see it is that (most of) these > > > > *events* happen in the "system", and this document defines NETCONF > > > > *notifications* representing these events. > > > > > > But I think this is not true for the notifications the document > > > actually defines. > > > > > > netconf-config-change: > > > > > > Generated when the NETCONF server detects that the > > > or configuration datastore has changed. > > > > This text clearly says that the notification is generated when the > > NETCONF server detects the event, which presumably means that the > > event happens outside the server. > > So you agree that this notification carries the event that the server > detected the change, not the change event of the system's configuration > itself. No, it states the obvious that the notification is generated when the NETCONF server detects the event (it would be interesting if it was generated _before_ the event was detected :). I think the notification represents the change event of the system's configuration. > Good we agree that this is a NETCONF server notification. ;-) Sorry, no :) > > > netconf-capability-change > > > > > > Generated when a is added, deleted, > > > or modified. > > > > As I said, the capability addition is the way to report that the > > system e.g. loaded a new module. The event is that the system for > > example supports a new feature (maybe a licence was installed for > > 'routing'). > > The event carries forward that the NETCONF server supports a new > capability or lost a capability. This might be related to a change of > the system's features, but it does not necessarily have to be. Nor > can you be sure that changes of the system's features always lead to a > change of the NETCONF capabilities. I agree that this notification represents two events - both that the system's features has changed, and that the netconf server's internal capabilities have changed (altough my guess is that this is not that common, since it probably implies a software change of the netconf server). > > > notification netconf-session-start > > > > > > Generated when a new NETCONF session is started. > > > notification netconf-session-end > > > > > > Generated when a NETCONF session is terminated. > > > > I would like these to have broader scope. I think we've discussed this > > in the past. I think these notifications could be generated also when a > > CLI session starts/ends, or a Web session, or whatever. > > I doubt it is workable nor desirable to make this an open ended "some > interesting transport session started/ended" notification. I don't see the point in having multiple lists for different mgmt protocols. Why list CLI, Web, SNMP (over ssh or something) in separate lists? Some devices might not support this, but that is fine. I want to avoid having N versions of this exact data model - cli-session-start, cli-config-change, web-config-change, snmp-config-change, etc. This just makes it more difficult for the client. What is the advantage this approach? > > > netconf-confirmed-commit > > > > > > Generated when a confirmed-commit event occurs. > > > > Devices that support this likely support this in the native system, > > not just in the NETCONF server. In fact, I don't think you can > > implement this correctly w/o support from the underlying system (data > > store etc). I'm pretty sure that the feature is also available in the > > CLI for such devices. > > You have not convinced me yet. ;-) /martin From kwatsen@juniper.net Tue Mar 29 10:26:57 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337E83A6A68 for ; Tue, 29 Mar 2011 10:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WivFfL6sZf06 for ; Tue, 29 Mar 2011 10:26:55 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id A25F63A67A6 for ; Tue, 29 Mar 2011 10:26:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTZIWvdM88PhLpOO5wEPKITHEtV+wW6Tw@postini.com; Tue, 29 Mar 2011 10:28:34 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 29 Mar 2011 10:25:41 -0700 From: Kent Watsen To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Date: Tue, 29 Mar 2011 10:27:09 -0700 Thread-Topic: [Netconf] js comments on draft-ietf-netconf-system-notifications-03 Thread-Index: AcvuHqzCsumJgLg+RQ6bZReysKK0uAACe/DA Message-ID: <84600D05C20FF943918238042D7670FD3863B16562@EMBX01-HQ.jnpr.net> References: <20110329104625.GA27488@elstar.local> <20110329.134228.182416665.mbj@tail-f.com> <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> In-Reply-To: <20110329.163703.215127896.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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2011 17:26:57 -0000 I view this capability (along with netconf:base and netconf-monitoring) as = the first of a set of capabilities enabling basic element-level device mana= gement: - system management - hardware management - software management - license management - configuration management - user management - etc. In general, I see each of these "capabilities" defining RPCs and notificati= ons and, in very rare circumstances, configuration (abstract data-models). = So, for instance, the ":hardware" capability would define an RPC to fetch = physical inventory on the device as well as define notifications for when h= ardware has been physically added/removed. Now, back to this capability, it provides notifications for both "configura= tion management" (see above list) as well as for the netconf server itself = (not listed above). Both of these make sense, given that they reflect what= the NetConf RFC defines, but I wouldn't name it "netconf system", "netconf= server" or "system notifications over netconf", as none of them seem to ac= curately reflect its nature. I might call it "netconf base notifications"= , since it mostly defines notifications that reflect the "netconf:base" pro= tocol, or "netconf monitoring notifications", since it seems to provide not= ifications for when the various "monitoring" subtrees change. [note: in t= he latter case, we might consider rev-ing the ietf-netconf-monitoring capab= ility instead as notifications are for monitoring...] Regarding notifications on netconf-sessions, I can accept them as needed in= order to reflect the netconf-monitoring "/sessions" subtree, but I strongl= y resists the idea of expanding the scope to user sessions in general (i.e.= cli, webui, etc.), as I believe that these notifications should be pushed = out to a distinct "system" or "user" capability specific to the purpose. Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Tuesday, March 29, 2011 10:37 AM To: j.schoenwaelder@jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notificatio= ns-03 Juergen Schoenwaelder wrote: > On Tue, Mar 29, 2011 at 01:42:28PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Mar 29, 2011 at 12:36:10PM +0200, Martin Bjorklund wrote: > > > > Hi, > > > >=20 > > > > Juergen Schoenwaelder wrote: > > > > > a) I am not a big fan of the term "netconf system notifications" = since > > > > > system is rather ambiguous. I suggest to replace this phrase w= ith > > > > > "netconf server notifications". > > > >=20 > > > > I disagree. I'd rather call it "system notifictions over NETCONF" = or > > > > something, to indicate that the notifications are related to more t= han > > > > just the NETCONF server. The way I see it is that (most of) these > > > > *events* happen in the "system", and this document defines NETCONF > > > > *notifications* representing these events. > > >=20 > > > But I think this is not true for the notifications the document > > > actually defines. > > >=20 > > > netconf-config-change: > > >=20 > > > Generated when the NETCONF server detects that the > > > or configuration datastore has changed. > >=20 > > This text clearly says that the notification is generated when the > > NETCONF server detects the event, which presumably means that the > > event happens outside the server. >=20 > So you agree that this notification carries the event that the server > detected the change, not the change event of the system's configuration > itself. No, it states the obvious that the notification is generated when the NETCONF server detects the event (it would be interesting if it was generated _before_ the event was detected :). I think the notification represents the change event of the system's configuration. > Good we agree that this is a NETCONF server notification. ;-) Sorry, no :) > > > netconf-capability-change > > >=20 > > > Generated when a is added, deleted, > > > or modified. > >=20 > > As I said, the capability addition is the way to report that the > > system e.g. loaded a new module. The event is that the system for > > example supports a new feature (maybe a licence was installed for > > 'routing'). >=20 > The event carries forward that the NETCONF server supports a new > capability or lost a capability. This might be related to a change of > the system's features, but it does not necessarily have to be. Nor > can you be sure that changes of the system's features always lead to a > change of the NETCONF capabilities. I agree that this notification represents two events - both that the system's features has changed, and that the netconf server's internal capabilities have changed (altough my guess is that this is not that common, since it probably implies a software change of the netconf server). > > > notification netconf-session-start > > >=20 > > > Generated when a new NETCONF session is started. > > > notification netconf-session-end > > >=20 > > > Generated when a NETCONF session is terminated. > >=20 > > I would like these to have broader scope. I think we've discussed this > > in the past. I think these notifications could be generated also when = a > > CLI session starts/ends, or a Web session, or whatever. =20 >=20 > I doubt it is workable nor desirable to make this an open ended "some > interesting transport session started/ended" notification. I don't see the point in having multiple lists for different mgmt protocols. Why list CLI, Web, SNMP (over ssh or something) in separate lists? Some devices might not support this, but that is fine. I want to avoid having N versions of this exact data model - cli-session-start, cli-config-change, web-config-change, snmp-config-change, etc. This just makes it more difficult for the client. What is the advantage this approach? > > > netconf-confirmed-commit > > >=20 > > > Generated when a confirmed-commit event occurs. > >=20 > > Devices that support this likely support this in the native system, > > not just in the NETCONF server. In fact, I don't think you can > > implement this correctly w/o support from the underlying system (data > > store etc). I'm pretty sure that the feature is also available in the > > CLI for such devices. >=20 > You have not convinced me yet. ;-) /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Mar 30 00:29:00 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EB23A682C for ; Wed, 30 Mar 2011 00:29:00 -0700 (PDT) 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 74EGVJK-QACY for ; Wed, 30 Mar 2011 00:28:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9BFDA3A6AD4 for ; Wed, 30 Mar 2011 00:28:59 -0700 (PDT) Received: from localhost (dhcp-413b.meeting.ietf.org [130.129.65.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 43B9F76C3AC; Wed, 30 Mar 2011 09:30:36 +0200 (CEST) Date: Wed, 30 Mar 2011 09:30:31 +0200 (CEST) Message-Id: <20110330.093031.138644799.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD3863B16562@EMBX01-HQ.jnpr.net> References: <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD3863B16562@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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2011 07:29:00 -0000 Hi, Kent Watsen wrote: > Regarding notifications on netconf-sessions, I can accept them as needed in > order to reflect the netconf-monitoring "/sessions" subtree, but I strongly > resists the idea of expanding the scope to user sessions in general (i.e. cli, > webui, etc.), as I believe that these notifications should be pushed out to a > distinct "system" or "user" capability specific to the purpose. So maybe we agree here. I don't think a special notification for just NETCONF user sessions is that useful, since that means we'd have to define special notifications for CLI user sessions, Web user sessions, etc. I think this notif was originally called sys-session-start, which is in line with what you suggested. This argument is even stronger for things like config-change and confirmed-commit. /martin From ietf@andybierman.com Wed Mar 30 01:08:51 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B78C3A6886 for ; Wed, 30 Mar 2011 01:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 A2bV9RPqCHrR for ; Wed, 30 Mar 2011 01:08:50 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 680463A6B28 for ; Wed, 30 Mar 2011 01:08:47 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2U8AN8T014140 for ; Wed, 30 Mar 2011 04:10:25 -0400 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.71.147] ([130.129.71.147:46946] helo=[130.129.71.147]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CA/BD-12945-E65E29D4; Wed, 30 Mar 2011 04:10:23 -0400 Message-ID: <4D92E569.20901@andybierman.com> Date: Wed, 30 Mar 2011 01:10:17 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Martin Bjorklund References: <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD3863B16562@EMBX01-HQ.jnpr.net> <20110330.093031.138644799.mbj@tail-f.com> In-Reply-To: <20110330.093031.138644799.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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2011 08:08:51 -0000 On 03/30/2011 12:30 AM, Martin Bjorklund wrote: > Hi, > > Kent Watsen wrote: >> Regarding notifications on netconf-sessions, I can accept them as needed in >> order to reflect the netconf-monitoring "/sessions" subtree, but I strongly >> resists the idea of expanding the scope to user sessions in general (i.e. cli, >> webui, etc.), as I believe that these notifications should be pushed out to a >> distinct "system" or "user" capability specific to the purpose. > > So maybe we agree here. I don't think a special notification for just > NETCONF user sessions is that useful, since that means we'd have to > define special notifications for CLI user sessions, Web user sessions, > etc. I think this notif was originally called sys-session-start, > which is in line with what you suggested. > > This argument is even stronger for things like config-change and > confirmed-commit. > I don't agree with expanding the scope of this draft. I could agree to allowing a server to optionally report external events if it wants to do that (MAY, not SHOULD or MUST), but I do not want to spend any effort on it (e.g., know the user name for session 0; all CLI sessions show up as session 0; knowing exactly what happened in a config-change done externally -- a server may report N external changes as 1 detected change, which may lose some intermediate changes; a server may completely miss an external CLI session start and/or CLI session end). So this would mean the text will change to say the foo-event is generated if and when the NETCONF server detects the foo-event, instead of directly coupling the foo-event to a specific NETCONF operation. > > /martin Andy From j.schoenwaelder@jacobs-university.de Wed Mar 30 02:37:26 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F5D28C0DB for ; Wed, 30 Mar 2011 02:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 D0nlxbPkBWWn for ; Wed, 30 Mar 2011 02:37:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4E2833A68CE for ; Wed, 30 Mar 2011 02:37:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB25DC000D; Wed, 30 Mar 2011 11:39:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SBMbqgdfqbIq; Wed, 30 Mar 2011 11:39:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D56B7C000B; Wed, 30 Mar 2011 11:39:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F16EC174DADE; Wed, 30 Mar 2011 11:38:58 +0200 (CEST) Date: Wed, 30 Mar 2011 11:38:58 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110330093858.GA29937@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20110329104625.GA27488@elstar.local> <20110329.134228.182416665.mbj@tail-f.com> <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110329.163703.215127896.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notifications-03 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, 30 Mar 2011 09:37:26 -0000 On Tue, Mar 29, 2011 at 04:37:03PM +0200, Martin Bjorklund wrote: > > > > notification netconf-session-start > > > > > > > > Generated when a new NETCONF session is started. > > > > notification netconf-session-end > > > > > > > > Generated when a NETCONF session is terminated. > > > > > > I would like these to have broader scope. I think we've discussed this > > > in the past. I think these notifications could be generated also when a > > > CLI session starts/ends, or a Web session, or whatever. > > > > I doubt it is workable nor desirable to make this an open ended "some > > interesting transport session started/ended" notification. > > I don't see the point in having multiple lists for different mgmt > protocols. Why list CLI, Web, SNMP (over ssh or something) in > separate lists? Some devices might not support this, but that is > fine. > > I want to avoid having N versions of this exact data model - > cli-session-start, cli-config-change, web-config-change, > snmp-config-change, etc. This just makes it more difficult for the > client. What is the advantage this approach? Lets not mix session-start with config-change. The config-change wording is fine - you get a notification when the NC server detects a config change. That is cool. For session start/end, despite questions what an SNMP session start/end really is, for tightly integrated implementations, it might be easy to generate notifications for all management interfaces (although not sure where "all" starts and ends). For loosely integrated implementations, a requirement to report all will be hard or close to impossible to implement. So the solution could be to require that all NC session starts/ends are reported and additional MGMT session starts/ends MAY be reported at the discretion of the device. But forcing this would likely be a failure. (And for SNMP, we lived so far with a session start/end notification - so this is probably not even needed.) /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 Wed Mar 30 02:38:42 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB683A6B33 for ; Wed, 30 Mar 2011 02:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 sF9YOoU9Zmr0 for ; Wed, 30 Mar 2011 02:38:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19A913A6B24 for ; Wed, 30 Mar 2011 02:38:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89BD2C000D; Wed, 30 Mar 2011 11:40:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mh+4MMt8-Wyv; Wed, 30 Mar 2011 11:40:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7BA6C000B; Wed, 30 Mar 2011 11:40:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 51102174DB30; Wed, 30 Mar 2011 11:40:15 +0200 (CEST) Date: Wed, 30 Mar 2011 11:40:15 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110330094015.GB29937@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <20110329104625.GA27488@elstar.local> <20110329.134228.182416665.mbj@tail-f.com> <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD3863B16562@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3863B16562@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notifications-03 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, 30 Mar 2011 09:38:42 -0000 On Tue, Mar 29, 2011 at 10:27:09AM -0700, Kent Watsen wrote: > Now, back to this capability, it provides notifications for both "configuration management" (see above list) as well as for the netconf server itself (not listed above). Both of these make sense, given that they reflect what the NetConf RFC defines, but I wouldn't name it "netconf system", "netconf server" or "system notifications over netconf", as none of them seem to accurately reflect its nature. I might call it "netconf base notifications", since it mostly defines notifications that reflect the "netconf:base" protocol, or "netconf monitoring notifications", since it seems to provide notifications for when the various "monitoring" subtrees change. [note: in the latter case, we might consider rev-ing the ietf-netconf-monitoring capability instead as notifications are for monitoring...] I think the term "NETCONF base notifications" is a reasonable way to resolve this terminology issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Mar 30 02:43:48 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD40A3A6B3E for ; Wed, 30 Mar 2011 02:43:48 -0700 (PDT) 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 P3vP9CML7qJj for ; Wed, 30 Mar 2011 02:43:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B74543A6B38 for ; Wed, 30 Mar 2011 02:43:47 -0700 (PDT) Received: from localhost (dhcp-413b.meeting.ietf.org [130.129.65.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 7584076C205; Wed, 30 Mar 2011 11:45:23 +0200 (CEST) Date: Wed, 30 Mar 2011 11:45:16 +0200 (CEST) Message-Id: <20110330.114516.258705594.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110330093858.GA29937@elstar.local> References: <20110329141451.GA27857@elstar.local> <20110329.163703.215127896.mbj@tail-f.com> <20110330093858.GA29937@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] js comments on draft-ietf-netconf-system-notifications-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2011 09:43:48 -0000 Juergen Schoenwaelder wrote: > So the solution could be to require that all NC session starts/ends > are reported and additional MGMT session starts/ends MAY be reported > at the discretion of the device. But forcing this would likely be a > failure. MAY be reported is fine with me. I agree that this cannot be a MUST or SHOULD. > (And for SNMP, we lived so far with a session start/end > notification - so this is probably not even needed.) One reason could be that there really are no sessions when UDP is used... But removing this notif would of course also make the problem go away ;) /martin From ietf@andybierman.com Wed Mar 30 03:33:02 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295BA28C101 for ; Wed, 30 Mar 2011 03:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSwT9kSk9Umt for ; Wed, 30 Mar 2011 03:33:01 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 78C5828C12D for ; Wed, 30 Mar 2011 03:32:58 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2UAYaS2006443 for ; Wed, 30 Mar 2011 06:34:37 -0400 Authentication-Results: cm-omr3 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [90.182.128.42] ([90.182.128.42:35456] helo=[192.168.2.7]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 67/D9-30207-C37039D4; Wed, 30 Mar 2011 06:34:36 -0400 To: "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" , j.schoenwaelder@jacobs-university.de Message-ID: <67.D9.30207.C37039D4@cm-omr3> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 30 Mar 2011 03:34:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_1301481283482" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?js_comments_on_draft-ietf-netconf-system-noti?= =?utf-8?q?fications-03?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2011 10:33:02 -0000 ------=_Part_2_1301481283482 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHJlYXNvbiBJIHdhbnQgdGhlc2Ugbm90aWZpY2F0aW9ucyBpcyB0aGF0IHBlb3BsZSB0ZW5k IHRvIGlnbm9yZSBsb2NraW5nIHNvIGtub3dpbmcgb3RoZXIgc2Vzc2lvbnMgc3RhcnRlZCBtYXkg YXZvaWQgY29sbGlzaW9ucyBtYW51YWxseS4KCkFuZHkKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0t LS0KRnJvbTogIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNvbT4KRGF0ZTogV2VkLCBN YXIgMzAsIDIwMTEgMDI6NDUKU3ViamVjdDogW05ldGNvbmZdIGpzIGNvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtbmV0Y29uZi1zeXN0ZW0tbm90aWZpY2F0aW9ucy0wMwpUbzogPGouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4KQ2M6IDxuZXRjb25mQGlldGYub3JnPgoKCkp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90 ZToKPiBTbyB0aGUgc29sdXRpb24gY291bGQgYmUgdG8gcmVxdWlyZSB0aGF0IGFsbCBOQyBzZXNz aW9uIHN0YXJ0cy9lbmRzCj4gYXJlIHJlcG9ydGVkIGFuZCBhZGRpdGlvbmFsIE1HTVQgc2Vzc2lv biBzdGFydHMvZW5kcyBNQVkgYmUgcmVwb3J0ZWQKPiBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUg ZGV2aWNlLiBCdXQgZm9yY2luZyB0aGlzIHdvdWxkIGxpa2VseSBiZSBhCj4gZmFpbHVyZS4KCk1B WSBiZSByZXBvcnRlZCBpcyBmaW5lIHdpdGggbWUuICBJIGFncmVlIHRoYXQgdGhpcyBjYW5ub3Qg YmUgYSBNVVNUCm9yIFNIT1VMRC4KCj4gKEFuZCBmb3IgU05NUCwgd2UgbGl2ZWQgc28gZmFyIHdp dGggYSBzZXNzaW9uIHN0YXJ0L2VuZAo+IG5vdGlmaWNhdGlvbiAtIHNvIHRoaXMgaXMgcHJvYmFi bHkgbm90IGV2ZW4gbmVlZGVkLikKCk9uZSByZWFzb24gY291bGQgYmUgdGhhdCB0aGVyZSByZWFs bHkgYXJlIG5vIHNlc3Npb25zIHdoZW4gVURQIGlzCnVzZWQuLi4gICBCdXQgcmVtb3ZpbmcgdGhp cyBub3RpZiB3b3VsZCBvZiBjb3Vyc2UgYWxzbyBtYWtlIHRoZQpwcm9ibGVtIGdvIGF3YXkgOykK CgovbWFydGluCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Ck5ldGNvbmYgbWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCgo= ------=_Part_2_1301481283482 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHJlYXNvbiBJIHdhbnQgdGhlc2Ugbm90aWZpY2F0aW9ucyBpcyB0aGF0IHBlb3BsZSB0ZW5k IHRvIGlnbm9yZSBsb2NraW5nIHNvIGtub3dpbmcgb3RoZXIgc2Vzc2lvbnMgc3RhcnRlZCBtYXkg YXZvaWQgY29sbGlzaW9ucyBtYW51YWxseS48YnI+PGJyPkFuZHk8YnI+PGJyPi0tLS0tIFJlcGx5 IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7 bWJqQHRhaWwtZi5jb20mZ3Q7PGJyPkRhdGU6IFdlZCwgTWFyIDMwLCAyMDExIDAyOjQ1PGJyPlN1 YmplY3Q6IFtOZXRjb25mXSBqcyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3lzdGVt LW5vdGlmaWNhdGlvbnMtMDM8YnI+VG86ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGUmZ3Q7PGJyPkNjOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+PGJyPjxicj5K dWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZSZndDsgd3JvdGU6PGJyPiZndDsgU28gdGhlIHNvbHV0aW9uIGNvdWxkIGJlIHRvIHJlcXVp cmUgdGhhdCBhbGwgTkMgc2Vzc2lvbiBzdGFydHMvZW5kczxicj4mZ3Q7IGFyZSByZXBvcnRlZCBh bmQgYWRkaXRpb25hbCBNR01UIHNlc3Npb24gc3RhcnRzL2VuZHMgTUFZIGJlIHJlcG9ydGVkPGJy PiZndDsgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGRldmljZS4gQnV0IGZvcmNpbmcgdGhpcyB3 b3VsZCBsaWtlbHkgYmUgYTxicj4mZ3Q7IGZhaWx1cmUuPGJyPjxicj5NQVkgYmUgcmVwb3J0ZWQg aXMgZmluZSB3aXRoIG1lLiAmbmJzcDtJIGFncmVlIHRoYXQgdGhpcyBjYW5ub3QgYmUgYSBNVVNU PGJyPm9yIFNIT1VMRC48YnI+PGJyPiZndDsgKEFuZCBmb3IgU05NUCwgd2UgbGl2ZWQgc28gZmFy IHdpdGggYSBzZXNzaW9uIHN0YXJ0L2VuZDxicj4mZ3Q7IG5vdGlmaWNhdGlvbiAtIHNvIHRoaXMg aXMgcHJvYmFibHkgbm90IGV2ZW4gbmVlZGVkLik8YnI+PGJyPk9uZSByZWFzb24gY291bGQgYmUg dGhhdCB0aGVyZSByZWFsbHkgYXJlIG5vIHNlc3Npb25zIHdoZW4gVURQIGlzPGJyPnVzZWQuLi4g Jm5ic3A7IEJ1dCByZW1vdmluZyB0aGlzIG5vdGlmIHdvdWxkIG9mIGNvdXJzZSBhbHNvIG1ha2Ug dGhlPGJyPnByb2JsZW0gZ28gYXdheSA7KTxicj48YnI+PGJyPi9tYXJ0aW48YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+TmV0Y29uZiBtYWlsaW5n IGxpc3Q8YnI+TmV0Y29uZkBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZjwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_2_1301481283482-- From mehmet.ersue@nsn.com Wed Mar 30 03:34:04 2011 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8393A68B7; Wed, 30 Mar 2011 03:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D9v6gze5rYI; Wed, 30 Mar 2011 03:34:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id AD91C3A68B1; Wed, 30 Mar 2011 03:34:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2UAZT2c007363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 12:35:29 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2UAZSB3009118; Wed, 30 Mar 2011 12:35:28 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 12:35:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 12:34:32 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401DDB214@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF Implementation Demos Thread-Index: Acvuxg53DHHc1EEOTpCOHsiB8UbCMw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" , X-OriginalArrivalTime: 30 Mar 2011 10:35:28.0785 (UTC) FILETIME=[3015A010:01CBEEC6] Cc: ext Vladislav Perelman , core-chairs@tools.ietf.org, 6lowpan-chairs@tools.ietf.org Subject: [Netconf] NETCONF Implementation Demos X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2011 10:34:04 -0000 Hi All, there will be two demos on Thursday between 1520-1600 in room Rokoska on Mezzanine level. This happened pretty much in an adhoc manner. 1) Demo on 'NETCONF-Light Implementation for Class 1 constrained devices' (by Vlad Perelman, Juergen Schoenwaelder - Jacobs University Bremen) 2) Demo on 'NETCONF Notification over WebSocket' (by Tomoyoki Iijima - Hitachi) Please consider to check the demos. Cheers,=20 Mehmet=20