From luchuk@snmp.com Tue Nov 1 11:26:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6121711E80C9 for ; Tue, 1 Nov 2011 11:26:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej0ezGxXgU+a for ; Tue, 1 Nov 2011 11:25:59 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D15C21F9468 for ; Tue, 1 Nov 2011 11:25:57 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA05297; Tue, 1 Nov 2011 14:24:47 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id OAA07939; Tue, 1 Nov 2011 14:24:42 -0400 (EDT) Date: Tue, 1 Nov 2011 14:24:42 -0400 (EDT) From: Alan Luchuk Message-Id: <201111011824.OAA07939@adminfs.snmp.com> To: netconf@ietf.org Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 18:26:00 -0000 Hello, Thanks for the comments. The comments are helpful, and most have been addressed in the updated draft. Hopefully the updated text clarifies and strengthens the proposal. >From: "Randy Presuhn" >To: >Date: Thu, 27 Oct 2011 10:50:22 -0700 >Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames > > >> Additionally, the NETCONF protocol [RFC6241] requires that the >> transport protocol's 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. Thus, an algorithm for >> transforming certificates to NETCONF usernames is needed. > >I think someone else has already commented on how the "MUST" >here is a bit odd. > >Is it attempting to say that >it is impossible >for the permissions >of an authenticated client identity >to *not* be known >to the server? > This text above was copied, with slight changes, from RFC 6241, Section 2.2. I left it unchanged in the latest update. >> The algorithm for deriving NETCONF usernames from TLS certificates >> is patterned after the algorithm for deriving tmSecurityNames from >> TLS certificates specified in Transport Layer Security (TLS) >> Transport Model for the Simple Network Management Protocol (SNMP) >> [RFC6353]. RFC6353 specifies that an SNMP engine must implement >> several algorithms for transforming a certificate to a tmSecurityName, >> and lets the SNMP engine deployer choose and configure the algorithm >> most suitable for the deployer's environment. > >Recapping RFC6353 does be helpful, but it's more important to answer the >question of what *this* specification requires. All this paragraph says is >"patterned after", which means "similar but likely different", and the >paragraph does not spell out what the differences are. OK. The second sentence of the paragraph has been replaced. The updated paragraph now reads: The algorithm for deriving NETCONF usernames from TLS certificates is patterned after the algorithm for deriving tmSecurityNames from TLS certificates specified in Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) [RFC6353]. Both RFC 6353 and this document require several different algorithms for deriving usernames from TLS certificates, and allow the security administrator to choose and deploy the algorithm that works best in his environment. > >> When a NETCONF server accepts a TLS connection from a NETCONF client, >> the NETCONF server must produce a NETCONF username from the certificate >> presented by the NETCONF client. The NETCONF server may use any of >> the following algorithms to produce the NETCONF username from the >> certificate presented by the NETCONF client: > >Is the use of "must" and "may deliberate? I think what you mean is: > When a NETCONF server accepts a TLS connection from a NETCONF client, > the NETCONF server attempts to derive a NETCONF username from the > certificate presented by the NETCONF client. The NETCONF server MAY > use any of the following algorithms to produce the NETCONF username > from the certificate presented by the NETCONF client: Yes, your suggested text captures the intent. The updated paragraph reads: When a NETCONF server accepts a TLS connection from a NETCONF client, the NETCONF server attempts to derive a NETCONF username from the certificate presented by the NETCONF client. If the NETCONF server cannot derive a valid NETCONF username from the client's presented certificate, then the NETCONF server MUST close the TLS connection, and MUST NOT accept NETCONF messages over it. The NETCONF server MAY use any of the following algorithms to produce the NETCONF username from the certificate presented by the NETCONF client: > >> - Map a certificate directly to a NETCONF username; > >What transforms are permitted in this mapping? The updated text reads: - Map a certificate directly to a specified, pre-configured, NETCONF username; >> - Examine the subjectAltName's rfc822Name, dnsName, and iPAddress >> fields in a pre-defined order, then use the first matching >> subjectAltName value. > >"matching" what? The updated text reads: - Examine the subjectAltName's rfc822Name, dnsName, and iPAddress fields in a pre-defined order. Return the value from the first subjectAltName field that is examined, defined, and populated with a non-empty value. If no subjectAltName field of a specific type is defined, then the examination skips that field and proceeds to examine the next field type. If a subjectAltName field is defined, but the value is not populated, or is populated by an empty value, then the examination skips that field and proceeds to examine the next field type. >> The NETCONF server MUST implement all of these algorithms, and >> allow the deployer to choose and configure the algorithm used. > >"and configure" - are there additional inputs to any of these algorithms? >If so, they need to be spelled out. > >> The problem with using the entire certificates as the identity is >> that they are difficult for people to use. It is generally accepted >> that a fingerprint of a certificate is not likely to come up with a >> collision against a fingerprint of another (different) certificate. >> Thus, assuming a good hash algorithm, using fingerprints is a safe >> way to compare two certificates. > >"Compare" is the wrong word. I'd suggest replacing the last phrase >with "a fingerprint can be a safe short-hand for identifying a certificate." Done. The updated text reads: Thus, assuming a good hash algorithm, a fingerprint can be a safe short-hand for identifying a certificate. >I would recommend that someone actually do the math to figure out >what a "safe" fingerprint size would be. Since this would be used for >configuration, interoperability is a concern, so the fingerprint algorithm >needs to be spelled out. I'm not a crypto-guru, but I trust 1) the crypto-gurus already know what "safe" fingerprint sizes are; 2) the safe fingerprint sizes vary depending upon the hash algorithm; 3) crypto-tools and libraries return fingerprints of "safe" sizes. If more needs to be said here, I'm open to suggested text. >> If if a locally held copy of a trusted CA certificate is configured >> in the transformation container, and that CA certificate was used to >> validate the path to the presented certificate, then the NETCONF >> server should use that list entry in the transformation container. >> All presented certificates validated by the configured CA certificate >> will be transformed to NETCONF usernames using the same transformation >> algorithm. > >This paragraph is just plain baffling in context. It sounds like it presumes >a bunch of stuff spelled out in the Yang. Agreed. The important content of this paragraph also appears in the YANG module, so I deleted it from here. > >... >> leaf certificate-to-username-transform-count { >> type yang:gauge32; >> description >> "A count of the number of certificate-to-username-transforms."; >> config false; >> } > >Why is this needed? > >> leaf certificate-to-username-transform-last-changed { >> type yang:date-and-time; >> description >> "The date and time when the certificate-to-username-transforms >> was last modified through any means. The value 0 means the >> certificate-to-username-transforms has not been modified since >> the NETCONF server was started."; >> config false; >> } > >Why is this needed? If it's there for the reason I think it's there, limiting it >to "since the NETCONF server was started" defeats the purpose. Fixed. Deleted the certificate-to-username-transform-count, and updated the certificate-to-username-transform-last-changed description. >> NETCONF username to identify with the remote connection. This > >perhaps s/identify/associate/ Done. >> is done by considering each active list entry from this container >> in prioritized order according to its index value. >> Each list entry's certificate-fingerprint value determines >> whether the list entry is a match for the incoming connection: >> >> 1) If the list entry's certificate-fingerprint value >> identifies the presented certificate, then consider the > >s/identifies/matches that of/ Done. >> 2) If the list entry's certificate-fingerprint value >> identifies a locally held copy of a trusted CA > >s/identifies/matches that of/ Done. > >> certificate and that CA certificate was used to >> validate the path to the presented certificate, then >> consider the list entry as a successful match. > >This seems just a bit odd. Why should CAs be treated as NETCONF users? Added the second paragraph of text to clarify the intent. The section now reads: 2) If the list entry's certificate-fingerprint value matches that of a locally held copy of a trusted CA certificate, and that CA certificate was used to validate the path to the presented certificate, then consider the list entry as a successful match. This feature lets the NETCONF server derive NETCONF usernames from all certificates signed by the trusted CA certificate. The NETCONF server will derive all NETCONF usernames using the same derivation algorithm. The NETCONF server requires only a single container entry to configure this behavior. >> Once a matching list entry has been found, the NETCONF server uses >> the map-type value to determine how the NETCONF username associated >> with the session should be determined. See the map-type column's > >General note - is "column" the preferred terminology here and elsewhere? >It sounds rather MIB-ish. Changed "column" to "leaf" throughout. >> If no matching and valid list entry can be found, the connection MUST >> be closed and NETCONF messages MUST NOT be accepted over it. > >This seems quite reasonable, but contradicts the statement from above >"Additionally, the NETCONF protocol [RFC6241] requires that the >transport protocol's authentication process MUST result in an >authenticated client identity whose permissions are known to the >server." I left this as-is. I think the intent is clear. If others think a different behavior would be better, I think the options are: - Terminate the connection if no valid NETCONF username can be produced; - Continue the connection with an invalid NETCONF username; - Produce a default NETCONF username; - Others? >> Missing values of index are acceptable and implementations > >How can the value of index be missing? It's a key, with a simple integer range. Changed "missing" to "non-consecutive." >> recommended that administrators skip index values to leave room > >Do you mean "RECOMMENDED"? Not sure this recommendation is as strong as "RECOMMENDED" in RFC 2119. I left it lowercase, but have no preference, if anyone believes it should be upper case. >> Users are encouraged to make use of certificates with > >By "users" do you mean "security administrators"? Yes. Thanks. Changed "Users" to "Security administrators". >> leaf data { >> type string { >> length "1..max"; >> } >> description >> "Auxiliary data used as optional configuration information for >> a given mapping specified by the map-type column. Only some >> mapping systems will make use of this column. The value in this >> column MUST be ignored for any mapping type that does not require >> data present in this column."; > >What does "MUST be ignored" mean? During get-config? During edit-config? Changed the text of the second sentence to read: When the NETCONF server derives the NETCONF username from the client's presented certificate, the value in this leaf MUST be ignored for any mapping type that does not require data present in this column. > >... >> Implementations may optionally support TLS Pre-Shared Key (PSK) >> authentication. RFC 4279 describes pre-shared key ciphersuites for >> TLS. During the TLS Handshake, the client indicates which key to use >> by including a PSK identity in the TLS ClientKeyExchange message >> [RFC4279]. On the server side, this PSK identity is used to lookup the > >s/lookup/look up/ Changed. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From bwijnen@ripe.net Fri Nov 4 07:49:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9E21F8C16 for ; Fri, 4 Nov 2011 07:49:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgtL6fxg1bxA for ; Fri, 4 Nov 2011 07:49:28 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id DE8AF21F8B8C for ; Fri, 4 Nov 2011 07:49:27 -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 1RML58-0003X4-8z for netconf@ietf.org; Fri, 04 Nov 2011 15:49:26 +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 1RML57-0005vK-M4 for netconf@ietf.org; Fri, 04 Nov 2011 15:49:22 +0100 Message-ID: <4EB3FB71.2000003@ripe.net> Date: Fri, 04 Nov 2011 15:49:21 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf References: <4EB3F1EE.2080102@ripe.net> In-Reply-To: <4EB3F1EE.2080102@ripe.net> X-Forwarded-Message-Id: <4EB3F1EE.2080102@ripe.net> Content-Type: multipart/mixed; boundary="------------070901040707010107080204" X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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: 5ef2bffdfa2294c21c35da1b4f77885e48e82eefdbacab9094087de3dbd963a4 Subject: [Netconf] [www.ietf.org/rt #42803] AutoReply: request to publish draft-ietf-netconf-access-control-06.txt a Proposed STandard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:49:29 -0000 This is a multi-part message in MIME format. --------------070901040707010107080204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [www.ietf.org/rt #42803] AutoReply: request to publish draft-ietf-netconf-access-control-06.txt a Proposed STandard Date: Fri, 04 Nov 2011 07:08:52 -0700 From: IETF-IESG via RT Reply-To: iesg-secretary@ietf.org To: bwijnen@ripe.net snip.. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #42803]. Please include the string: [www.ietf.org/rt #42803] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Dear secretariat and AD, we believe that this document is ready for consideration by the IESG (after IETF LC of course) to be published as a PS RFC. Attached is the document write-up Thank you, Bert Wijnen - Netconf co-chair and document-shepherd Mehmet Ersue - NetConf co-chair --------------070901040707010107080204 Content-Type: text/plain; name="111104_NETCONF-Access-Control-Model-Doc-Writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="111104_NETCONF-Access-Control-Model-Doc-Writeup.txt" --------------------------------------------------------------------------- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I, Bert Wijnen, am the Document Shepherd for this document. I have personally reviewed this version of the document and I believe it is ready for publication. Adequate review has occurred from WG members. We've gone to a couple of WG Last Calls, which resulted in comments and corrections/clarifications to the current document. The issues raised in the reviews have been discussed on the mailing list and fixed in the last versions. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from working group and non-working group members, mostly from NETCONF and NETMOD WGs. I do not have any concerns about the depth or breadth of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. We tried very hard to get review from our Security Advisor but he seemed to be too busy. We then got the preliminary review from the Security ADs and their comments have been addressed in the latest revision. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns about the technical merit of the document. There are no IPR disclosures filed on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus in the WG to publish this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are no nits in this draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has both normative references and informative references, and they have been provided properly. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? IANA considerations are complete and consistent with RFC 3688. The draft requests to register one XML namespace URN and one module name in the 'YANG Module Names' registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The YANG module in the document has been checked for validity and is syntactically correct. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document addresses access control mechanisms for the Operation and Content layers of NETCONF, as defined in RFC6241. It contains three main sections: 1. Access Control Design Objectives 2. NETCONF Access Control Model (NACM) 3. YANG Data Model (ietf-netconf-acm.yang) Working Group Summary The document has been extensively 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 Working Group. The Security ADs have also reviewed revision 5 of the document. We specifically asked for a Detailed Security review, because the content of this document is all about access control and secure and properly authorized access to the NETCONF protocol and content. The last WGLC did raise only minor issues. The changes have been accepted by the WG. Document Quality mplementations of earlier drafts do (partially) exist and it is expected that NETCONF implementations will be extended once this document gets published as proposed standard. Bert Wijnen Document Shepherd --------------070901040707010107080204-- From bwijnen@ripe.net Fri Nov 4 08:10:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6921F8C5A for ; Fri, 4 Nov 2011 08:10:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNKV9oTb0ukf for ; Fri, 4 Nov 2011 08:10:23 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id B26A321F8C45 for ; Fri, 4 Nov 2011 08:10:23 -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 1RMLPG-0005bO-Lt for netconf@ietf.org; Fri, 04 Nov 2011 16:10:13 +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 1RMLPD-0007ye-A0 for netconf@ietf.org; Fri, 04 Nov 2011 16:10:08 +0100 Message-ID: <4EB4004E.4000700@ripe.net> Date: Fri, 04 Nov 2011 16:10:06 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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: 5ef2bffdfa2294c21c35da1b4f77885e28ff1468448ceca798991c286b9d1c85 Subject: [Netconf] Fwd: [www.ietf.org/rt #42803] request to publish draft-ietf-netconf-access-control-06.txt a Proposed STandard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:10:24 -0000 FYI -------- Original Message -------- Subject: [www.ietf.org/rt #42803] request to publish draft-ietf-netconf-access-control-06.txt a Proposed STandard Date: Fri, 04 Nov 2011 08:09:03 -0700 From: Cindy Morgan via RT Reply-To: iesg-secretary@ietf.org To: bwijnen@ripe.net Hi Bert, This document has been added to the I-D tracker in state Publication Requested. Best regards, Cindy On Fri Nov 04 07:08:51 2011, bwijnen@ripe.net wrote: > Dear secretariat and AD, > > we believe that this document is ready for consideration > by the IESG (after IETF LC of course) to be published > as a PS RFC. > > Attached is the document write-up > > Thank you, > Bert Wijnen - Netconf co-chair and document-shepherd > Mehmet Ersue - NetConf co-chair From mehmet.ersue@nsn.com Fri Nov 4 08:15:41 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6DA21F8C98 for ; Fri, 4 Nov 2011 08:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZImK2EwZpMB for ; Fri, 4 Nov 2011 08:15:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57D21F8C96 for ; Fri, 4 Nov 2011 08:15:40 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA4FFXG3031649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 16:15:33 +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 pA4FFIJk007558 for ; Fri, 4 Nov 2011 16:15:32 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 16:15:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 4 Nov 2011 16:05:34 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402EC7FAC@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [www.ietf.org/rt #42804] AutoReply: Request to consider for publication as PS RFC Thread-Index: Acya/e+55FyYOsJ2TFWhdN9zgrM8jwABTExQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 04 Nov 2011 15:15:00.0497 (UTC) FILETIME=[85450810:01CC9B04] Subject: [Netconf] FW: [www.ietf.org/rt #42804] AutoReply: Request to consider for publication as PS RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:15:42 -0000 RllJDQoNCk1laG1ldCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBJ RVRGLUlFU0cgdmlhIFJUIFttYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmddIA0KU2VudDog RnJpZGF5LCBOb3ZlbWJlciAwNCwgMjAxMSAzOjI4IFBNDQpUbzogRXJzdWUsIE1laG1ldCAoTlNO IC0gREUvTXVuaWNoKQ0KU3ViamVjdDogW3d3dy5pZXRmLm9yZy9ydCAjNDI4MDRdIEF1dG9SZXBs eTogUmVxdWVzdCB0byBjb25zaWRlciA8ZHJhZnQtaWV0Zi1uZXRjb25mLXN5c3RlbS1ub3RpZmlj YXRpb25zPiBmb3IgcHVibGljYXRpb24gYXMgUFMgUkZDIA0KDQoNCkdyZWV0aW5ncywNCg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIGF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGluIHJlc3BvbnNlIHRv IHRoZQ0KY3JlYXRpb24gb2YgYSB0cm91YmxlIHRpY2tldCByZWdhcmRpbmc6DQoJIlJlcXVlc3Qg dG8gY29uc2lkZXIgPGRyYWZ0LWlldGYtbmV0Y29uZi1zeXN0ZW0tbm90aWZpY2F0aW9ucz4gZm9y IHB1YmxpY2F0aW9uIGFzIFBTIFJGQyIsIA0KYSBzdW1tYXJ5IG9mIHdoaWNoIGFwcGVhcnMgYmVs b3cuDQoNClRoZXJlIGlzIG5vIG5lZWQgdG8gcmVwbHkgdG8gdGhpcyBtZXNzYWdlIHJpZ2h0IG5v dy4gIFlvdXIgdGlja2V0IGhhcyBiZWVuDQphc3NpZ25lZCBhbiBJRCBvZiBbd3d3LmlldGYub3Jn L3J0ICM0MjgwNF0uDQoNClBsZWFzZSBpbmNsdWRlIHRoZSBzdHJpbmc6DQoNCiAgICAgICAgIFt3 d3cuaWV0Zi5vcmcvcnQgIzQyODA0XQ0KDQppbiB0aGUgc3ViamVjdCBsaW5lIG9mIGFsbCBmdXR1 cmUgY29ycmVzcG9uZGVuY2UgYWJvdXQgdGhpcyBpc3N1ZS4gVG8gZG8gc28sIA0KeW91IG1heSBy ZXBseSB0byB0aGlzIG1lc3NhZ2UuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmsg eW91LA0KICAgICAgICAgICAgICAgICAgICAgICAgaWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmcNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KSGkgRGFuLCANCg0KYmFzZWQgb24gdGhlIGNvbnNlbnN1cyBpbiB0 aGUgTkVUQ09ORiBXRyBhbmQgYXMgZGlzY3Vzc2VkIHdpdGggDQpteSBjby1jaGFpciBhbmQgdGhl IGF1dGhvciBvZiB0aGUgZHJhZnQgTkVUQ09ORiBCYXNlIE5vdGlmaWNhdGlvbnMNCndlIHRoaW5r IHRoYXQgd2UgYXJlIHJlYWR5IHRvIGJyaW5nIHRoZSBkb2N1bWVudCB0byB0aGUgbmV4dCBzdGVw Lg0KDQpJIHdvdWxkIGxpa2UgdG8gcGxlYXNlIHlvdSB0byBpbml0aWF0ZSB0aGUgbmVjZXNzYXJ5 IHByb2Nlc3MgZm9yIA0KdGhlIHB1YmxpY2F0aW9uIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1zeXN0 ZW0tbm90aWZpY2F0aW9ucyAoTmV0d29yayANCkNvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENP TkYpIEJhc2UgTm90aWZpY2F0aW9ucykuDQoNClBsZWFzZSBmaW5kIGJlbG93IHRoZSBkb2N1bWVu dCB3cml0ZS11cCBmb3IgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dGNvbmYtc3lzdGVtLW5vdGlmaWNhdGlvbnMtMDYuDQoNClRoYW5rIHlvdS4NCg0KQmVzdCBSZWdh cmRzLA0KTWVobWV0IEVyc3VlIC0gTmV0Y29uZiBjby1jaGFpciBhbmQgZG9jdW1lbnQtc2hlcGhl cmQNCkJlcnQgV2lqbmVuIC0gTmV0Q29uZiBjby1jaGFpcg0KDQogPDwxMTExMDRfTkVUQ09ORi1C YXNlLU5vdGlmLURvYy1Xcml0ZXVwLnR4dD4+IA0KW3NhbWUgdGV4dCBhcyBhdHRhY2htZW50XQ0K DQooMS5hKSBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyBI YXMgdGhlICANCiAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhp cyB2ZXJzaW9uIG9mIHRoZSAgDQogICAgICBkb2N1bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRv ZXMgaGUgb3Igc2hlIGJlbGlldmUgdGhpcyAgDQogICAgICB2ZXJzaW9uIGlzIHJlYWR5IGZvciBm b3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8gDQogDQogICAgICANCiAgICAg SSwgTWVobWV0IEVyc3VlLCBhbSB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgZm9yIHRoaXMgZG9jdW1l bnQuIA0KICAgICBJIGhhdmUgcGVyc29uYWxseSByZXZpZXdlZCB0aGlzIHZlcnNpb24gb2YgdGhl IGRvY3VtZW50IGFuZCBJIA0KICAgICBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv bi4gDQogICAgICANCiAgICAgQWRlcXVhdGUgcmV2aWV3IGhhcyBvY2N1cnJlZCBmcm9tIFdHIG1l bWJlcnMsIGFuZCBpdCBoYXMgYmVlbiANCiAgICAgcmV2aWV3ZWQgZXNwZWNpYWxseSBieSBNYXJ0 aW4gQmpvcmtsdW5kLCBNdXRodW1heWFuIE1hZGhheXlhbiwgDQogICAgIFJhbmR5IFByZXN1aG4s IERhbiBSb21hc2NhbnUsIFBoaWwgU2hhZWZlciwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCANCiAg ICAgS2VudCBXYXRzb24sIGFuZCBCZXJ0IFdpam5lbi4gVGhlIGlzc3VlcyByYWlzZWQgaW4gdGhl IHJldmlld3MgaGF2ZQ0KDQogICAgIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3Qg YW5kIGZpeGVkIGluIHRoZSBsYXN0IHZlcnNpb25zLiANCiAgICAgICAgDQogDQooMS5iKSBIYXMg dGhlIGRvY3VtZW50IGhhZCBhZGVxdWF0ZSByZXZpZXcgYm90aCBmcm9tIGtleSBXRyBtZW1iZXJz ICANCiAgICAgIGFuZCBmcm9tIGtleSBub24tV0cgbWVtYmVycz8gRG9lcyB0aGUgRG9jdW1lbnQg U2hlcGhlcmQgaGF2ZSAgDQogICAgICBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yIGJy ZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCAgDQogICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPyAg ICAgIA0KIA0KICAgICAgVGhlIGRvY3VtZW50IGhhcyBoYWQgYWRlcXVhdGUgcmV2aWV3IGZyb20g d29ya2luZyBncm91cCBhbmQgDQogICAgICBub24td29ya2luZyBncm91cCBtZW1iZXJzLCBtb3N0 bHkgZnJvbSBORVRDT05GIGFuZCBORVRNT0QgV0dzLiAgDQogICAgICBJIGRvIG5vdCBoYXZlIGFu eSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZiByZXZpZXcuDQoNCiAgICAg IA0KIA0KKDEuYykgRG9lcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBjb25jZXJucyB0aGF0 IHRoZSBkb2N1bWVudCAgDQogICAgICBuZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxh ciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLCAgDQogICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0 aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBmYW1pbGlhciB3aXRoICANCiAgICAgIEFBQSwgaW50 ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1MPyANCiANCiAgICAgIE5vLiANCiANCigxLmQpIERvZXMg dGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yICANCiAg ICAgIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJlYSBE aXJlY3RvciAgDQogICAgICBhbmQvb3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3Ig ZXhhbXBsZSwgcGVyaGFwcyBoZSAgDQogICAgICBvciBzaGUgaXMgdW5jb21mb3J0YWJsZSB3aXRo IGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50LCBvciAgDQogICAgICBoYXMgY29uY2VybnMg d2hldGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55ICANCiAgICAgIGV2 ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0 ZWQgIA0KICAgICAgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQs IGRldGFpbCB0aG9zZSAgDQogICAgICBjb25jZXJucyBoZXJlLiBIYXMgYW4gSVBSIGRpc2Nsb3N1 cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50ICANCiAgICAgIGJlZW4gZmlsZWQ/IElmIHNvLCBw bGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byB0aGUgIA0KICAgICAgZGlzY2xvc3VyZSBhbmQg c3VtbWFyaXplIHRoZSBXRyBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIG9uICANCiAgICAgIHRo aXMgaXNzdWUuDQoNCiAgICAgIFRoZXJlIGFyZSBubyBjb25jZXJucyBhYm91dCB0aGUgdGVjaG5p Y2FsIG1lcml0IG9mIHRoZSBkb2N1bWVudC4gDQogICAgICBUaGVyZSBhcmUgbm8gSVBSIGRpc2Ns b3N1cmVzIGZpbGVkIG9uIHRoaXMgZG9jdW1lbnQuDQoNCiANCigxLmUpIEhvdyBzb2xpZCBpcyB0 aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0ICANCiAgICAgIHJl cHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1YWxzLCB3aXRo ICANCiAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUg dW5kZXJzdGFuZCBhbmQgIA0KICAgICAgYWdyZWUgd2l0aCBpdD8gDQogIA0KICAgICAgVGhlcmUg aXMgc3Ryb25nIGNvbnNlbnN1cyBpbiB0aGUgV0cgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50Lg0K DQogDQooMS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBp bmRpY2F0ZWQgZXh0cmVtZSAgDQogICAgICBkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1bW1h cmlzZSB0aGUgYXJlYXMgb2YgY29uZmxpY3QgaW4gIA0KICAgICAgc2VwYXJhdGUgZW1haWwgbWVz c2FnZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdCAgDQogICAgICBzaG91 bGQgYmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyAg DQogICAgICBlbnRlcmVkIGludG8gdGhlIElEIFRyYWNrZXIuKSANCiANCiAgICAgIE5vLiANCiAN CiANCigxLmcpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmllZCB0 aGF0IHRoZSAgDQogICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChTZWUgIA0K ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9JRC1DaGVja2xpc3QuaHRtbCBhbmQgIA0KICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8pLiBCb2lsZXJwbGF0ZSBjaGVja3Mg YXJlICANCiAgICAgIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUgdGhvcm91Z2gu IEhhcyB0aGUgZG9jdW1lbnQgIA0KICAgICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNyaXRlcmlh IGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRoZSBNSUIgIA0KICAgICAgRG9jdG9yLCBtZWRpYSB0eXBl IGFuZCBVUkkgdHlwZSByZXZpZXdzPyANCiAgICAgIA0KICAgICAgWWVzLiBUaGVyZSBhcmUgbm8g bml0cyBpbiB0aGlzIGRyYWZ0Lg0KICAgDQogDQooMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0 IGl0cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZCAgDQogICAgICBpbmZvcm1hdGl2ZT8g QXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0ICANCiAgICAg IGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5j bGVhciAgDQogICAgICBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwg d2hhdCBpcyB0aGUgIA0KICAgICAgc3RyYXRlZ3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/IEFyZSB0 aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyAgDQogICAgICB0aGF0IGFyZSBkb3dud2FyZCByZWZl cmVuY2VzLCBhcyBkZXNjcmliZWQgaW4gW1JGQzM5NjddPyBJZiAgDQogICAgICBzbywgbGlzdCB0 aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgIA0KICAgICAgRGly ZWN0b3IgaW4gdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUgZm9yIHRoZW0gW1JGQzM5NjddLiANCiAN CiAgICAgIFRoZSBkb2N1bWVudCBoYXMgb25seSBub3JtYXRpdmUgcmVmZXJlbmNlcy4gDQogDQog DQooMS5pKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgdGhlIGRvY3Vt ZW50IElBTkEgIA0KICAgICAgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29u c2lzdGVudCB3aXRoIHRoZSBib2R5ICANCiAgICAgIG9mIHRoZSBkb2N1bWVudD8gSWYgdGhlIGRv Y3VtZW50IHNwZWNpZmllcyBwcm90b2NvbCAgDQogICAgICBleHRlbnNpb25zLCBhcmUgcmVzZXJ2 YXRpb25zIHJlcXVlc3RlZCBpbiBhcHByb3ByaWF0ZSBJQU5BICANCiAgICAgIHJlZ2lzdHJpZXM/ IEFyZSB0aGUgSUFOQSByZWdpc3RyaWVzIGNsZWFybHkgaWRlbnRpZmllZD8gSWYgIA0KICAgICAg dGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5lIHRoZSAg DQogICAgICBwcm9wb3NlZCBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyeSBhbmQgYW4g YWxsb2NhdGlvbiAgDQogICAgICBwcm9jZWR1cmUgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zPyBE b2VzIGl0IHN1Z2dlc3QgYSAgDQogICAgICByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVn aXN0cnk/IFNlZSBbUkZDNTIyNl0uIElmIHRoZSAgDQogICAgICBkb2N1bWVudCBkZXNjcmliZXMg YW4gRXhwZXJ0IFJldmlldyBwcm9jZXNzIGhhcyBTaGVwaGVyZCAgDQogICAgICBjb25mZXJyZWQg d2l0aCB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvciBzbyB0aGF0IHRoZSBJRVNHICANCiAg ICAgIGNhbiBhcHBvaW50IHRoZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0 aW9uPyANCiANCiAgICAgIElBTkEgY29uc2lkZXJhdGlvbnMgYXJlIGNvbXBsZXRlIGFuZCBjb25z aXN0ZW50IHdpdGggUkZDIDM2ODguDQogICAgIFRoZSBkcmFmdCByZXF1ZXN0cyB0byByZWdpc3Rl ciBvbmUgWE1MIG5hbWVzcGFjZSBVUk4gYW5kIG9uZSANCiAgICAgIG1vZHVsZSBuYW1lIGluIHRo ZSAnWUFORyBNb2R1bGUgTmFtZXMnIHJlZ2lzdHJ5Lg0KDQogDQooMS5qKSBIYXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlICANCiAgICAgIGRvY3Vt ZW50IHRoYXQgYXJlIHdyaXR0ZW4gaW4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MICAN CiAgICAgIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBj b3JyZWN0bHkgaW4gIA0KICAgICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/DQoNCiAgICAgVGhlIFlB TkcgbW9kdWxlIGluIHRoZSBkb2N1bWVudCBoYXMgYmVlbiBjaGVja2VkIGZvciB2YWxpZGl0eS4g DQogDQogDQooMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBE b2N1bWVudCAgDQogICAgICBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1 Y2ggYSBEb2N1bWVudCAgDQogICAgICBBbm5vdW5jZW1lbnQgV3JpdGUtVXA/IFJlY2VudCBleGFt cGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlIA0KICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBm b3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgIA0KICAgICAgYW5ub3VuY2VtZW50 IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6ICAgICAgICAgICAgDQogDQogICAgICBU ZWNobmljYWwgU3VtbWFyeSAgDQoNCiAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcg bW9kdWxlIHRoYXQgYWxsb3dzIGEgTkVUQ09ORiBjbGllbnQgDQogICAgICB0byByZWNlaXZlIG5v dGlmaWNhdGlvbnMgZm9yIHNvbWUgY29tbW9uIHN5c3RlbSBldmVudHMuIEFzIHN1Y2ggDQogICAg ICB0aGUgZG9jdW1lbnQgc3VwcG9ydHMgdGhlIG1vbml0b3Jpbmcgb2YgYmFzZSBzeXN0ZW0gZXZl bnRzIHdpdGhpbiANCiAgICAgIHRoZSBORVRDT05GIHNlcnZlci4gIA0KDQogICAgICBXb3JraW5n IEdyb3VwIFN1bW1hcnkgIA0KDQogICAgICBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gbG9uZ2x5IGRp c2N1c3NlZCBpbiB0aGUgV29ya2luZyBHcm91cCwgDQogICAgICBpbmNsdWRpbmcgc2V2ZXJhbCBX RyBMYXN0IENhbGxzLiBUaGUgY29tbWVudHMgYW5kIHJldmlld3MgaGVscGVkIA0KICAgICAgdG8g aW1wcm92ZSB0aGUgZG9jdW1lbnQgYSBsb3QgYW5kIHRoZSBjdXJyZW50IHZlcnNpb24gcmVmbGVj dHMgdGhlDQoNCiAgICAgIGNvbnNlbnN1cyBvZiB0aGUgV29ya2luZyBHcm91cC4gDQogICAgICBU aGVyZSB3YXMgc29tZSBkZWJhdGUgb24gdGhlIHNjb3BlIG9mIHRoZSBkcmFmdC4gS2VudCBXYXRz ZW4gd2FzDQogICAgICB0aGUgb25seSBwZXJzb24gd2hvIHByb3Bvc2VkIHRoZSBkb2N1bWVudCB0 byBjb3ZlciBhIG11Y2ggYmlnZ2VyIA0KICAgICAgc2NvcGUuIFRoZSBzeXN0ZW0tc3RhcnR1cCBu b3RpZmljYXRpb24gaGFzIGJlZW4gcmVtb3ZlZCBhZnRlciBzb21lDQoNCiAgICAgIGRpc2N1c3Np b24uICAgDQogICAgICBUaGUgbGFzdCBXR0xDIGRpZCByYWlzZSBvbmx5IG1pbm9yIGlzc3Vlcy4g VGhlIGNoYW5nZXMgaGF2ZSBiZWVuIA0KICAgICAgYWNjZXB0ZWQgYnkgdGhlIFdHIHdpdGggc29t ZSBhZGRpdGlvbmFsIGRpc2N1c3Npb24gYW5kIGJ1ZyBmaXhpbmcuDQoNCg0KICAgICAgRG9jdW1l bnQgUXVhbGl0eSANCg0KICAgICAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBORVRDT05GIGltcGxlbWVu dGF0aW9ucyB3aWxsIGJlIGV4dGVuZGVkIG9uY2UgDQogICAgICB0aGlzIGRvY3VtZW50IGdldHMg cHVibGlzaGVkIGFzIHByb3Bvc2VkIHN0YW5kYXJkLg0KDQoNCk1laG1ldCBFcnN1ZQ0KRG9jdW1l bnQgU2hlcGhlcmQNCg0K From leonidas@netmode.ntua.gr Mon Nov 7 03:24:55 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06E021F8B1B for ; Mon, 7 Nov 2011 03:24:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJlmnJlgq4yZ for ; Mon, 7 Nov 2011 03:24:55 -0800 (PST) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC221F8B17 for ; Mon, 7 Nov 2011 03:24:54 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by diomedes.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pA7BOrkt003538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Nov 2011 13:24:53 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pA7BOr7i021444; Mon, 7 Nov 2011 13:24:53 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: netconf@ietf.org Date: Mon, 07 Nov 2011 13:23:54 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]); Mon, 07 Nov 2011 13:24:53 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at diomedes.noc.ntua.gr X-Virus-Status: Clean Subject: [Netconf] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 11:24:55 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From dromasca@avaya.com Mon Nov 7 05:13:09 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C640F21F8B77 for ; Mon, 7 Nov 2011 05:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.331 X-Spam-Level: X-Spam-Status: No, score=-103.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86kQj2edkCjY for ; Mon, 7 Nov 2011 05:13:09 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3251821F8B7A for ; Mon, 7 Nov 2011 05:13:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAILYt07GmAcF/2dsb2JhbABDmkCPJYEFgXQBAQMSHgpRARUVBgwMB1cBBBsanXSEEptSiEhjBJlxjB0 X-IronPort-AV: E=Sophos;i="4.69,470,1315195200"; d="scan'208";a="313202372" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Nov 2011 08:13:08 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Nov 2011 08:12:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 14:13:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: AD review of draft-ietf-netconf-access-control-06 thread-index: AcydTv1tog8GnIowTjqiAimE52aY1A== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] AD review of draft-ietf-netconf-access-control-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:13:09 -0000 I have performed the AD review of draft-ietf-netconf-access-control-06. There are no show-stoppers in this document, so I am sending it to IETF Last Call. However, because of the timing conflict with the IETF meeting which will keep busy many IETF contributors I will ask for the Last Call period to be one week longer than usual (three weeks instead of the usual two weeks).=20 Please consider the questions and comments below together with the other Last Call comments. The Technical comments are marked T and the Editorial comments are marked E.=20 T1. In Section 2.5:=20 It is necessary that the user-to-group mapping can be delegated to a central server, such as a RADIUS server [RFC2865] [RFC5607]. Since authentication is performed by the NETCONF transport layer, and RADIUS performs authentication and service authorization at the same time, the underlying NETCONF transport needs to be able to report a set of group names associated with the user to the server. How does this requirement reflect in the rest of the document or maybe does it need future work in RADEXT or in the YANG module for the reporting part?=20 T2. In Section 3.1.1:=20 o The entire ACM can be disabled during operation, in order to debug operational problems. I think that the Security Considerations section needs to deal with this case - at a minimum draw the attention of operators and implementers on the existence of this mode, maybe make recommendations about how the option of disabling the ACM can be prevented from becoming a potential source of security attack. Just establishing enable as default mode is not sufficient IMO.=20 T3. Should not the default values of the four global enforcement control switches defined in section 3.3.3 be specified? If no, why?=20 E1. In Section 2.7:=20 Access control rules to restrict access operations on specific subtrees within the configuration datastore needs to be supported. s/needs/need/ E2. Why is the following paragraph part of sub-section 3.3.1 Users?=20 The server MAY support a "recovery session" mechanism, which will bypass all access control enforcement. This is useful for restricting initial access and repairing a broken access control configuration. E3. I am questioning whether the capitalization of SHOULD in the first paragraph of 3.7.3 is needed. If I understood correctly the logic of using capitalized keywords in the rest of the document, the scarce usage is restricted to the instances where clear requirements are made on server to allow interoperable definitions of NACM. This seems to be an exception.=20 From iesg-secretary@ietf.org Mon Nov 7 07:05:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864DE21F8C1C; Mon, 7 Nov 2011 07:05:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmk8R8bxzC6I; Mon, 7 Nov 2011 07:05:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70F721F8C0C; Mon, 7 Nov 2011 07:05:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111107150545.20925.6634.idtracker@ietfa.amsl.com> Date: Mon, 07 Nov 2011 07:05:45 -0800 Cc: netconf@ietf.org Subject: [Netconf] Last Call: (Network Configuration Protocol (NETCONF) Access Control Model) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:05:50 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Network Configuration Protocol (NETCONF) Access Control Model' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that 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 protocol operations and content. This document defines such an access control model. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ No IPR declarations have been submitted directly on this I-D. From bertietf@bwijnen.net Mon Nov 7 07:25:41 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D851421F8AF0 for ; Mon, 7 Nov 2011 07:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moqjDohDvD9f for ; Mon, 7 Nov 2011 07:25:41 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3021F8AD1 for ; Mon, 7 Nov 2011 07:25:40 -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 1RNR4o-0004UL-Qd for netconf@ietf.org; Mon, 07 Nov 2011 16:25:39 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RNR4o-0000AH-M9 for netconf@ietf.org; Mon, 07 Nov 2011 16:25:34 +0100 Message-ID: <4EB7F86E.8030600@bwijnen.net> Date: Mon, 07 Nov 2011 16:25:34 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Netconf References: <20111107150545.20925.6634.idtracker@ietfa.amsl.com> In-Reply-To: <20111107150545.20925.6634.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111107150545.20925.6634.idtracker@ietfa.amsl.com> 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: 86ab03e524994f79ca2c75a176445dd41f813950754337cac8b897530a0670f4 Subject: [Netconf] Fwd: Last Call: (Network Configuration Protocol (NETCONF) Access Control Model) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:25:42 -0000 So, WG and specifically editors/authors, This IETF Last Call runs till 28 Nov. Our AD (Dan) is planning to put this document on the IESG agenda for 1 Dec. So it is important that you/we respond to any IETF LC comments/questions promptly. This so we can try to come to closure on these before th actual IESG telechat occurs. That way, hopefully this document gets approved BEFORE the end of this calendar year. We can start with Dan comments from his AD review (which he posted earler today). Bert document shepherd. -------- Original Message -------- Subject: Last Call: (Network Configuration Protocol (NETCONF) Access Control Model) to Proposed Standard Date: Mon, 07 Nov 2011 07:05:45 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: netconf@ietf.org The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Network Configuration Protocol (NETCONF) Access Control Model' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that 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 protocol operations and content. This document defines such an access control model. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Mon Nov 7 07:30:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D790621F8B4E for ; Mon, 7 Nov 2011 07:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xXTtYdjhGWQ for ; Mon, 7 Nov 2011 07:30:50 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB6A21F8B4C for ; Mon, 7 Nov 2011 07:30:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAFT5t06HCzI1/2dsb2JhbAA6CZpAjyaBBYF0AQEDEh4KPRQBFRUGDAwHVwEEGwwOnjaEEptvhXuCTWMEmXGMHQ X-IronPort-AV: E=Sophos;i="4.69,470,1315195200"; d="scan'208";a="313232294" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Nov 2011 10:30:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Nov 2011 10:19:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 16:30:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: AD review of draft-ietf-netconf-system-notifications-06 thread-index: AcydYi+h9LMjmS3SQ9+mMW2kbc35Ng== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:30:50 -0000 I have performed the AD review of draft-ietf-netconf-system-notifications-06. There are no show-stoppers in this document, so I am sending it to IETF Last Call. However, because of the timing conflict with the IETF meeting which will keep busy many IETF contributors I will ask for the Last Call period to be one week longer than usual (three weeks instead of the usual two weeks).=20 Please consider the questions and comments below together with the other Last Call comments. The Technical comments are marked T and the Editorial comments are marked E. T1. In section 2.1:=20 netconf-session-start: Generated when a NETCONF server detects that a NETCONF session has started. A server MAY generate this event for non-NETCONF management sessions. Indicates the identity of the user that started the session. I am not sure that I understand why a server needs to generate a netconf-session-start notification for a non-NETCONF management session. Maybe an example / use case could help.=20 Same question for netconf-session-end: T2. This may be more like a YANG question, but as I encountered it here I will ask it now. In the MIB world we do not encourage the inclusion of capitalized keywords in DESCRIPTION clauses of the MIB objects. Here I see them used frequently. Did the NETCONF / NETMOD community discuss this practice?=20 =20 E1. Page 7:=20 Generated when the NETCONF server detects that the or configuration datastore has changed by a management session. s/has changed/has been changed/ From j.schoenwaelder@jacobs-university.de Mon Nov 7 07:57:21 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350CB21F8B45 for ; Mon, 7 Nov 2011 07:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS6D2X6EzPsU for ; Mon, 7 Nov 2011 07:57:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E611821F8AF4 for ; Mon, 7 Nov 2011 07:57:16 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D01820DE1; Mon, 7 Nov 2011 16:57:16 +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 IX-9_ySx87Z9; Mon, 7 Nov 2011 16:57:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CE1F20DCB; Mon, 7 Nov 2011 16:57:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8E3011B5727B; Mon, 7 Nov 2011 16:56:51 +0100 (CET) Date: Mon, 7 Nov 2011 16:56:51 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20111107155651.GA24205@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:57:21 -0000 On Mon, Nov 07, 2011 at 04:30:31PM +0100, Romascanu, Dan (Dan) wrote: > T2. This may be more like a YANG question, but as I encountered it here > I will ask it now. In the MIB world we do not encourage the inclusion of > capitalized keywords in DESCRIPTION clauses of the MIB objects. Here I > see them used frequently. Did the NETCONF / NETMOD community discuss > this practice? Interesting, I did not know this. Is this covered anywhere in RFC 4181? I guess the only reason for this is to please broken MIB parsers. I hope YANG does not need such rules since we do not have to cater for broken YANG parsers... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon Nov 7 08:10:27 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E221F8C5E for ; Mon, 7 Nov 2011 08:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.84 X-Spam-Level: X-Spam-Status: No, score=-102.84 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAbGHofDUW3T for ; Mon, 7 Nov 2011 08:10:23 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4B21F8C59 for ; Mon, 7 Nov 2011 08:10:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAHsBuE7GmAcF/2dsb2JhbABDmX2PaYEFgXIBAQEBAxIeCj0CDAQCAQgNAQIBBAEBAQoGDAsBBgFFCQgBAQQTCAwOol6bc4hIYwSZcYwd X-IronPort-AV: E=Sophos;i="4.69,470,1315195200"; d="scan'208";a="216670038" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Nov 2011 11:09:53 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Nov 2011 11:09:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 17:09:48 +0100 Message-ID: In-Reply-To: <20111107155651.GA24205@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 thread-index: AcydZe5opl5yfGF/Q5iOrktcx5E4MwAATzRg References: <20111107155651.GA24205@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:10:28 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, November 07, 2011 5:57 PM > To: Romascanu, Dan (Dan) > Cc: netconf@ietf.org > Subject: Re: [Netconf] AD review of draft-ietf-netconf-system- > notifications-06 >=20 > On Mon, Nov 07, 2011 at 04:30:31PM +0100, Romascanu, Dan (Dan) wrote: >=20 > > T2. This may be more like a YANG question, but as I encountered it > here > > I will ask it now. In the MIB world we do not encourage the inclusion > of > > capitalized keywords in DESCRIPTION clauses of the MIB objects. Here > I > > see them used frequently. Did the NETCONF / NETMOD community discuss > > this practice? >=20 > Interesting, I did not know this. Is this covered anywhere in RFC > 4181? I guess the only reason for this is to please broken MIB > parsers. I hope YANG does not need such rules since we do not have to > cater for broken YANG parsers... >=20 [[DR]] Am I mistaken? The reason was not related to broken MIB parsers (sure, YANG tools never broke :-)) but more to avoid including normative text in a clause that is targeting documentation, or so I thought.=20 Dan From mbj@tail-f.com Mon Nov 7 11:44:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5432511E80A3 for ; Mon, 7 Nov 2011 11:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfK3U6jyvpuv for ; Mon, 7 Nov 2011 11:44:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B06CC11E80A0 for ; Mon, 7 Nov 2011 11:44:34 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 50A411200D4C; Mon, 7 Nov 2011 20:44:22 +0100 (CET) Date: Mon, 07 Nov 2011 20:44:22 +0100 (CET) Message-Id: <20111107.204422.152914522.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: <20111107155651.GA24205@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / 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] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:44:35 -0000 "Romascanu, Dan (Dan)" wrote: > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Monday, November 07, 2011 5:57 PM > > To: Romascanu, Dan (Dan) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] AD review of draft-ietf-netconf-system- > > notifications-06 > > > > On Mon, Nov 07, 2011 at 04:30:31PM +0100, Romascanu, Dan (Dan) wrote: > > > > > T2. This may be more like a YANG question, but as I encountered it > > here > > > I will ask it now. In the MIB world we do not encourage the > inclusion > > of > > > capitalized keywords in DESCRIPTION clauses of the MIB objects. Here > > I > > > see them used frequently. Did the NETCONF / NETMOD community discuss > > > this practice? > > > > Interesting, I did not know this. Is this covered anywhere in RFC > > 4181? I guess the only reason for this is to please broken MIB > > parsers. I hope YANG does not need such rules since we do not have to > > cater for broken YANG parsers... > > > > [[DR]] Am I mistaken? The reason was not related to broken MIB parsers > (sure, YANG tools never broke :-)) but more to avoid including normative > text in a clause that is targeting documentation, or so I thought. Isn't the description text allowed to define the normative behavior of the objects? I hope it is ok, because otherwise we would have to write all normative text in the RFC outside of the YANG module (or MIB module), and that means that the standalone module is less useful, and readers must also check the RFC to find the normative text. It seems e.g. MUST is used in some MIBs as well, e.g. INET-ADDRESS-MIB. In libsmi/mibs/ietf: $ grep MUST * | wc -l 1039 /martin From randy_presuhn@mindspring.com Mon Nov 7 12:06:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0E21F847A for ; Mon, 7 Nov 2011 12:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUTpSKnkQ9ao for ; Mon, 7 Nov 2011 12:06:28 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3521F846D for ; Mon, 7 Nov 2011 12:06:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JXUwqquG7fEuf+OKF3jeTmM/AASmfarDSxJsdFkTzz+0w3p3ntbdefdpyCMM+XNR; 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.187.236.11] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RNVSb-0007pg-Ew for netconf@ietf.org; Mon, 07 Nov 2011 15:06:25 -0500 Message-ID: <001001cc9d88$d0fa9d20$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111107155651.GA24205@elstar.local> <20111107.204422.152914522.mbj@tail-f.com> Date: Mon, 7 Nov 2011 12:07:02 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f0f31a800453882e769f0418319657094350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.236.11 Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:06:29 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, November 07, 2011 11:44 AM > Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 ... > Isn't the description text allowed to define the normative behavior of > the objects? I hope it is ok, because otherwise we would have to > write all normative text in the RFC outside of the YANG module (or MIB > module), and that means that the standalone module is less useful, and > readers must also check the RFC to find the normative text. Agreed. To me the MIB module DESCRIPTION clauses seem like the logical place to put normative text describing the behaviour of those management interfaces. > It seems e.g. MUST is used in some MIBs as well, > e.g. INET-ADDRESS-MIB. > > In libsmi/mibs/ietf: > $ grep MUST * | wc -l > 1039 I do not find this surprising. :-) Randy From bertietf@bwijnen.net Mon Nov 7 12:12:26 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8213A21F849C for ; Mon, 7 Nov 2011 12:12:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0KNoj+DSd-m for ; Mon, 7 Nov 2011 12:12:26 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id E2D8F21F844A for ; Mon, 7 Nov 2011 12:12:25 -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 1RNVYM-0001Bk-Os; Mon, 07 Nov 2011 21:12: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 1RNVYM-0001b5-JC; Mon, 07 Nov 2011 21:12:22 +0100 Message-ID: <4EB83BA6.7030308@bwijnen.net> Date: Mon, 07 Nov 2011 21:12:22 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , netconf@ietf.org References: <20111107155651.GA24205@elstar.local> In-Reply-To: <20111107155651.GA24205@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: 86ab03e524994f79ca2c75a176445dd4f978a9235555bf702474a9f1e55e9542 Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:12:26 -0000 inline On 11/7/11 4:56 PM, Juergen Schoenwaelder wrote: > On Mon, Nov 07, 2011 at 04:30:31PM +0100, Romascanu, Dan (Dan) wrote: > >> T2. This may be more like a YANG question, but as I encountered it here >> I will ask it now. In the MIB world we do not encourage the inclusion of >> capitalized keywords in DESCRIPTION clauses of the MIB objects. Here I >> see them used frequently. Did the NETCONF / NETMOD community discuss >> this practice? > > Interesting, I did not know this. Is this covered anywhere in RFC > 4181? I guess the only reason for this is to please broken MIB > parsers. I hope YANG does not need such rules since we do not have to > cater for broken YANG parsers... > I am also not aware of this. What I do know is that we do not want thing in DESCRIPTION clauses that can easily be expressed in MODULE-COMPLIANCE. As far as I know, several MIB modules do use RFC2119 language in DESCRIPTION clauses. I need to dig in my archives if I have to provide examples. Bert > /js > From j.schoenwaelder@jacobs-university.de Mon Nov 7 12:45:48 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74E11E80D6 for ; Mon, 7 Nov 2011 12:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4W3EBFWKO8F for ; Mon, 7 Nov 2011 12:45:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B780211E80D5 for ; Mon, 7 Nov 2011 12:45:47 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B351E20C9E; Mon, 7 Nov 2011 21:45:46 +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 CnKbwvj4tarF; Mon, 7 Nov 2011 21:45:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 729E620DBC; Mon, 7 Nov 2011 21:45:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 73BCD1B577A4; Mon, 7 Nov 2011 21:45:29 +0100 (CET) Date: Mon, 7 Nov 2011 21:45:29 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20111107204529.GB24827@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netconf@ietf.org References: <20111107155651.GA24205@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:45:48 -0000 On Mon, Nov 07, 2011 at 05:09:48PM +0100, Romascanu, Dan (Dan) wrote: > > [[DR]] Am I mistaken? The reason was not related to broken MIB parsers > (sure, YANG tools never broke :-)) but more to avoid including normative > text in a clause that is targeting documentation, or so I thought. > Sorry, I did not equate "capitalized keywords" with RFC 2119 key words (I was thinking about keywords of the language a module is written in, hence my comment on broken MIB parsers). But even with the confusion resolved, I must say that I strongly prefer to find the normative text describing managed objects where the objects are defined. (Of course, the normative text should be restricted to the managed object definition itself and not express normative behaviour of the protocol mechanism being instrumented.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From iesg-secretary@ietf.org Mon Nov 7 15:48:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8B11E80D9; Mon, 7 Nov 2011 15:48:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAGUKv8jrfNr; Mon, 7 Nov 2011 15:48:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868F11E80CB; Mon, 7 Nov 2011 15:48:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111107234843.17154.24211.idtracker@ietfa.amsl.com> Date: Mon, 07 Nov 2011 15:48:43 -0800 Cc: netconf@ietf.org Subject: [Netconf] Last Call: (Network Configuration Protocol (NETCONF) Base Notifications) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 23:48:43 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Network Configuration Protocol (NETCONF) Base Notifications' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netconf-system-notifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netconf-system-notifications/ No IPR declarations have been submitted directly on this I-D. From dromasca@avaya.com Tue Nov 8 02:08:21 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087EB21F8C7E for ; Tue, 8 Nov 2011 02:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.344 X-Spam-Level: X-Spam-Status: No, score=-103.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUURLDwgieUm for ; Tue, 8 Nov 2011 02:08:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B021F8C36 for ; Tue, 8 Nov 2011 02:08:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAMj+uE6HCzI1/2dsb2JhbABDmhaPa4EFgXIBAQEBAxIeCj0OBAIBCA0EBAEBAQoGDAsBBgFFCQgBAQQBEggMDqMnnCuISGMEmXGMHQ X-IronPort-AV: E=Sophos;i="4.69,476,1315195200"; d="scan'208";a="313379934" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Nov 2011 05:08:19 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Nov 2011 04:57:19 -0500 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 Nov 2011 11:08:17 +0100 Message-ID: In-Reply-To: <4EB83BA6.7030308@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 thread-index: AcydiZNdQ2ZetUmcRl+NyEd4xH6SHAAdKoJA References: <20111107155651.GA24205@elstar.local> <4EB83BA6.7030308@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Subject: Re: [Netconf] AD review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 10:08:21 -0000 Fine with me - you can ignore this comment.=20 Dan > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Monday, November 07, 2011 10:12 PM > To: Romascanu, Dan (Dan); netconf@ietf.org > Subject: Re: [Netconf] AD review of draft-ietf-netconf-system- > notifications-06 >=20 > inline >=20 > On 11/7/11 4:56 PM, Juergen Schoenwaelder wrote: > > On Mon, Nov 07, 2011 at 04:30:31PM +0100, Romascanu, Dan (Dan) wrote: > > > >> T2. This may be more like a YANG question, but as I encountered it > here > >> I will ask it now. In the MIB world we do not encourage the > inclusion of > >> capitalized keywords in DESCRIPTION clauses of the MIB objects. Here > I > >> see them used frequently. Did the NETCONF / NETMOD community discuss > >> this practice? > > > > Interesting, I did not know this. Is this covered anywhere in RFC > > 4181? I guess the only reason for this is to please broken MIB > > parsers. I hope YANG does not need such rules since we do not have to > > cater for broken YANG parsers... > > >=20 > I am also not aware of this. > What I do know is that we do not want thing in DESCRIPTION clauses that > can easily be expressed in MODULE-COMPLIANCE. > As far as I know, several MIB modules do use RFC2119 language in > DESCRIPTION clauses. I need to dig in my archives if I have to > provide examples. >=20 > Bert >=20 > > /js > > From mehmet.ersue@nsn.com Tue Nov 8 11:24:39 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2A31F0C6C for ; Tue, 8 Nov 2011 11:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34NePeBwUNVV for ; Tue, 8 Nov 2011 11:24:39 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id AFE621F0C69 for ; Tue, 8 Nov 2011 11:24:36 -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 pA8JOYfF006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Nov 2011 20:24:35 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA8JOYHk017195 for ; Tue, 8 Nov 2011 20:24:34 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 20:24:34 +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 Nov 2011 20:24:33 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402F0B608@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recruiting Note Takers and Jabber Scribes Thread-Index: AcyeSXTxxbyjtXtKQqGhGHAg+QD4NgAAjkMQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 08 Nov 2011 19:24:34.0650 (UTC) FILETIME=[0C3673A0:01CC9E4C] Subject: [Netconf] FW: Recruiting Note Takers and Jabber Scribes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 19:24:39 -0000 Hi All, are there any volunteers? Please let us know privately. We need two note takers and one Jabber scribe for the NETCONF session. Thank you. Mehmet & Bert -----Original Message----- From: ext Ronald Bonica [mailto:rbonica@juniper.net]=20 Sent: Tuesday, November 08, 2011 8:06 PM To: ops-chairs@ietf.org Subject: Recruiting Note Takers and Jabber Scribes Folks, If you want to make the most out of your meeting time, please consider recruiting note takers and Jabber scribes before the meeting.=20 -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From mbj@tail-f.com Tue Nov 15 02:32:56 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C49D11E824E for ; Tue, 15 Nov 2011 02:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX4CogvydJve for ; Tue, 15 Nov 2011 02:32:56 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48411E8241 for ; Tue, 15 Nov 2011 02:32:56 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5116D1200D02 for ; Tue, 15 Nov 2011 11:32:54 +0100 (CET) Date: Tue, 15 Nov 2011 11:32:53 +0100 (CET) Message-Id: <20111115.113253.283039164.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] advertising submodules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 10:32:56 -0000 Hi, I just wanted to clarify what I meant re. advertising submodules. *If* we need to change this, that would be an update to YANG, not to NETCONF. NETCONF has this notion of capabilities, but it doesn't specify exactly what should go in them. YANG defines that each *module* is advertised, with revision, module name, features etc. If we also want to advertise submdoules, the natural place to specify how to do that would be in YANG. So we could say that each submodule is advertised as a separate NETCONF cpaability. No need to change NETCONF to do this. /martin From andy@netconfcentral.org Tue Nov 15 06:04:46 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DF021F8B0B for ; Tue, 15 Nov 2011 06:04:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK9r4lAw4ent for ; Tue, 15 Nov 2011 06:04:45 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id B5FC721F8AF8 for ; Tue, 15 Nov 2011 06:04:45 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAFE4gt4013765 for ; Tue, 15 Nov 2011 09:04:44 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [122.147.240.7] ([122.147.240.7:10659] helo=[172.22.14.161]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7A/15-04871-87172CE4; Tue, 15 Nov 2011 09:04:42 -0500 Message-ID: <4EC27177.7010207@netconfcentral.org> Date: Tue, 15 Nov 2011 06:04:39 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <20111115.113253.283039164.mbj@tail-f.com> In-Reply-To: <20111115.113253.283039164.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] advertising submodules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:04:46 -0000 On 11/15/2011 02:32 AM, Martin Bjorklund wrote: > Hi, > > I just wanted to clarify what I meant re. advertising submodules. > > *If* we need to change this, that would be an update to YANG, not to > NETCONF. NETCONF has this notion of capabilities, but it doesn't > specify exactly what should go in them. > > YANG defines that each *module* is advertised, with revision, module > name, features etc. > > If we also want to advertise submdoules, the natural place to specify > how to do that would be in YANG. So we could say that each submodule > is advertised as a separate NETCONF cpaability. No need to change > NETCONF to do this. > Of course. NETCONF just requires a URI as capability content. A new document called 'YANG Submodule Capability for NETCONF' could be done without touching the RFC 6020. > /martin Andy From lhotka@cesnet.cz Tue Nov 15 06:08:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B4121F8B1C for ; Tue, 15 Nov 2011 06:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW1mompnSm1R for ; Tue, 15 Nov 2011 06:08:00 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id CB41B21F8B16 for ; Tue, 15 Nov 2011 06:07:59 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9B6BF2CDE058; Tue, 15 Nov 2011 15:07:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_02F216A0-222B-414E-BE26-1AD0762A3935"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4EC27177.7010207@netconfcentral.org> Date: Tue, 15 Nov 2011 22:07:49 +0800 Message-Id: References: <20111115.113253.283039164.mbj@tail-f.com> <4EC27177.7010207@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1251.1) Cc: netconf@ietf.org Subject: Re: [Netconf] advertising submodules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:08:00 -0000 --Apple-Mail=_02F216A0-222B-414E-BE26-1AD0762A3935 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 15, 2011, at 10:04 PM, Andy Bierman wrote: > On 11/15/2011 02:32 AM, Martin Bjorklund wrote: >> Hi, >> >> I just wanted to clarify what I meant re. advertising submodules. >> >> *If* we need to change this, that would be an update to YANG, not to >> NETCONF. NETCONF has this notion of capabilities, but it doesn't >> specify exactly what should go in them. >> >> YANG defines that each *module* is advertised, with revision, module >> name, features etc. >> >> If we also want to advertise submdoules, the natural place to specify >> how to do that would be in YANG. So we could say that each submodule >> is advertised as a separate NETCONF cpaability. No need to change >> NETCONF to do this. >> > > Of course. > NETCONF just requires a URI as capability content. > > A new document called 'YANG Submodule Capability for NETCONF' could > be done without touching the RFC 6020. Does it mean this new capability will be optional? Lada > >> /martin > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_02F216A0-222B-414E-BE26-1AD0762A3935 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE1MTQwNzQ5WjAjBgkqhkiG9w0BCQQxFgQUzQFgnyGIh7sD+FkQtiKd3uoO57MwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQA5leNp0YkF5yYUzjBaftTf9CK5 ScdJ2RVONFTMD+WxYzokzoNI/gR3UjtXBMlKEYkQ3exxnapqULdWlfCEGI8pMEeOMNhWK466WUDB O4GEHCg3o0/qIK+qCxEW8DvhPY4rENx+3++o9ZwliUozM235+ju4Wrg7b5HL4hTReFghtaSxVk+/ q+qRkokz3RSKyOPcKztUO6MqQJbJdZ5cKcu7SlCvDQKY/e2fO6+JNBJ3xeMKW/xiU3Fb5R7T4+QI Wk0DoG+0PuuN8YmE7kZMvJ/cped/giTpNrN1bjhPeBkH6HYxVsm1p7pZaT03TKxqQ6G3U+q6f6Gy ZwRibP9NGG5ZAAAAAAAA --Apple-Mail=_02F216A0-222B-414E-BE26-1AD0762A3935-- From mbj@tail-f.com Tue Nov 15 06:11:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CC21F8CA5 for ; Tue, 15 Nov 2011 06:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ifMKbeuEzMa for ; Tue, 15 Nov 2011 06:11:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9351311E80A2 for ; Tue, 15 Nov 2011 06:11:34 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A5A2012008E8; Tue, 15 Nov 2011 15:11:33 +0100 (CET) Date: Tue, 15 Nov 2011 15:11:32 +0100 (CET) Message-Id: <20111115.151132.473180082.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4EC27177.7010207@netconfcentral.org> References: <20111115.113253.283039164.mbj@tail-f.com> <4EC27177.7010207@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] advertising submodules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:11:35 -0000 Andy Bierman wrote: > On 11/15/2011 02:32 AM, Martin Bjorklund wrote: > > Hi, > > > > I just wanted to clarify what I meant re. advertising submodules. > > > > *If* we need to change this, that would be an update to YANG, not to > > NETCONF. NETCONF has this notion of capabilities, but it doesn't > > specify exactly what should go in them. > > > > YANG defines that each *module* is advertised, with revision, module > > name, features etc. > > > > If we also want to advertise submdoules, the natural place to specify > > how to do that would be in YANG. So we could say that each submodule > > is advertised as a separate NETCONF cpaability. No need to change > > NETCONF to do this. > > > > Of course. > NETCONF just requires a URI as capability content. > > A new document called 'YANG Submodule Capability for NETCONF' could > be done without touching the RFC 6020. Right. It could Update 6020. But before we do this, we need to make sure that this is the right solution to the original problem... And we need to switch ML. /martin From mehmet.ersue@nsn.com Wed Nov 16 23:34:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37911E810B for ; Wed, 16 Nov 2011 23:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2AI8mA+GBb5 for ; Wed, 16 Nov 2011 23:34:23 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3293A11E80C8 for ; Wed, 16 Nov 2011 23:34:23 -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 pAH7YCSG024568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 08:34:13 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAH7YCb7014046; Thu, 17 Nov 2011 08:34:12 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 08:33:57 +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, 17 Nov 2011 08:33:53 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640301A2D6@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF Session in IETF #82 Thread-Index: AcykSRjE9afmhsi5SeS9P3LY/nOPgwArRXCg From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 17 Nov 2011 07:33:57.0523 (UTC) FILETIME=[4438EE30:01CCA4FB] Cc: netconf@ietf.org Subject: [Netconf] Summary of the NETCONF Session in IETF #82 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 07:34:24 -0000 Dear Dan,=20 below is a summary and action items from the NETCONF WG session on November 15, 2011 in Taipei, Taiwan:=20 - We had approx. 23 participants in the 1 hour NETCONF session.=20 - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. Status of the documents: NETCONF Access Control Model and NETCONF System Notifications documents are both in IETF LC, which end Nov. 28, 2011. Andy discussed the issues raised by the AD review and will fix them as part of LC comments. Non-chartered items: Update of NETCONF over TLS (5539bis): Juergen Schoenwaelder explained the addons in 5539bis document, which are the different methods for the extraction of username from TLS certificates, and the necessary extensions based on the Chunked Framing Mechanism as well as the requirements from RFC 6241. The document is especially necessary because of the security issue of the EOM character sequence. The participants of the session were in favor to adopt the document as WG item. Carsten Bormann raised the issue of deriving user identity from TLS, if a user has multiple keys. RFC4279 (Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)) should be checked whether it provides a solution. Carsten will post his question on PSK key rollover to the list to start a discussion. NETCONF over Web Sockets: Tomoyuki Iijima explained the changes since last time. The document is based on his implementation experience and proposed to publish as Experimental RFC. The document does not handle usernames as required by RFC 6241 should be extended.=20 There were comments in the room against the Web Sockets as transport as it would be not useful in a huge network with some thousand nodes. Others in the room were in favor of the document as they think a browser-based solution would be helpful for testing and small networks. The document will be further discussed on the maillist. There was a question whether a REST-based solution better than a Web Socket based solution, which needs to be discussed on the maillist. Tomoyuki is going to update his implementation and the document concerning the username handling. There was some discussion on what the WG should do with other transport bindings for NETCONF (i.e. NETCONF over BEEP and NETCONF over SOAP) as they also miss the username handling introduced by RFC 6141. The WG co-chairs will ask the WG whether these transport bindings are in use, whether somebody in NETCONF ML is interested to keep them as transport and in this case whether they volunteer to update the corresponding document appropriately. It has been proposed to make these documents historic, if there is not sufficient interest to keep them. AOB Juergen proposed to introduce sub-modules for NETCONF. Martin stated that the natural place to specify the advertisement of submodules would be in YANG. Juergen will send a summary to the list and then ask peoples opinion on what to do. Bert & Mehmet From andy@netconfcentral.org Sun Nov 20 13:12:17 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B146421F869E for ; Sun, 20 Nov 2011 13:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEXRT5lwKclG for ; Sun, 20 Nov 2011 13:12:17 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id EC00C21F8672 for ; Sun, 20 Nov 2011 13:12:16 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAKLCE5L020559 for ; Sun, 20 Nov 2011 16:12:16 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:54840] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F1/C5-04877-D2D69CE4; Sun, 20 Nov 2011 16:12:14 -0500 Message-ID: <4EC96D2D.3040507@netconfcentral.org> Date: Sun, 20 Nov 2011 13:12:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:12:18 -0000 On 10/24/2011 04:39 PM, Kent Watsen wrote: .... > Concrete example, we originally defined modules like this: > > > module hardware { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > module software { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > module license { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > Guess what? I had way too much time to think about stuff like this on my flight home, and I realized that what you are trying to do fits the current software world view wrt/ namespaces and solves the 'std' namespace update churn problem without the need to keep adding 'include-stmts' to a master container module. You are the centralized naming authority for xml.juniper.net. It should be perfectly valid for you to reuse the same namespace for multiple modules. (Makes the capability list in the hello really important). It assumes you know the difference between a cut-and-paste error and intended namespace sharing. Tools like yuma don't support this yet, but it wouldn't be that hard to support 1:N instead of 1:1 mappings. It means that submodules are seriously redundant and we should get rid of them. They don't work exactly the same as imported modules, just different enough to confuse people. It would require a new version of YANG (IMO) to allow this change. > Thanks, > Kent > Andy From j.schoenwaelder@jacobs-university.de Sun Nov 20 13:22:57 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21CE21F84A7; Sun, 20 Nov 2011 13:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si7eLKxgmP57; Sun, 20 Nov 2011 13:22:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D921F849C; Sun, 20 Nov 2011 13:22:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81A3620C70; Sun, 20 Nov 2011 22:22:55 +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 x3B0dfp3r5z7; Sun, 20 Nov 2011 22:22:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1CCB20C6E; Sun, 20 Nov 2011 22:22:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E64561BBDE4F; Sun, 20 Nov 2011 22:22:36 +0100 (CET) Date: Sun, 20 Nov 2011 22:22:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111120212236.GA37392@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , "netconf@ietf.org" , NETMOD Working Group References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC96D2D.3040507@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [Netconf] [netmod] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:22:57 -0000 On Sun, Nov 20, 2011 at 01:12:13PM -0800, Andy Bierman wrote: > On 10/24/2011 04:39 PM, Kent Watsen wrote: > .... > >Concrete example, we originally defined modules like this: > > > > > > module hardware { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > module software { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > module license { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > > > Guess what? > I had way too much time to think about stuff like this on my flight home, > and I realized that what you are trying to do fits the current software world view > wrt/ namespaces and solves the 'std' namespace update churn problem without > the need to keep adding 'include-stmts' to a master container module. > > You are the centralized naming authority for xml.juniper.net. > It should be perfectly valid for you to reuse the same namespace for multiple modules. > (Makes the capability list in the hello really important). It assumes > you know the difference between a cut-and-paste error and intended namespace sharing. > Tools like yuma don't support this yet, but it wouldn't be that hard > to support 1:N instead of 1:1 mappings. > > It means that submodules are seriously redundant and we should get rid of them. > They don't work exactly the same as imported modules, just different enough > to confuse people. > > It would require a new version of YANG (IMO) to allow this change. So what is the benefit of this compared to a solution in which submodules are announced in the exchange? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Sun Nov 20 13:49:17 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43871F0C4C for ; Sun, 20 Nov 2011 13:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghCZJWmUeuQa for ; Sun, 20 Nov 2011 13:49:17 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56C1F0C34 for ; Sun, 20 Nov 2011 13:49:16 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAKLnENR030913 for ; Sun, 20 Nov 2011 16:49:16 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:54859] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5C/1C-04600-9D579CE4; Sun, 20 Nov 2011 16:49:14 -0500 Message-ID: <4EC975D9.4040006@netconfcentral.org> Date: Sun, 20 Nov 2011 13:49:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" , NETMOD Working Group References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> In-Reply-To: <20111120212236.GA37392@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [netmod] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 21:49:17 -0000 On 11/20/2011 01:22 PM, Juergen Schoenwaelder wrote: > On Sun, Nov 20, 2011 at 01:12:13PM -0800, Andy Bierman wrote: >> On 10/24/2011 04:39 PM, Kent Watsen wrote: >> .... >>> Concrete example, we originally defined modules like this: >>> >>> >>> module hardware { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> module software { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> module license { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> >> Guess what? >> I had way too much time to think about stuff like this on my flight home, >> and I realized that what you are trying to do fits the current software world view >> wrt/ namespaces and solves the 'std' namespace update churn problem without >> the need to keep adding 'include-stmts' to a master container module. >> >> You are the centralized naming authority for xml.juniper.net. >> It should be perfectly valid for you to reuse the same namespace for multiple modules. >> (Makes the capability list in the hello really important). It assumes >> you know the difference between a cut-and-paste error and intended namespace sharing. >> Tools like yuma don't support this yet, but it wouldn't be that hard >> to support 1:N instead of 1:1 mappings. >> >> It means that submodules are seriously redundant and we should get rid of them. >> They don't work exactly the same as imported modules, just different enough >> to confuse people. >> >> It would require a new version of YANG (IMO) to allow this change. > So what is the benefit of this compared to a solution in which > submodules are announced in the exchange? > > 1) simpler for readers/writers * just import, no include * submodules are flat, not nested like modules, which is confusing 2) no need to keep updating a main module with include-stmts 3) no changes to NETCONF needed at all 4) YANG version may not need to be updated if submodules retained and maybe extensions used An online registry of modules for each namespace could be maintained. Either way, the server must send a complete module capability list in the , and it is already outside the scope of the standard how YANG file locations are mapped to the URIs. IMO, it matches how Python and C++ treat namespaces and modules. They have no need or notion of submodules. > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Nov 21 02:33:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCBF21F8541 for ; Mon, 21 Nov 2011 02:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwS2QQ5W6Ln3 for ; Mon, 21 Nov 2011 02:32:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 77DC921F853E for ; Mon, 21 Nov 2011 02:32:59 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB53D20C9C for ; Mon, 21 Nov 2011 11:32:58 +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 XYJ1_61HMNaM; Mon, 21 Nov 2011 11:32:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2F4F20C98; Mon, 21 Nov 2011 11:32:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 737C31BBE65D; Mon, 21 Nov 2011 11:32:40 +0100 (CET) Date: Mon, 21 Nov 2011 11:32:39 +0100 From: Juergen Schoenwaelder To: "netconf@ietf.org" Message-ID: <20111121103239.GC38525@elstar.local> Mail-Followup-To: "netconf@ietf.org" References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC975D9.4040006@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] [netmod] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 10:33:00 -0000 Hi, I think we should have the discussion on the NETMOD mailing list only since this is mainly a YANG issued and not so much a NETCONF issue. So please help us staying focussed by removing NETCONF from any further CCs on this topic. /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 Mon Nov 21 06:10:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29C821F8B40 for ; Mon, 21 Nov 2011 06:10:29 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8V0h-NFjYni for ; Mon, 21 Nov 2011 06:10:29 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE9221F8B3B for ; Mon, 21 Nov 2011 06:10:27 -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 1RSUZi-0007cc-GV; Mon, 21 Nov 2011 15:10:24 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest148.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RSUZi-0004VY-2u; Mon, 21 Nov 2011 15:10:22 +0100 Message-ID: <4ECA5BCD.4040106@bwijnen.net> Date: Mon, 21 Nov 2011 15:10:21 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netconf References: <4ECA2643.3060102@ripe.net> In-Reply-To: <4ECA2643.3060102@ripe.net> X-Forwarded-Message-Id: <4ECA2643.3060102@ripe.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: 86ab03e524994f79ca2c75a176445dd43dcccbf4370250f75d4e40e06834d8c4 Subject: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:10:51 -0000 Response requested from all WG participants by December 15th 2011. During our meeting at IETF82, the question was raised if we should consider to obsolete (and make HISTORIC) 2 of the NETCONF transport protocols: - RFC4743 - Netconf over SOAP - RFC4744 - Netconf over BEEP It was noted, that they are currently at PS (Proposed Standard), but that they have a normative reference to the obsoleted Netconf Protocol (RFC4741). They cannot just depend on the new RFC6241 without being updated to also support the :base:1.1 capability, specifically: o Introduced a NETCONF username and a requirement for transport protocols to explain how a username is derived. One option would be to do a revision of those 2 RFCs (similar to the revision of RFC6242 (which obsoleted RFC4742) and rfc5539-bis work. However, it seems that as a WG, we should ONLY consider that option IF: 1 - There are multiple implementations 2 - There is real production deployment 3 - There are multiple people in the WG who want to work on such a revision. 4 - The existing implementations (if any) are also willing to implement such a revision Without that, it seems that OBSOLETING is the best path forward. We (WG chairs) propose that the default path forward will be to obsolete RFC4743 and RFC4744. Anyone opposing that, please speak up asap but do so BEFORE December 15. And, if you do object, then please include answers to the 4 IFs above. Anyone in support of "obsoleting RFC4743 and RFC4744", please let us know by December 15 as well. It is good to also know that we have indeed WG consensus on this. The editors/authors of the documents have been (bbc) copied. Bert and Mehmet. From phil@juniper.net Mon Nov 21 08:30:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88621F8C10 for ; Mon, 21 Nov 2011 08:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmmPIwhdIkHn for ; Mon, 21 Nov 2011 08:30:20 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id CB02821F8BD3 for ; Mon, 21 Nov 2011 08:30:17 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTsp8ktXl4OQ/9f5SHzNu/nHRLh40Ns2K@postini.com; Mon, 21 Nov 2011 08:30:19 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.3.213.0; Mon, 21 Nov 2011 08:28: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 pALGSbh39999; Mon, 21 Nov 2011 08:28:37 -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 pALFxthw007924; Mon, 21 Nov 2011 15:59:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111211559.pALFxthw007924@idle.juniper.net> To: "Bert Wijnen (IETF)" In-Reply-To: <4ECA5BCD.4040106@bwijnen.net> Date: Mon, 21 Nov 2011 10:59:55 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 16:30:20 -0000 "Bert Wijnen (IETF)" writes: >1 - There are multiple implementations >2 - There is real production deployment >3 - There are multiple people in the WG who want to work > on such a revision. >4 - The existing implementations (if any) are also willing > to implement such a revision We have an implementation of NETCONF over BEEP in JUNOS that is used in real deployments. I'm mostly on hiatus from IETF work due to "day job" commitments and travel restrictions, so that's two out of four for me. Thanks, Phil From mbadra@gmail.com Wed Nov 23 03:13:40 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720921F8BDE for ; Wed, 23 Nov 2011 03:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuUstYNuzNUT for ; Wed, 23 Nov 2011 03:13:40 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4AA21F8B25 for ; Wed, 23 Nov 2011 03:13:39 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1367133vcb.31 for ; Wed, 23 Nov 2011 03:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=I1bHxNzniOyEU1clH1sTGxO8zHDkEV202WjAc6iGCNE=; b=Nxps65s2eHjf+nDOQD7v7teCxFJyV2kJp8W7agllRS8v4JIXmodBoT9vXDUVHkpbp4 MKntLJ+id0zqmc9e/2GTj7qjEmiEgZV31dHKHACOSxzwh/AuJPwHKBn9CDaDnzUDZzrh KFeNIviRSfaynGHlRF78pNo+EHfC2ByNaU4c8= MIME-Version: 1.0 Received: by 10.52.72.227 with SMTP id g3mr25104678vdv.10.1322046818958; Wed, 23 Nov 2011 03:13:38 -0800 (PST) Received: by 10.220.157.5 with HTTP; Wed, 23 Nov 2011 03:13:38 -0800 (PST) Date: Wed, 23 Nov 2011 15:13:38 +0400 Message-ID: From: Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=bcaec5016525053ba704b26503b8 Subject: [Netconf] PSK Identity Types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 11:13:40 -0000 --bcaec5016525053ba704b26503b8 Content-Type: text/plain; charset=ISO-8859-1 Dear all, draft-badra-netconf-rfc5539bis-00 includes support for certificate and pre-shared key (PSK)-based authentication. RFC4279 listed three "PSK Identity" types: DNS Names, X509 Distinguished Names and IP Addresses. PSK identity is used as the NETCONF username. Please don't hesitate to propose more identity types so we include them in the draft Best regards, Badra --bcaec5016525053ba704b26503b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

draft-badra-netconf-rfc5539bi= s-00=A0includes support for=A0certificate and pre-shared key (PSK)-based au= thentication.

RFC4279 listed three "PSK Ident= ity" types: DNS Names, X509 Distinguished Names and IP Addresses.

PSK identity is used as the NETCONF username.=A0Please don't h= esitate to propose more identity types so we include them in the draft

Best regards,
Badra
--bcaec5016525053ba704b26503b8-- From j.schoenwaelder@jacobs-university.de Wed Nov 23 03:56:42 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2521F8BE8 for ; Wed, 23 Nov 2011 03:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6xK8oqGMTkU for ; Wed, 23 Nov 2011 03:56:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1630621F8BE7 for ; Wed, 23 Nov 2011 03:56:39 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 692F720CD6; Wed, 23 Nov 2011 12:56:38 +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 8e5MmB1BDAuf; Wed, 23 Nov 2011 12:56:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B24320CBE; Wed, 23 Nov 2011 12:56:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E4E01BDB2A0; Wed, 23 Nov 2011 12:56:20 +0100 (CET) Date: Wed, 23 Nov 2011 12:56:19 +0100 From: Juergen Schoenwaelder To: Badra Message-ID: <20111123115619.GB98340@elstar.local> Mail-Followup-To: Badra , netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] PSK Identity Types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 23 Nov 2011 11:56:42 -0000 On Wed, Nov 23, 2011 at 03:13:38PM +0400, Badra wrote: > Dear all, > > draft-badra-netconf-rfc5539bis-00 includes support for certificate and > pre-shared key (PSK)-based authentication. > > RFC4279 listed three "PSK Identity" types: DNS Names, X509 Distinguished > Names and IP Addresses. > > PSK identity is used as the NETCONF username. Please don't hesitate to > propose more identity types so we include them in the draft I and Badra seem to have different interpretations of this text (quoting from RFC 4279): 5.1. PSK Identity Encoding The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance, o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.2.1"), not as 32-bit integers in network byte order. o Domain names are sent in their usual text form [DNS] (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol format. o X.500 Distinguished Names are sent in their string representation [LDAPDN], not as BER-encoded ASN.1. My reading of this text is that the PSK identity is a UTF-8 character string. Period. In case your identity is an IPv4 address or a domain name or an X.500 DN (that is stuff that is natively not a UTF-8 character string), the bullets say how to render things in UTF-8. I do not see a requirement in this text to specify identity types and specific encoding rules. In other words, if I call my PSK identity "badra", the resulting string is simply the five UTF-8 character sequence "badra". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Wed Nov 23 04:24:52 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441421F8C50 for ; Wed, 23 Nov 2011 04:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxTmEj5zMriZ for ; Wed, 23 Nov 2011 04:24:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F02321F8C4A for ; Wed, 23 Nov 2011 04:24:51 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1447390vcb.31 for ; Wed, 23 Nov 2011 04:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dsuBmyi9JmEsAszPAiexxXfbUobYYC97bpSnvxS7rs4=; b=d9DMMblQP6LX62rqJjWJLJU5XIktuAFQlQ2hhYP7FULtHUB60Y3lYtFR2DpqpD7te5 heHesK74RjLRSO6+POu9ayH5+qKsnx440tUyBTaMxhvyIoe2YJGDaGS7Z+RjDLOHg2n7 5DdYOBjI2Jb0z7g1k9ABJCRyYRE8L8fr/GDbk= MIME-Version: 1.0 Received: by 10.52.72.227 with SMTP id g3mr25359552vdv.10.1322051089362; Wed, 23 Nov 2011 04:24:49 -0800 (PST) Received: by 10.220.157.5 with HTTP; Wed, 23 Nov 2011 04:24:49 -0800 (PST) In-Reply-To: <20111123115619.GB98340@elstar.local> References: <20111123115619.GB98340@elstar.local> Date: Wed, 23 Nov 2011 13:24:49 +0100 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , netconf@ietf.org Content-Type: multipart/alternative; boundary=bcaec50165258e6e1304b2660145 Subject: Re: [Netconf] PSK Identity Types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 12:24:52 -0000 --bcaec50165258e6e1304b2660145 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 23, 2011 at 12:56 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Nov 23, 2011 at 03:13:38PM +0400, Badra wrote: > > Dear all, > > > > draft-badra-netconf-rfc5539bis-00 includes support for certificate and > > pre-shared key (PSK)-based authentication. > > > > RFC4279 listed three "PSK Identity" types: DNS Names, X509 Distinguished > > Names and IP Addresses. > > > > PSK identity is used as the NETCONF username. Please don't hesitate to > > propose more identity types so we include them in the draft > > I and Badra seem to have different interpretations of this text > (quoting from RFC 4279): > > 5.1. PSK Identity Encoding > > The PSK identity MUST be first converted to a character string, and > then encoded to octets using UTF-8 [UTF8]. For instance, > > o IPv4 addresses are sent as dotted-decimal strings (e.g., > "192.0.2.1"), not as 32-bit integers in network byte order. > > o Domain names are sent in their usual text form [DNS] (e.g., > "www.example.com" or "embedded\.dot.example.net"), not in DNS > protocol format. > > o X.500 Distinguished Names are sent in their string representation > [LDAPDN], not as BER-encoded ASN.1. > > My reading of this text is that the PSK identity is a UTF-8 character > string. Period. > > In case your identity is an IPv4 address or a domain name or an X.500 > DN (that is stuff that is natively not a UTF-8 character string), the > bullets say how to render things in UTF-8. I do not see a requirement > in this text to specify identity types and specific encoding rules. In > other words, if I call my PSK identity "badra", the resulting string > is simply the five UTF-8 character sequence "badra". > > > I agree with your interpretation; RFC4279 doesn't mandate the use of any particular type of identity. I wanted in my previous message to know if we need to add more examples on how to convert, to UTF-8, some different PSK Identities not being listed in RFC4279. If this is not required, so the current text is more than enough. Best regards, Badra --bcaec50165258e6e1304b2660145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2011 a= t 12:56 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On = Wed, Nov 23, 2011 at 03:13:38PM +0400, Badra wrote:
> Dear all,
>
> draft-badra-netconf-rfc5539bis-00 includes support for certificate and=
> pre-shared key (PSK)-based authentication.
>
> RFC4279 listed three "PSK Identity" types: DNS Names, X509 D= istinguished
> Names and IP Addresses.
>
> PSK identity is used as the NETCONF username. Please don't hesitat= e to
> propose more identity types so we include them in the draft

I and Badra seem to have different interpretations of this text=
(quoting from RFC 4279):

=A05.1. =A0PSK Identity Encoding

=A0 =A0 The PSK identity MUST be first converted to a character string, an= d
=A0 =A0 then encoded to octets using UTF-8 [UTF8]. =A0For instance,

=A0 =A0 o =A0IPv4 addresses are sent as dotted-decimal strings (e.g.,
=A0 =A0 =A0 =A0"192.0.2.1"), not as 32-bit integers in network b= yte order.

=A0 =A0 o =A0Domain names are sent in their usual text form [DNS] (e.g., =A0 =A0 =A0 =A0"= www.example.com" or "embedded\.dot.example.net"), not in DNS
=A0 =A0 =A0 =A0protocol format.

=A0 =A0 o =A0X.500 Distinguished Names are sent in their string representa= tion
=A0 =A0 =A0 =A0[LDAPDN], not as BER-encoded ASN.1.

My reading of this text is that the PSK identity is a UTF-8 character
string. Period.

In case your identity is an IPv4 address or a domain name or an X.500
DN (that is stuff that is natively not a UTF-8 character string), the
bullets say how to render things in UTF-8. =A0I do not see a requirement in this text to specify identity types and specific encoding rules. In
other words, if I call my PSK identity "badra", the resulting str= ing
is simply the five UTF-8 character sequence "badra".




I agree with your interpretation;= RFC4279=A0doesn't=A0mandate the use of any particular type of identity= . I wanted in my previous message to know if we need to add more examples o= n how to convert, to UTF-8, some different=A0PSK Identities not being liste= d in RFC4279. If this is not required, so the current text is more than eno= ugh.

Best regards,
Badra
--bcaec50165258e6e1304b2660145-- From atarashi@alaxala.net Wed Nov 23 16:37:59 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8877D11E80B4 for ; Wed, 23 Nov 2011 16:37:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUkgBLS22BuP for ; Wed, 23 Nov 2011 16:37:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1F3C11E80B3 for ; Wed, 23 Nov 2011 16:37:58 -0800 (PST) Received: by iaeo4 with SMTP id o4so2680156iae.31 for ; Wed, 23 Nov 2011 16:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alaxala.net; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6iFP06yto3MYOL1XTY+cqsGyqrCCJVL1lz+I5+ge1RM=; b=kxcni7L4a1mIvN6rWGac5l9+jYK9eSsFca6c3pYE8ATbqY32IC7pit70hSuOtmmDDA tm+HnzUTN2dzEXkm5l50IRTNXZdedaenRNP4ws7rwqacA3D4GvmTkfemIaAJsCVthLkM 5Jlwl2t/Ogqyh8vRIiD5KadFAAvWubUI3lAFo= Received: by 10.231.27.203 with SMTP id j11mr7009790ibc.10.1322095078544; Wed, 23 Nov 2011 16:37:58 -0800 (PST) Received: from zamboni.intra.alaxala.net ([2001:200:165:1:f2b4:79ff:fe20:77ba]) by mx.google.com with ESMTPS id n30sm79708231ibl.4.2011.11.23.16.37.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 16:37:57 -0800 (PST) Message-ID: <4ECD91EE.2070602@alaxala.net> Date: Thu, 24 Nov 2011 09:38:06 +0900 From: Yoshifumi Atarashi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netconf@ietf.org References: <201111211559.pALFxthw007924@idle.juniper.net> In-Reply-To: <201111211559.pALFxthw007924@idle.juniper.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 00:37:59 -0000 Hello, Alaxala have an implementation of NETCONF over SOAP. It's supported on our products. And I know HITACHI, NEC, Allied products use NETCONF over SOAP. Yoshifumi Atarashi (11/11/22 0:59), Phil Shafer wrote: > "Bert Wijnen (IETF)" writes: >> 1 - There are multiple implementations >> 2 - There is real production deployment >> 3 - There are multiple people in the WG who want to work >> on such a revision. >> 4 - The existing implementations (if any) are also willing >> to implement such a revision > We have an implementation of NETCONF over BEEP in JUNOS that is > used in real deployments. I'm mostly on hiatus from IETF work due > to "day job" commitments and travel restrictions, so that's two out > of four for me. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Wed Nov 23 23:43:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9088A21F8500 for ; Wed, 23 Nov 2011 23:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt-U8+IPODo0 for ; Wed, 23 Nov 2011 23:43:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B563221F84D4 for ; Wed, 23 Nov 2011 23:43:04 -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 pAO7h160023139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Nov 2011 08:43:01 +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 pAO7guSC027111; Thu, 24 Nov 2011 08:43:01 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 08:43:00 +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, 24 Nov 2011 08:42:59 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403096118@DEMUEXC006.nsn-intra.net> In-Reply-To: <4ECD91EE.2070602@alaxala.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) Thread-Index: AcyqQVVWIJYGBYAAS3SUXcnxFu/oGQAOvyNg References: <201111211559.pALFxthw007924@idle.juniper.net> <4ECD91EE.2070602@alaxala.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Yoshifumi Atarashi" , X-OriginalArrivalTime: 24 Nov 2011 07:43:00.0877 (UTC) FILETIME=[B0FA6BD0:01CCAA7C] Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 07:43:05 -0000 > 3 - There are multiple people in the WG who want to work > on such a revision. > 4 - The existing implementations (if any) are also willing > to implement such a revision This is fine. However, still the questions 3 and 4 need to be=20 answered to update RFC 4743 fitting the NETCONF RFC 6241. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Yoshifumi Atarashi > Sent: Thursday, November 24, 2011 1:38 AM > To: netconf@ietf.org > Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) >=20 > Hello, >=20 > Alaxala have an implementation of NETCONF over SOAP. > It's supported on our products. > And I know HITACHI, NEC, Allied products use NETCONF over SOAP. >=20 > Yoshifumi Atarashi >=20 >=20 > (11/11/22 0:59), Phil Shafer wrote: > > "Bert Wijnen (IETF)" writes: > >> 1 - There are multiple implementations > >> 2 - There is real production deployment > >> 3 - There are multiple people in the WG who want to work > >> on such a revision. > >> 4 - The existing implementations (if any) are also willing > >> to implement such a revision > > We have an implementation of NETCONF over BEEP in JUNOS that is > > used in real deployments. I'm mostly on hiatus from IETF work due > > to "day job" commitments and travel restrictions, so that's two out > > of four for me. > > > > Thanks, > > Phil > > _______________________________________________ > > 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 mehmet.ersue@nsn.com Mon Nov 28 06:31:12 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C629321F8C4C for ; Mon, 28 Nov 2011 06:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzW4k+6rmWYH for ; Mon, 28 Nov 2011 06:31:12 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26521F88A0 for ; Mon, 28 Nov 2011 06:31:11 -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 pASEVAaA009718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Nov 2011 15:31:10 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pASEV7i8022885 for ; Mon, 28 Nov 2011 15:31:10 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Nov 2011 15:30:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2011 15:30:49 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403114C4C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 82 NETCONF Session Minutes Thread-Index: Acyt2lLtlkMG7ND1StumRtctl1iPSA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 28 Nov 2011 14:30:50.0651 (UTC) FILETIME=[53C09EB0:01CCADDA] Subject: [Netconf] Draft IETF 82 NETCONF Session Minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 14:31:12 -0000 Dear NETCONF WG, please find below the draft minutes of the NETCONF session in IETF 82. Please send us your comments by Dec. 12, 2011. http://www.ietf.org/proceedings/82/minutes/netconf.txt=20 Many thanks to the minute taker Lada Lhotka and Jabber=20 scribe Russ Mundy. Mehmet & Bert From mbadra@gmail.com Mon Nov 28 07:40:58 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBFE21F8BB2 for ; Mon, 28 Nov 2011 07:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvxg46MTtyb3 for ; Mon, 28 Nov 2011 07:40:57 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF421F8A6C for ; Mon, 28 Nov 2011 07:40:57 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so5461999vcb.31 for ; Mon, 28 Nov 2011 07:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sFcbs9WRtcO/M8DNnPbSm0/U6Db4DePH549wzGhVJAU=; b=Sa/Mlj55Ejt40p33zTIoEKFt6Yk5modKLFHwTZnhWHtvTJtWsHzE+QnH5IfmIz0/oX Jbcd32rs+qEGRGIw+w5fiNkEuUENzyrBUi9jvlRarLte0zcEkq39rDqPJDn/PbU6ytYH oYgyYdzKeKMwoNNfWzN2X6rep0ykCHzQWUzRs= MIME-Version: 1.0 Received: by 10.220.176.12 with SMTP id bc12mr4887463vcb.142.1322494855127; Mon, 28 Nov 2011 07:40:55 -0800 (PST) Received: by 10.220.191.13 with HTTP; Mon, 28 Nov 2011 07:40:54 -0800 (PST) In-Reply-To: References: <4ECCA4F0.7010504@bwijnen.net> Date: Mon, 28 Nov 2011 16:40:54 +0100 Message-ID: From: Badra To: Carsten Bormann Content-Type: multipart/alternative; boundary=90e6ba53aeb60ea54004b2cd5416 Cc: netconf@ietf.org Subject: [Netconf] PSK comment during NETCONF session at IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:40:58 -0000 --90e6ba53aeb60ea54004b2cd5416 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2011 at 5:09 PM, Carsten Bormann wrote: > On Nov 23, 2011, at 08:46, Bert Wijnen (IETF) wrote: > > > I will let Carsten explain what his exact question was/is. > > My understanding of it was that he wonders what happens > > during key roll-over. The way I understood it, one can > > have 2 keys (ofr a period of time) during roll-over (i.e. > > during the time that you are switching from one PSK to a new PSK). > > So how is that being dealth with? > > Exactly. Below please find the question as I posed it to two of the > authors of RFC4279 (I don't have a reply yet), with some additional > comments: > > > I'm neither a netconf nor a TLS expert, but I'm trying to do the same > > thing in CoRE that draft-badra-netconf-rfc5539bis-00.txt tries to do > > in section 3.2.2: use the PSK identity mechanism defined in RFC4279 > > section 2 as a way to establish a user name that is authenticated by > > the TLS (/DTLS) session. > > > > RFC4279: > > Both clients and servers may have pre-shared keys with several > > different parties. The client indicates which key to use by > > including a "PSK identity"... > > > > I would expect many organizations to have a policy that limits the > > lifetime of a PSK. (I'm not talking about rekeying of the TEK here -- > > this is taken care of by starting a new TLS connection.) To do key > > rollover, at any time an old and a new key may be active > > simultaneously for one user. I'd expect these to have different PSK > > key identities. So how can they map to the same username? > > > > 1) we can define an algorithmic mapping from the PSK identity to a > > user name (by removing some information, which then effectively > > becomes the key generation ID). > > e.g., the UTF-8 PSK identity string would be something like cabo@tzi.org/= 1, > cabo@tzi.org/2, and the mapping to the username would get rid of the part > starting with the slash. > > RFC4279 doesn't specify that; I believe it is up to the application layer to manage that. Your approach can help. I can insert it to the document if people agree. > 2) We can store the username with the key and use the PSK identity as > > just that, a key identity; the username is then retrieved with the key. > > e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, and > there would be a table like > > Jpzb3YWS cabo@tzi.org (key=85) > K3nV6qh0 cabo@tzi.org (key=85) > A4AINPdk bertietf@bwijnen.net (key=85) > n5Dft5CQ mehmet.ersue@nsn.com (key=85) > 2qQbLrhI mehmet.ersue@nsn.com (key=85) > > (probably with columns added that maintain the key validity time ranges). > > > 3) We can expect the TLS implementation to maintain multiple keys > > under one identity and select the one that happens to authenticate. > > (which is a bit ugly to implement and would AFAIK be a new requirement on > a TLS library that no existing one meets.) > > I'd like to know what is the right way to do this. I'll then send a > > message to the netconf and core WGs providing some explanation. > > > > Gruesse, Carsten > > In order to get this discussion going, please feel free to forward this > message to the netconf list (I'm subscribing now, too). > > The WG is cced to this message, and are invited to comment on that issue Best regards Badra --90e6ba53aeb60ea54004b2cd5416 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2011 at 5:0= 9 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Nov 23, 2011, at 08:46, Bert Wijnen (IETF) wrote:

> I will let Carsten explain what his exact question was/is.
> My understanding of it was that he wonders what happens
> during key roll-over. The way I understood it, one can
> have 2 keys (ofr a period of time) during roll-over (i.e.
> during the time that you are switching from one PSK to a new PSK).
> So how is that being dealth with?

Exactly. =A0Below please find the question as I posed it to two of th= e authors of RFC4279 (I don't have a reply yet), with some additional c= omments:

> I'm neither a netconf nor a TLS expert, but I'm trying to do t= he same
> thing in CoRE that draft-badra-netconf-rfc5539bis-00.txt tries to do > in section 3.2.2: use the PSK identity mechanism defined in RFC4279 > section 2 as a way to establish a user name that is authenticated by > the TLS (/DTLS) session.
>
> RFC4279:
> =A0 Both clients and servers may have pre-shared keys with several
> =A0 different parties. =A0The client indicates which key to use by
> =A0 including a "PSK identity"...
>
> I would expect many organizations to have a policy that limits the
> lifetime of a PSK. =A0(I'm not talking about rekeying of the TEK h= ere --
> this is taken care of by starting a new TLS connection.) =A0To do key<= br> > rollover, at any time an old and a new key may be active
> simultaneously for one user. =A0I'd expect these to have different= PSK
> key identities. =A0So how can they map to the same username?
>
> 1) we can define an algorithmic mapping from the PSK identity to a
> user name (by removing some information, which then effectively
> becomes the key generation ID).

e.g., the UTF-8 PSK identity string would be something like cabo@tzi.org/1, cabo@tzi.org/2, and the mapping to th= e username would get rid of the part starting with the slash.



RFC4279 doesn't spe= cify that; I believe it is up to the application layer to manage that.

Your approach can help. I can insert it to the documen= t if people agree.



cabo@tzi.org =A0 =A0 =A0 =A0 = =A0 =A0 (key=85)
K3nV6qh0 cabo@tzi.org =A0 =A0 =A0 =A0 = =A0 =A0 (key=85)
A4AINPdk bertietf@bwijnen.net = =A0 =A0 (key=85)
n5Dft5CQ mehmet.ersue@nsn.com = =A0 =A0 (key=85)
2qQbLrhI mehmet.ersue@nsn.com = =A0 =A0 (key=85)

(probably with columns added that maintain the key validity time ranges).
> 3) We can expect the TLS implementation to maintain multiple keys
> under one identity and select the one that happens to authenticate.
(which is a bit ugly to implement and would AFAIK be a new requirement on a= TLS library that no existing one meets.)
=A0
> I'd like to know what is the right way to do this. =A0I'll the= n send a
> message to the netconf and core WGs providing some explanation.
>
> Gruesse, Carsten

In order to get this discussion going, please feel free to forward this mes= sage to the netconf list (I'm subscribing now, too).


The WG is cced to this message, and are in= vited to comment on that issue

Best regards
<= div>Badra=A0

--90e6ba53aeb60ea54004b2cd5416-- From j.schoenwaelder@jacobs-university.de Mon Nov 28 07:59:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5CE21F8B53 for ; Mon, 28 Nov 2011 07:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j6mB2lzyCh6 for ; Mon, 28 Nov 2011 07:59:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7721F8B45 for ; Mon, 28 Nov 2011 07:59:36 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B652120CC2; Mon, 28 Nov 2011 16:59:35 +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 xHSNxK9GK1G3; Mon, 28 Nov 2011 16:59:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 372D320CBC; Mon, 28 Nov 2011 16:59:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 615591BE7160; Mon, 28 Nov 2011 16:59:17 +0100 (CET) Date: Mon, 28 Nov 2011 16:59:16 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20111128155916.GE22835@elstar.local> Mail-Followup-To: Carsten Bormann , netconf@ietf.org References: <4ECCA4F0.7010504@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] PSK comment during NETCONF session at IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:59:37 -0000 On Wed, Nov 23, 2011 at 05:09:24PM +0100, Carsten Bormann wrote: > > I would expect many organizations to have a policy that limits the > > lifetime of a PSK. (I'm not talking about rekeying of the TEK here -- > > this is taken care of by starting a new TLS connection.) To do key > > rollover, at any time an old and a new key may be active > > simultaneously for one user. I'd expect these to have different PSK > > key identities. So how can they map to the same username? > > > > 1) we can define an algorithmic mapping from the PSK identity to a > > user name (by removing some information, which then effectively > > becomes the key generation ID). > > e.g., the UTF-8 PSK identity string would be something like cabo@tzi.org/1, cabo@tzi.org/2, and the mapping to the username would get rid of the part starting with the slash. > > > 2) We can store the username with the key and use the PSK identity as > > just that, a key identity; the username is then retrieved with the key. > > e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, and there would be a table like > > Jpzb3YWS cabo@tzi.org (key…) > K3nV6qh0 cabo@tzi.org (key…) > A4AINPdk bertietf@bwijnen.net (key…) > n5Dft5CQ mehmet.ersue@nsn.com (key…) > 2qQbLrhI mehmet.ersue@nsn.com (key…) > > (probably with columns added that maintain the key validity time ranges). > > > 3) We can expect the TLS implementation to maintain multiple keys > > under one identity and select the one that happens to authenticate. > > (which is a bit ugly to implement and would AFAIK be a new requirement on a TLS library that no existing one meets.) > > > I'd like to know what is the right way to do this. I'll then send a > > message to the netconf and core WGs providing some explanation. > > > > Gruesse, Carsten > > In order to get this discussion going, please feel free to forward this message to the netconf list (I'm subscribing now, too). While we could invent option 1), things get bad if other WGs choose to invent a different notation as there does not seem to be a common notation for this (yet). Option 2) seems to be a safe bet since it pushed the problem to controllable configuration (and as a side effect we would have a NETCONF way of managing PSK keys). Option 3 seems to be out of scope since PSK does not allow "key probing" (and I assume security folks might not like this either). /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 Nov 29 03:39:18 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD1D21F85B8 for ; Tue, 29 Nov 2011 03:39:18 -0800 (PST) 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_16=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv-54ktXWpqF for ; Tue, 29 Nov 2011 03:39:17 -0800 (PST) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 004EB21F85F2 for ; Tue, 29 Nov 2011 03:39:16 -0800 (PST) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr07.btconnect.com with SMTP id FMD87298; Tue, 29 Nov 2011 11:38:58 +0000 (GMT) Message-ID: <035a01ccae83$5c9c55c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Carsten Bormann" References: <4ECCA4F0.7010504@bwijnen.net> <20111128155916.GE22835@elstar.local> Date: Tue, 29 Nov 2011 11:40:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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.0A0B0303.4ED4C451.00A7, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.29.104816:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, __PHISH_SPEAR_ACCOUNT_1, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4ED4C452.017C,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] PSK comment during NETCONF session at IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 11:39:18 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "Carsten Bormann" Cc: Sent: Monday, November 28, 2011 4:59 PM > On Wed, Nov 23, 2011 at 05:09:24PM +0100, Carsten Bormann wrote: > > > > I would expect many organizations to have a policy that limits the > > > lifetime of a PSK. (I'm not talking about rekeying of the TEK here -- > > > this is taken care of by starting a new TLS connection.) To do key > > > rollover, at any time an old and a new key may be active > > > simultaneously for one user. I'd expect these to have different PSK > > > key identities. So how can they map to the same username? > > > > > > 1) we can define an algorithmic mapping from the PSK identity to a > > > user name (by removing some information, which then effectively > > > becomes the key generation ID). > > > > e.g., the UTF-8 PSK identity string would be something like cabo@tzi.org/1, cabo@tzi.org/2, and the mapping to the username would get rid of the part starting with the slash. > > > > > 2) We can store the username with the key and use the PSK identity as > > > just that, a key identity; the username is then retrieved with the key. > > > > e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, and there would be a table like > > > > Jpzb3YWS cabo@tzi.org (key…) > > K3nV6qh0 cabo@tzi.org (key…) > > A4AINPdk bertietf@bwijnen.net (key…) > > n5Dft5CQ mehmet.ersue@nsn.com (key…) > > 2qQbLrhI mehmet.ersue@nsn.com (key…) > > > > (probably with columns added that maintain the key validity time ranges). > > > > > 3) We can expect the TLS implementation to maintain multiple keys > > > under one identity and select the one that happens to authenticate. > > > > (which is a bit ugly to implement and would AFAIK be a new requirement on a TLS library that no existing one meets.) > > > > > I'd like to know what is the right way to do this. I'll then send a > > > message to the netconf and core WGs providing some explanation. > > > > > > Gruesse, Carsten > > > > In order to get this discussion going, please feel free to forward this message to the netconf list (I'm subscribing now, too). > > While we could invent option 1), things get bad if other WGs choose to > invent a different notation as there does not seem to be a common > notation for this (yet). I think that the underlying problem is a lack of interest in PSK and allied technologies. There was an I-D brought to the TLS recently in this area which provoked the response, 'why do you expect this one to succeed when the previous three I-Ds have not?' Logically, PSK makes a lot of sense but as here, more work is needed. But it just does not seem to get used, hence, IMO, the unresolved details. Tom Petch > > Option 2) seems to be a safe bet since it pushed the problem to > controllable configuration (and as a side effect we would have a > NETCONF way of managing PSK keys). > > Option 3 seems to be out of scope since PSK does not allow "key > probing" (and I assume security folks might not like this either). > > /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 cabo@tzi.org Tue Nov 29 07:09:31 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C082221F8B5D for ; Tue, 29 Nov 2011 07:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qga9olojY7-n for ; Tue, 29 Nov 2011 07:09:31 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EB6CD21F8AC9 for ; Tue, 29 Nov 2011 07:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pATF9NF0025591; Tue, 29 Nov 2011 16:09:23 +0100 (CET) Received: from eduroam-pool6-0601.wlan.uni-bremen.de (eduroam-pool6-0601.wlan.uni-bremen.de [134.102.26.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B664A6A; Tue, 29 Nov 2011 16:09:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20111128155916.GE22835@elstar.local> Date: Tue, 29 Nov 2011 16:09:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73DE8CE6-8C58-414C-994E-891560A78D4B@tzi.org> References: <4ECCA4F0.7010504@bwijnen.net> <20111128155916.GE22835@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: netconf@ietf.org Subject: Re: [Netconf] PSK comment during NETCONF session at IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:09:31 -0000 On Nov 28, 2011, at 16:59, Juergen Schoenwaelder wrote: >>> 2) We can store the username with the key and use the PSK identity = as >>> just that, a key identity; the username is then retrieved with the = key. >>=20 >> e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, = and there would be a table like >>=20 >> Jpzb3YWS cabo@tzi.org (key=85) >> K3nV6qh0 cabo@tzi.org (key=85) >> A4AINPdk bertietf@bwijnen.net (key=85) >> n5Dft5CQ mehmet.ersue@nsn.com (key=85) >> 2qQbLrhI mehmet.ersue@nsn.com (key=85) >>=20 >> (probably with columns added that maintain the key validity time = ranges). >>=20 > Option 2) seems to be a safe bet since it pushed the problem to > controllable configuration (and as a side effect we would have a > NETCONF way of managing PSK keys). Sounds good to me. Gr=FC=DFe, Carsten From dromasca@avaya.com Tue Nov 29 08:38:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDCD21F8BF4 for ; Tue, 29 Nov 2011 08:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D7G8ZDmmWCj for ; Tue, 29 Nov 2011 08:38:47 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 404E821F8AFA for ; Tue, 29 Nov 2011 08:38:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAAN0J1U7GmAcF/2dsb2JhbABDmmKQGIEFgXIBAQEBAxIeCksGAQgNBAQBAQsGDAsBB0UHAQEFBAEEEwganzeEFJtjiAmCMmMEmjmMLQ X-IronPort-AV: E=Sophos;i="4.69,592,1315195200"; d="scan'208";a="316988581" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Nov 2011 11:38:44 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Nov 2011 11:36:45 -0500 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, 29 Nov 2011 17:38:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-netconf-access-control-06 Thread-Index: AcyuF5BqVfAUJ9IqRUO/NntQ7LuMHQAncVdA From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: secdir review of draft-ietf-netconf-access-control-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 16:38:47 -0000 -----Original Message----- From: Carl Wallace [mailto:carl@redhoundsoftware.com]=20 Sent: Monday, November 28, 2011 11:49 PM To: draft-ietf-netconf-access-control.all@tools.ietf.org Cc: iesg@ietf.org; secdir@ietf.org Subject: secdir review of draft-ietf-netconf-access-control-06 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines such an access control model to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. I am not familiar with NETCONF or YANG so my review may be off-base. I found the frequent references to "recovery sessions" and "non-recovery sessions" unnecessary and somewhat confusing. Couldn't this concept be described once and omitted from the various lists of steps? There are probably some inconsistencies in the RFC 2119 language around the "recovery session" concept. For example, section 3.4.4 provides a bulleted list of steps that MUST be followed. Included in this list is an exception for recovery sessions. Section 3.3.1 says a "server MAY support a "recovery session" mechanism". Should 3.3.1 be a MUST? Section 3.1.1 references both "recovery session" and the ability to disable the entire access control model "during operation, in order to debug operational problems". What does the latter bullet that mentions debugging refer to in the model? Is this bullet just a second reference to recovery session? In section 3.2.4, copy operations may be partially performed while "nodes to which the client does not have read access are silently omitted". Why is this OK? It seems inconsistent with section 3.1.3, which says "If the user is authorized to perform the requested access operation on the requested data, then processing continues", implying that processing does not continue otherwise. The same silent skipping of items appears elsewhere as well, including edit config. At a minimum, some rationale describing why these silent omissions are acceptable should be provided. From dromasca@avaya.com Tue Nov 29 08:39:11 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1458321F8C76 for ; Tue, 29 Nov 2011 08:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjAgzJloK0BU for ; Tue, 29 Nov 2011 08:39:09 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF8E21F8AFA for ; Tue, 29 Nov 2011 08:39:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAAIoJ1U6HCzI1/2dsb2JhbABDmmKQGIEFgXIBAQEBAxIeCj0OBgEIDQQEAQELBgwLAQdFBwEBBQQBBBMIGp83hBSbY4gJgjJjBJo5jC0 X-IronPort-AV: E=Sophos;i="4.69,592,1315195200"; d="scan'208";a="279642515" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Nov 2011 11:39:04 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Nov 2011 11:27:20 -0500 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, 29 Nov 2011 17:39:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-netconf-system-notifications-06 Thread-Index: AcyuKpFYfdWR2kGRTCWxWg8QktjYBwAis4Bg From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: Secdir review of draft-ietf-netconf-system-notifications-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 16:39:11 -0000 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Brian Weis Sent: Tuesday, November 29, 2011 2:05 AM To: secdir@ietf.org; The IESG Cc: draft-ietf-netconf-system-notifications.all@tools.ietf.org Subject: Secdir review of draft-ietf-netconf-system-notifications-06 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. Events reported include change of system configuration, start or stop of of a NETCONF client, and the like. These are important notifications for the purposes of accounting and auditing. I have two comments on the Security Considerations text: 1) The first paragraph indicates that SSH is mandatory-to-implement for the transport layer and cites RFC 6242 ("Using the NETCONF Protocol over Secure Shell (SSH)". This is certainly good and acceptable, but I'm not sure where the statement is made that says RFC 6242 MUST be implemented as part of a NETCONF implementation. It would be good to cite that RFC as well. 2) The second paragraph wisely states that read access to the data nodes described in this memo should be controlled. It would be helpful to give some advice how the control can be done. For example, this could be an authorization step by the SSH server as part of authenticating a client. Or it could be true because authentication credentials known by server are only given to users who are authorized to have read access. The first paragraph of RFC 62642's Security Considerations discusses this a bit and seems to imply the latter authorization model. If that's the intention here, a statement recommending giving out authentication credentials only to users/devices authorized to read the NETCONF notifications would be sufficient. Brian From cabo@tzi.org Tue Nov 29 12:20:02 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A331F0CAE for ; Tue, 29 Nov 2011 12:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.316 X-Spam-Level: X-Spam-Status: No, score=-103.316 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cODhIN3xqowl for ; Tue, 29 Nov 2011 12:20:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D71F0CAD for ; Tue, 29 Nov 2011 12:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pATKJjpF010273; Tue, 29 Nov 2011 21:19:47 +0100 (CET) From: Carsten Bormann To: "t.petch" In-Reply-To: <035a01ccae83$5c9c55c0$4001a8c0@gateway.2wire.net> X-Priority: 3 References: <4ECCA4F0.7010504@bwijnen.net> <20111128155916.GE22835@elstar.local> <035a01ccae83$5c9c55c0$4001a8c0@gateway.2wire.net> Message-Id: <53FCB843-FCB0-4F2E-9715-566354C9FA65@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Nov 2011 21:19:45 +0100 X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] PSK comment during NETCONF session at IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 20:20:02 -0000 On Nov 29 2011, at 11:40, t.petch wrote: > lack of interest in PSK > and allied technologies I see the same problem in a slightly different light: TLS is just not yet being used a lot for PSK (just as, e.g., TLS 1.2 hasn't seen a lot of use yet). If we want to get TLS there (and I certainly want to get the DTLS part of TLS there), we have to make it fit for PSK. Or we'll have to use something else, and that would be a pity. But then I don't think the mapping between the identity hints used in the handshake and application layer user-ids used in ACLs is something that needs to be part of TLS itself. Different applications may have different needs here. Where they don't, something like RFC 6125 may emerge. Gruesse, Carsten