From owner-netconf@ops.ietf.org Sun Jun 03 16:03:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwIC-00073p-UI for netconf-archive@lists.ietf.org; Sun, 03 Jun 2007 16:03:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuwIB-00029S-EM for netconf-archive@lists.ietf.org; Sun, 03 Jun 2007 16:03:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Huw9k-000MQk-Cs for netconf-data@psg.com; Sun, 03 Jun 2007 19:54:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.200] (helo=smtp101.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Huw9Z-000MQC-1G for netconf@ops.ietf.org; Sun, 03 Jun 2007 19:54:22 +0000 Received: (qmail 16845 invoked from network); 3 Jun 2007 19:54:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 3 Jun 2007 19:54:15 -0000 X-YMail-OSG: 9575mGEVM1kZtT1BQWinsJbn_F7pqzUqRBVOltgW3NaUSpxlt9F1QkW0_95UYEvBQMCN4Q.dGr_5zbyYhG0IRCJR2w-- Message-ID: <46631C34.8090200@andybierman.com> Date: Sun, 03 Jun 2007 12:53:24 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification-07 XSD bugs in Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi, Two more XSD bugs: --------------------- OLD: NEW: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------------- OLD: NEW: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------------------- Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 03 16:54:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hux6E-0007At-KM for netconf-archive@lists.ietf.org; Sun, 03 Jun 2007 16:54:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hux6E-0007Mx-5O for netconf-archive@lists.ietf.org; Sun, 03 Jun 2007 16:54:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hux16-000P6M-Kk for netconf-data@psg.com; Sun, 03 Jun 2007 20:49:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.212] (helo=smtp113.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hux0v-000P5T-2u for netconf@ops.ietf.org; Sun, 03 Jun 2007 20:49:30 +0000 Received: (qmail 49252 invoked from network); 3 Jun 2007 20:49:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 3 Jun 2007 20:49:24 -0000 X-YMail-OSG: Tn26NhkVM1k5_3SxnEqSldJ5dwpWHdlCDJEXB5iQO1kEZSIoJ3FLulCIJB_vLL9zKB.WvPZjgpDKaEPc0RZbfBshPA-- Message-ID: <46632921.1010403@andybierman.com> Date: Sun, 03 Jun 2007 13:48:33 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: notification-07 issue list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Hi, We need to finish up this document by the end of the Chicago IETF. This is a first draft issue list, based on mailing list comments so far. It is getting increasingly difficult to get people to review successive versions of the draft. It seems that each time, not all approved changes are made, and one or two new things show up that were never even discussed by the WG. This has the combined effect of discouraging people from reviewing new versions, and keeps generating new issues to resolve. Therefore, we need to focus on creating a final edit list and making sure that it is applied exactly as approved by the WG, so we can finally forward the draft to the IESG. The issue list below highlights the recent comments made on notification-07: http://ops.ietf.org/lists/netconf/netconf.2007/msg00136.html http://ops.ietf.org/lists/netconf/netconf.2007/msg00137.html http://ops.ietf.org/lists/netconf/netconf.2007/msg00148.html http://ops.ietf.org/lists/netconf/netconf.2007/msg00153.html http://ops.ietf.org/lists/netconf/netconf.2007/msg00196.html --------------------------------------------- 1) named profiles a) element in named profile is not used for anything b) need (==) to properly support edit-config operation c) edit-config not applicable to contents of because its base type is 'any' d) filter element is optional. Not clear what use case a named profile without a filter supports. 2) data model element a) definition is not extensible, such that XSD cannot be properly used to specify extensions and restrictions b) new element named 'replayLogStartTime' has been added to the XSD. This is not mentioned anywhere in the draft. The WG never discussed adding this element. 3) XSD and Xpath corrections [see message list for details] 4) XSD template for wrapper a) current definition is not what the WG agreed to, and does not even support the replayComplete notification correctly b) definition is not extensible, such that XSD cannot be properly used to specify extensions and restrictions 5) XML representation of the notification a) new element named has been added to the XSD. The WG never discussed adding this element. There is no text in the document about this element, including its actual XML type definition, purpose, or value for the notification. 6) SSH Transport Support Text a) need separate document to support top-level element explicitly by NETCONF over SSH ------------------------------------------------------------------ Please try to use a separate email for each existing topic or new topic, instead of responding to this thread, if you want to comment on any of the open issues. We would like to finish up as much as possible on the mailing list, and not defer these decisions until the meeting in Chicago. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 04 11:40:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEfm-000705-6N for netconf-archive@lists.ietf.org; Mon, 04 Jun 2007 11:40:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEfl-0007tS-K4 for netconf-archive@lists.ietf.org; Mon, 04 Jun 2007 11:40:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HvEW0-0004F1-LT for netconf-data@psg.com; Mon, 04 Jun 2007 15:30:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.200.85] (helo=sccrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HvEVm-0004D0-Hf for netconf@ops.ietf.org; Mon, 04 Jun 2007 15:30:34 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007060415302401500cflc2e>; Mon, 4 Jun 2007 15:30:24 +0000 From: "David B Harrington" To: References: Subject: review of draft-ietf-netconf-notification-07.txt Date: Mon, 4 Jun 2007 11:30:12 -0400 Message-ID: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceXRE91A8nJ4LkHS6a1kG7s9y7K7QPZtIIA Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Hi, I haven't had a chance to complete my review of this revision; I'll try to review the remaining pages soon. In the meantime, I'll provide input on pages 1-21. section 1.1 "Subscription" does not define what a subscription is. "Operation" is self-referential, which is a bad thing for definition. ("an operation refers to an operation." Not very helpful. "Named Profile" is included, but not "Filter". Section 2.1.1 defines both. What is a "Network Element"? This is used in a definition but is nto defined itself. section 1.2 "this work is to enable ... sending ... messages ... consistent with the data model ... and security model ..." I am not sure what data model and security model refers to; I'm not sure they are defined anywhere yet. I don't know how this document will make things consistent with them. Would it be more accurate to change "consistent with" to "independent of"? or independent of specific data models and specific security models? What is a security model in netconf terms? It is not defined here or in RFC4741. section 1.3 "A capability may be advertised to announce that a server is able to process RPCs while a notification stream is active on a session. The behaviour of such a capability is outside the scope of this document." As I read this, I thought "if it is outside the scope of this document, then why mention it here?". But if oyu remove this text, then you miss an important decision made by this WG about the netconf notifications protocol, which seems to argue that it is in scope for this document. Shouldn't it be discussed here to ensure interoperability of this feature of the notification protocol? We certainly spent a lot of time debating it in the Montreal interim meeting, because it was important to understand the implications of this feature, and I don't see much of that debate captured here. Section 1.4 consistent capitalization of the bullets, please. "(syslog and SNMP are rather constrained in terms of message sizes)" is not actually true any longer. draft-ietf-syslog-protocol-20 defines no upper limit to message size. and "When an SNMP entity uses the snmpSSHDomain transport model, it must be capable of accepting messages up to and including 8192 octets in size. Implementation of larger values is encouraged whenever possible." "Data content must not preclude the use of the same data model as used in configuration" I'm not quite sure what this means, since this document does not define data content, does it? If you keep the sentence, I think it should read "same data model for notifications as is used in configuration." " o solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism (data content fully describes a notification; protocol information is not needed to understand a notification)" Isn't thsi about data modeling, not the protocol? section 2.1 capitalization in the section title: s/Subscribing to receive Event Notifications/Subscribing to Receive Event Notifications/ s/When the event notification subscription is created, the events of interest are specified./The events of interest MUST be specified when the event notification subscription is created./ section 2.1.1 Filter: s/This is mutually exclusive/The filter parameter is mutually exclusive/ ("this" could refer to the behavior described in the previous sentence.) Named profile: Is the sentence needed that says "If not present, no additional filtering will be applied."? s/Note that changes/Changes/ s/This/The Named Profile parameter/ Start Time s/indicates/indicate/ Stop Time: Can stop time precede start time? Hasn't this been asked before? I don't see it mentioned here. section 2.2.1 s/event of interest (i.e., ...) to them/event of interest to them (i.e., ...)/ section 2.3 Are there any security considerations for this still being an active session after terminating? section 3.2 Figure 4 does not show where access control is applied, but section 3.2.5.1 mentions that a session must have sufficient privilege. I assume the "privilege" check is perfomed after the stream is formed, and probably before the Filter is applied. Or is "privilege" determined by the netconf server, after filtering? Should the concept of "privilege" or "access control" be included in this diagram someplace, so operators and implementers can tell where the access control occurs in the flow? Should it be mentioned explciitly? section 3.2.2 Is "contents" or "content" approrpiate here? Must the XML be well-formed? Must it be valid? 3.2.3 s/NETCONF XML event notifications/NETCONF event notifications/ 3.2.5.1 s/where element is/where the element is/ "value is unique" - within what scope? s/snmp/SNMP/g section 3.2.5.2 s/available event streams to/event streams available to/ section 3.3.1 Is "recently" accurate? who defines what recent means? Would "previously" be accurate? Is "resend" accurate? what if the event were logged and never sent (due to loss of connectivity, for example)? Don't those also get "replayed"? section 3.3.2 Is the "replay complete" notification of section 3.3.2 the same as the replayComplete notification of section 3.3.3? There are a number of these that should be made consistent. I personally found the replayComplete easier to recognize as a specific notiication than the "replay complete notification" which has to be parsed (just slightly) to make sure "replay" or "complete" were not being used as verbs in the sentence. If you keep replay complete, then please quote it. section 3.3.2 and 3.3.3 have text about when the replay complete notification is sent. section 3.3.2 says it is sent to indicate that all of the replay notications have been sent, but 3.3.3 says it will only be sent if a stopTime was specified. So, I assume this menas only the replay notificiaitons with a time less than or equal to stopTime are sent, not "all of the replay notificiaitons". If I understand correctly, if I am replaying notifications, and I set the stopTime to be the time of my request, the channel may not be available for new notifications while I am replaying, so they get logged into the stream. They do not get "replayed" if I set a stopTime when I make the request for replay, since they are later than that stopTime. If I don't set a stopTime, the new logged notifications are also replayed, and new (non-replay) notifications will be sent as they arise naturally (per 3.3.2). Will netconf let me know when everything logged has been replayed (so I can tell that subsequent notifications in the stream will be real-time)? I think I'd like to know that. What is a "normal" NETCONF session? Is there a difference between a subscription with no stopTime that sends notificiaitons as they arise naturally, and a subscription with a stopTime that becomes a "normal" netconf session? section 3.4 s/and the query/and to query/ The XSD: "Named Profile" discusses the fact that it can be created, read, deleted, and modified. Should this documentation also include mention of the fact that once applied to a subscription, that instance cannot be modified, i.e., modifications will not impact the already-created subscription? "lastModified" says "Therefore, this time should be compared with the last modified time asscoiated with the subscription. If ..." I recommend s/subscription. If/subscription; if/ s/Note that//g - Please get rid of (at least) some of these unnecessary "Note that" phrases; everything in the spec is important, but that doesn't mean every sentence should start with "Note that". They are just not needed. "notethere is no guarantee that the profile named in the subscription will be found at all." - So what happens when that occurs? Should nothing be sent? should everything be sent? shoul dit generate an error because obviously there is a mismatch of expectations? section 3.6 "it will be filtered out" - what is filtered out? the data? the notification? Note that "Note that ... Note that ... Note that ... Note that" is irritating! Did we ever resolve the lowerCamel vs C-style naming? I see "named-profile" and stopTime. Can we be consistent? Note that ... I will send more later if I have time. ;-) [a quick glance at security considerations - I recommend this section include a discussion of the threats specific to notifications, and specifically how to mitigate those threats (e.g., use the SSH transport defined in RFCxxxx). I think this whole section will need work to pass security review. I'll try to make some recommendations later.] David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 07 12:17:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKft-0007cC-6h for netconf-archive@lists.ietf.org; Thu, 07 Jun 2007 12:17:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKfq-00037s-Q8 for netconf-archive@lists.ietf.org; Thu, 07 Jun 2007 12:17:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwKX9-000Mr2-St for netconf-data@psg.com; Thu, 07 Jun 2007 16:08:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.96] (helo=smtp109.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwKWt-000Mpx-52 for netconf@ops.ietf.org; Thu, 07 Jun 2007 16:08:18 +0000 Received: (qmail 11670 invoked from network); 7 Jun 2007 16:08:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 7 Jun 2007 16:08:06 -0000 X-YMail-OSG: gfueYN4VM1maMoKUASvquPenCjIY2NgixkPjBupTBoOS46PyPLPFMfOYhwyZkZPMeqxeW_KuQZmRLvoZCcjUIwzhyw-- Message-ID: <46682D2F.1080905@andybierman.com> Date: Thu, 07 Jun 2007 09:07:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Shilpa Jayantilal Bharkhada CC: netconf@ops.ietf.org Subject: Re: Plz help regarding implemetation of NETCONF over SSH References: <005b01c7a376$c90bca50$a021320a@telxsi.com> In-Reply-To: <005b01c7a376$c90bca50$a021320a@telxsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Shilpa Jayantilal Bharkhada wrote: > Hi Andy, > Sorry to bother you again on this. > > Just wanted one more clarification for this if you could help. > When ssh client is being used to create the subsystem as in "ssh -s > ourserver.com -p 830 netconf" , I understand that the ssh client is directly > connecting to the netconf subsystem agent which is starting at port 830. > This ssh command should work (on linux at least). Are you sure you properly configured the security on your server to accept NETCONF connections on port 830? (Update /etc/services and /etc/ssh/sshd_config for starters.) > Is this the correct way for the client to connect to the netconf agent or > client should always connect to port 22 i.e to sshd server (and not directly > to 830) and ssh will take care of tunnelling the communication to the agent > app at 830 ? > > Kindly help to understand section 3 of the RFC 4742 from your previous > implementation experience.I will highly appreciate this. > Any help in this regards from others will also be appreciated. > Regards, > Shilpa > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 11:26:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgMY-0007aC-6T for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:26:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgMW-0005c4-Nx for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:26:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwgFB-0000Jv-AX for netconf-data@psg.com; Fri, 08 Jun 2007 15:19:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [195.8.104.5] (helo=cypher.de.keymile.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwgF0-0000JC-2g for netconf@ops.ietf.org; Fri, 08 Jun 2007 15:19:11 +0000 Received: from mailrelay.de.keymile.net ([10.9.1.54]) by cypher.de.keymile.com (8.12.11.20060308/8.12.11) with ESMTP id l58FVAxU002622 for ; Fri, 8 Jun 2007 17:31:10 +0200 Received: from srvdehan1003.de.keymile.net (srvdehan1003.de.keymile.net [10.9.1.108]) by mailrelay.de.keymile.net (8.12.2/8.12.2) with ESMTP id l58FHoY2008773 for ; Fri, 8 Jun 2007 17:17:50 +0200 (MEST) Received: from SRVCHBER1212.ch.keymile.net ([172.31.32.9]) by srvdehan1003.de.keymile.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 17:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: NETCONF clarifications Date: Fri, 8 Jun 2007 17:19:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF clarifications Thread-Index: Acep4DTCdL7nfLCyQPSCYIGfDmT6mA== From: "Peter, Christian" To: X-OriginalArrivalTime: 08 Jun 2007 15:19:03.0381 (UTC) FILETIME=[58F8B050:01C7A9E0] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi, I have been reading the NETCONF standard and noticed a lot of common things with our XML management infrastructure. We are considering to also adding the NETCONF standard to our product. Now some questions are coming up. Probably some questions are out of scope of the NETCONF protocol or maybe already discussed or even stupid:-). I apologize ahead of time if the question I'm asking has already been answered, but I would really appreciate it, if someone could give me some clarifications. Non-configuration data (commands): In the RFC it's not mention about setting non-configuration data (e.g. setting clock time). Is there any good way to do this. In our system we have such a functionality mapped with following structure:=20 - operation name - in parameters (only for the request) - out parameters (only for the reply) Should the data directly wrapped in the ? ... ... =20 Timeout: Requests can have some time to process. A example could be the or gathering a lot of statistics at once. Is there any timeout behaviour or feedback mechanism to the client, when processing for a longer time (e.g. 15 minutes).=20 Attachments: I see that NETCONF is mainly an interface for configuration and status. But are there any ideas of having some mechanism to attach real binary data (e.g. firmware) to a request or reply?=20 Regards, Christian Christian Peter R & D Software Switzerland=20 ----------------------------------------=20 KEYMILE AG Schwarzenburgstrasse 73 CH-3097 Berne-Liebefeld, Switzerland www.keymile.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 11:26:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgMY-0007aO-CT for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:26:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgMW-0005c5-Nw for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:26:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwgCy-0000Br-SZ for netconf-data@psg.com; Fri, 08 Jun 2007 15:17:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [194.9.94.111] (helo=s87.loopia.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwgCn-0000AV-FL for netconf@ops.ietf.org; Fri, 08 Jun 2007 15:16:55 +0000 Received: (qmail 58409 invoked from network); 8 Jun 2007 14:50:06 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2007 14:50:06 -0000 Received: (qmail 62352 invoked from network); 8 Jun 2007 14:50:12 -0000 Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with SMTP for ; 8 Jun 2007 14:50:12 -0000 Message-ID: <46696CA4.5070804@edgeware.tv> Date: Fri, 08 Jun 2007 16:50:12 +0200 From: Johan Rydberg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: subelements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 While working on my data model I encountered a small design problem, and decided to look what NETCONF normally do in these situations. This made me think about a thing that I've always thought was odd: Why are configurations named with an subelements of or and not text payload of the element? This should make it impossible to have a configuration named "config", for example. What is the standard way of refering to units in NETCONF? via named subelements, via reference elements () or via text? What was the idea and reason behind using named subelements for the wire protocol? Or is the idea that if you want more configurations than those the RFC mention (running, startup, candidate) you must implement the URL capability? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 11:55:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgoR-0002ZC-N9 for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:55:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgoP-0001MO-VQ for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 11:55:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hwgev-0002IZ-Qk for netconf-data@psg.com; Fri, 08 Jun 2007 15:45:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hwgej-0002H5-I0 for netconf@ops.ietf.org; Fri, 08 Jun 2007 15:45:48 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21B1720704; Fri, 8 Jun 2007 17:45:39 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-01-466979a348ca Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 074552120A; Fri, 8 Jun 2007 17:45:39 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 17:45:38 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 17:45:38 +0200 Message-ID: <466979A1.1070307@ericsson.com> Date: Fri, 08 Jun 2007 17:45:37 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Peter, Christian" CC: netconf@ops.ietf.org Subject: Re: NETCONF clarifications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 15:45:38.0435 (UTC) FILETIME=[0FB29D30:01C7A9E4] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hello Peter, I had earlier submitted a draft about operations or as I called them generic-actions. I think this is what you are looking for. The draft is not perfect and I already have some ideas how to update it. Ericsson and Tailf have both implemented a non-standard solution for such operations/actions. I would happily and actively support anyone trying to push for support such a draft. regards Balazs Peter, Christian wrote: > Hi, > I have been reading the NETCONF standard and noticed a lot of common > things with > our XML management infrastructure. > We are considering to also adding the NETCONF standard to our product. > Now some > questions are coming up. Probably some questions are out of scope of the > NETCONF > protocol or maybe already discussed or even stupid:-). > I apologize ahead of time if the question I'm asking has already been > answered, > but I would really appreciate it, if someone could give me some > clarifications. > > Non-configuration data (commands): > In the RFC it's not mention about setting non-configuration data (e.g. > setting clock time). > Is there any good way to do this. In our system we have such a > functionality mapped > with following structure: > - operation name > - in parameters (only for the request) > - out parameters (only for the reply) > > Should the data directly wrapped in the ? > > > > > ... > > > > > > > ... > > > > Timeout: > Requests can have some time to process. A example could be the > or > gathering a lot of statistics at once. Is there any timeout behaviour or > feedback > mechanism to the client, when processing for a longer time (e.g. 15 > minutes). > > Attachments: > I see that NETCONF is mainly an interface for configuration and status. > But are > there any ideas of having some mechanism to attach real binary data > (e.g. firmware) > to a request or reply? > > > Regards, > Christian > > > Christian Peter > R & D Software Switzerland > ---------------------------------------- > KEYMILE AG > Schwarzenburgstrasse 73 > CH-3097 Berne-Liebefeld, Switzerland > www.keymile.com > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 13:07:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhwG-0006xf-40 for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 13:07:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwhwF-0003rk-Mg for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 13:07:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hwhpp-0007a9-7Q for netconf-data@psg.com; Fri, 08 Jun 2007 17:01:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hwhpe-0007YZ-2J for netconf@ops.ietf.org; Fri, 08 Jun 2007 17:01:07 +0000 Received: from 16.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-outbound.avaya.com with ESMTP; 08 Jun 2007 13:00:59 -0400 X-IronPort-AV: i="4.16,400,1175486400"; d="scan'208"; a="25083534:sNHT2151904584" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Begin Working Group Last Call: draft-ietf-netconf-notification-07.txt Date: Fri, 8 Jun 2007 19:00:58 +0200 Message-ID: In-Reply-To: <464DC062.7090400@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Begin Working Group Last Call: draft-ietf-netconf-notification-07.txt Thread-Index: AceZXn0J3uaWTdLOQAOPOdOUCGhayAQj1+pA References: <464DC062.7090400@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 1. This document needs a (temporary) 'Change Log' section. This is needed now, as we are in final editing phase in the WG and we want to make sure that all and only changes reflecting the comments in the Last Call and reviews are addressed. This will be needed also in the coming phases, so I suggest to include it starting with the coming I-D version. 2. The IANA Considerations version is a little confusing with the usage of past time for what is actually a requirement for registry entry from IANA. Also, there is no such reference [7] which is mentioned in this section.=20 3. There seems to be no need for [RFC2223] to be referenced. If there is a need however in order to avoid what would be a DOWNREF from a standards track to an Informational document, [RFC2223] should be included in a newly created Informational References sub-section.=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Friday, May 18, 2007 6:04 PM > To: Netconf (E-mail) > Subject: Begin Working Group Last Call:=20 > draft-ietf-netconf-notification-07.txt >=20 > Hi, >=20 > The NETCONF WG is concluding work on the NETCONF=20 > Notifications document. > The WG is urged to review the latest draft as soon as=20 > possible and send comments to the WG mailing list: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific ation-07.txt At this time, only corrections and strong objections are being considered. An issue with the named profiles has been raised, in which there is concern that the operation cannot be implemented in an interoperable manner for the element. Do you think named profiles are important to keep in this document? Do you think the edit-config interoperability problem is important? Do you understand the XSDs? Are they correct? Do you understand the examples? Are they correct? Do you understand how new notifications in new XSDs would be defined? Do you understand how create-subscription works with named profiles? Do you understand how notification replay works? Should the element allow 'anyAttribute' like the element? Currently attributes are not allowed at all in the element. Please send your comments to the WG mailing list by June 8, 2007 at 5PM ET. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 17:07:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlfp-00013d-3S for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 17:07:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlfo-0007fv-MK for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 17:07:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwlZO-000McS-Bl for netconf-data@psg.com; Fri, 08 Jun 2007 21:00:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwlZD-000Man-7X for netconf@ops.ietf.org; Fri, 08 Jun 2007 21:00:24 +0000 Received: (qmail 41115 invoked from network); 8 Jun 2007 21:00:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 8 Jun 2007 21:00:18 -0000 X-YMail-OSG: YyxjpfAVM1nIiPES0O7UJ3ebMurETs4ouq2P9kjgDJ_RACQKxa8TxRf0X82HQ_KWa73kzYht0zt6C1mYVC7wcIX7 Message-ID: <4669C32B.80301@andybierman.com> Date: Fri, 08 Jun 2007 13:59:23 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Peter, Christian" CC: netconf@ops.ietf.org Subject: Re: NETCONF clarifications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Peter, Christian wrote: > Hi, > I have been reading the NETCONF standard and noticed a lot of common > things with > our XML management infrastructure. > We are considering to also adding the NETCONF standard to our product. > Now some > questions are coming up. Probably some questions are out of scope of the > NETCONF > protocol or maybe already discussed or even stupid:-). > I apologize ahead of time if the question I'm asking has already been > answered, > but I would really appreciate it, if someone could give me some > clarifications. > > Non-configuration data (commands): > In the RFC it's not mention about setting non-configuration data (e.g. > setting clock time). I call this middle ground "transient configuration (tconfig)" It is writable, but not saved in NV-storage. > Is there any good way to do this. In our system we have such a > functionality mapped > with following structure: > - operation name > - in parameters (only for the request) > - out parameters (only for the reply) > > Should the data directly wrapped in the ? > You could define your own non-standard RPC method or use the standard operations. The data classification that is critical to implementation (i.e., state vs. tconfig vs. config) is not officially part of NETCONF, but the standard operation can be used on the data anyway. none set rollback-on-error ... > > > > ... > > > > > > > ... > > > > Timeout: > Requests can have some time to process. A example could be the > or > gathering a lot of statistics at once. Is there any timeout behaviour or > feedback > mechanism to the client, when processing for a longer time (e.g. 15 > minutes). There was -- it was removed from an early version of the protocol. A set of standard notifications may be produced, which would include a 'delayed rpc-reply'. For now, I suggest sending an back right away and using a proprietary notification (or data model) to indicate the progress and/or final status. > > Attachments: > I see that NETCONF is mainly an interface for configuration and status. > But are > there any ideas of having some mechanism to attach real binary data > (e.g. firmware) > to a request or reply? This has come up in the past and I suppose if a proposal existed which got enough support, it could be standardized. For now, define your own RPC and use a 'hexBinary' parameter. > > > Regards, > Christian > > > Christian Peter > R & D Software Switzerland Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 17:29:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwm1q-0007FO-Nv for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 17:29:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwm1o-0006HJ-E3 for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 17:29:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwlwR-000NvN-Ie for netconf-data@psg.com; Fri, 08 Jun 2007 21:24:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwlwH-000Nuo-0q for netconf@ops.ietf.org; Fri, 08 Jun 2007 21:24:14 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 08 Jun 2007 14:24:09 -0700 X-IronPort-AV: i="4.16,401,1175497200"; d="scan'208"; a="16075518:sNHT29538648" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l58LO7J27997; Fri, 8 Jun 2007 14:24:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l58LWUjw018222; Fri, 8 Jun 2007 17:32:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706082132.l58LWUjw018222@idle.juniper.net> To: Johan Rydberg cc: netconf@ops.ietf.org Subject: Re: subelements In-Reply-To: Your message of "Fri, 08 Jun 2007 16:50:12 +0200." <46696CA4.5070804@edgeware.tv> Date: Fri, 08 Jun 2007 17:32:30 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Johan Rydberg writes: >Why are configurations named with an subelements of or >and not text payload of the element? This should make it impossible to >have a configuration named "config", for example. I think you have it backwards, or I'm misunderstanding you. By using named subelements, we allow extensibility such as: and: greek or even: config Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 08 18:36:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwn4E-0001js-Jm for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 18:36:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwn4D-0000if-8t for netconf-archive@lists.ietf.org; Fri, 08 Jun 2007 18:36:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwmwQ-0001NN-04 for netconf-data@psg.com; Fri, 08 Jun 2007 22:28:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HwmwF-0001Mk-0V for netconf@ops.ietf.org; Fri, 08 Jun 2007 22:28:16 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 08 Jun 2007 15:28:11 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l58MS9J42619; Fri, 8 Jun 2007 15:28:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l58Madjw018887; Fri, 8 Jun 2007 18:36:39 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706082236.l58Madjw018887@idle.juniper.net> To: "Peter, Christian" cc: netconf@ops.ietf.org Subject: Re: NETCONF clarifications In-Reply-To: Your message of "Fri, 08 Jun 2007 17:19:03 +0200." Date: Fri, 08 Jun 2007 18:36:39 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a "Peter, Christian" writes: >We are considering to also adding the NETCONF standard to our product. Excellent news!! >In the RFC it's not mention about setting non-configuration data (e.g. >setting clock time). NETCONF allows you to define your own RPCs, with custom input parameters (encoded in xml) and custom XML output. So you can do something like: +%y%m%d%H%M.%S and you reply can contain whatever data you want. We do similar stuff in the JUNOScript API, which is available over NETCONF, as well as our older ssl-based access method. Check out: http://www.juniper.net/support/junoscript/ for details and examples. >Is there any timeout behaviour or feedback mechanism to the client, >when processing for a longer time (e.g. 15 minutes). Early drafts of the NETCONF spec had the operation from JUNOScript, but it was tossed out for reasons I don't remember. Without a way for the client to tell the server to stop (and the server to acknowledge it), you are stuck. You can make the server implement a timeout, like; /tmp/sw.tgz 10 >But are >there any ideas of having some mechanism to attach real binary data >(e.g. firmware) >to a request or reply? We do this with an parameter, like: core-file.tgz base64 The reply is something like: some-totally-awful-unreadable-and-long-stuff-here This shipped in JUNOS 8.3, for which the docs are not yet available on the public web site. If you want the full details, holler and I'll get them for you. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 09 15:25:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx6Yt-0002HK-BO for netconf-archive@lists.ietf.org; Sat, 09 Jun 2007 15:25:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx6Yr-0000jl-PB for netconf-archive@lists.ietf.org; Sat, 09 Jun 2007 15:25:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hx6Rg-000DmV-AR for netconf-data@psg.com; Sat, 09 Jun 2007 19:17:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hx6RV-000Dlu-2w for netconf@ops.ietf.org; Sat, 09 Jun 2007 19:17:50 +0000 Received: from localhost (h211n2c1o851.bredband.skanova.com [81.225.33.211]) by mail.tail-f.com (Postfix) with ESMTP id 876641B80C3; Sat, 9 Jun 2007 21:17:32 +0200 (CEST) Date: Sat, 09 Jun 2007 21:17:31 +0200 (CEST) Message-Id: <20070609.211731.75255468.mbj@tail-f.com> To: phil@juniper.net Cc: johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements From: Martin Bjorklund In-Reply-To: <200706082132.l58LWUjw018222@idle.juniper.net> References: <46696CA4.5070804@edgeware.tv> <200706082132.l58LWUjw018222@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Phil Shafer wrote: > Johan Rydberg writes: > >Why are configurations named with an subelements of or > >and not text payload of the element? This should make it impossible to > >have a configuration named "config", for example. > > I think you have it backwards, or I'm misunderstanding you. > > By using named subelements, we allow extensibility such as: > > > > ... except that this isn't allowed by the XSD in rfc4741. Should this be viewed as a bug in the schema? (In general I think it's unfortunate that the schema is not more extensible.) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 09 20:01:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxAsE-0007NG-UK for netconf-archive@lists.ietf.org; Sat, 09 Jun 2007 20:01:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxAsD-0004LA-Ha for netconf-archive@lists.ietf.org; Sat, 09 Jun 2007 20:01:38 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HxAlB-0000LZ-Py for netconf-data@psg.com; Sat, 09 Jun 2007 23:54:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HxAl0-0000L8-Ni for netconf@ops.ietf.org; Sat, 09 Jun 2007 23:54:16 +0000 Received: (qmail 22321 invoked from network); 9 Jun 2007 23:54:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2007 23:54:10 -0000 X-YMail-OSG: fHMVcfIVM1nowS6VSomHzYvHOEForypcG_Oe1PGZO1PM7f7SK.3I0FmjsEU4nuyPHqV0EEdu5BU7vxwiH62Qk98c Message-ID: <466B3D69.5090306@andybierman.com> Date: Sat, 09 Jun 2007 16:53:13 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements References: <46696CA4.5070804@edgeware.tv> <200706082132.l58LWUjw018222@idle.juniper.net> <20070609.211731.75255468.mbj@tail-f.com> In-Reply-To: <20070609.211731.75255468.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Martin Bjorklund wrote: > Phil Shafer wrote: >> Johan Rydberg writes: >>> Why are configurations named with an subelements of or >>> and not text payload of the element? This should make it impossible to >>> have a configuration named "config", for example. >> I think you have it backwards, or I'm misunderstanding you. >> >> By using named subelements, we allow extensibility such as: >> >> >> >> > > ... except that this isn't allowed by the XSD in rfc4741. Should this > be viewed as a bug in the schema? no -- there is no mention in the RFC of this extensibility feature that does not officially exist. I remember (way back when ;-) that Phil convinced us that was better than running It had something to do with making it easier to define an XSD that was a subset of the standard configurations. I don't see how it makes this possible without editing the schema, same as if the 'source' was an enumerated string. However, I don't mind the parameter the way it is, even if it is harder to implement than a string. A choice of N elements is more extensible than a union of N strings. > > (In general I think it's unfortunate that the schema is not more > extensible.) > We are going to make sure the Notification XSD is properly extensible. Several people (4?) have requested this and nobody has objected. I am declaring that WG consensus exists to define NETCONF XSDs such that they can be properly extended and restricted. If RFC 4741 is ever republished (highly likely), then I see no reason why the XSD cannot be altered, if it still describes the same set of valid instance documents. (But if the RFC cycles at Proposed Standard, this is not even a requirement.) > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 11 00:41:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxbiU-0001kC-9r for netconf-archive@lists.ietf.org; Mon, 11 Jun 2007 00:41:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxbiT-0000tj-09 for netconf-archive@lists.ietf.org; Mon, 11 Jun 2007 00:41:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hxbb1-0000DO-MU for netconf-data@psg.com; Mon, 11 Jun 2007 04:33:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hxbar-0000D5-0A for netconf@ops.ietf.org; Mon, 11 Jun 2007 04:33:34 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 10 Jun 2007 21:33:29 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5B4XRJ98787; Sun, 10 Jun 2007 21:33:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5B4ffjw025842; Mon, 11 Jun 2007 00:41:45 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706110441.l5B4ffjw025842@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements In-Reply-To: Your message of "Sat, 09 Jun 2007 16:53:13 PDT." <466B3D69.5090306@andybierman.com> Date: Mon, 11 Jun 2007 00:41:41 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Andy Bierman writes: >no -- there is no mention in the RFC of this extensibility feature >that does not officially exist. I remember (way back when ;-) >that Phil convinced us that > >was better than > running >It had something to do with making it easier to define an XSD >that was a subset of the standard configurations. IIRC, my argument was exactly as above, that using elements gives us extensibility. It's unfortunate that the xsd doesn't reflect this, but my view is that capabilities can extend the base protocol so this isn't really a problem. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 11 03:47:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxecG-0006ue-9A for netconf-archive@lists.ietf.org; Mon, 11 Jun 2007 03:47:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxecE-0003hF-K3 for netconf-archive@lists.ietf.org; Mon, 11 Jun 2007 03:47:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HxeWD-0009nl-DB for netconf-data@psg.com; Mon, 11 Jun 2007 07:40:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HxeW1-0009nM-BY for netconf@ops.ietf.org; Mon, 11 Jun 2007 07:40:48 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 154571B80C3; Mon, 11 Jun 2007 09:40:37 +0200 (CEST) Date: Mon, 11 Jun 2007 09:40:17 +0200 (CEST) Message-Id: <20070611.094017.27243838.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements From: Martin Bjorklund In-Reply-To: <200706110441.l5B4ffjw025842@idle.juniper.net> References: <466B3D69.5090306@andybierman.com> <200706110441.l5B4ffjw025842@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Phil Shafer wrote: > Andy Bierman writes: > >no -- there is no mention in the RFC of this extensibility feature > >that does not officially exist. I remember (way back when ;-) > >that Phil convinced us that > > > >was better than > > running > >It had something to do with making it easier to define an XSD > >that was a subset of the standard configurations. > > IIRC, my argument was exactly as above, that using elements > gives us extensibility. It's unfortunate that the xsd doesn't > reflect this, but my view is that capabilities can extend the > base protocol so this isn't really a problem. But can you really write a capability which modifies the schema in rfc4741? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 11:49:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8cJ-00075f-MQ for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 11:49:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8cI-0005bY-1H for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 11:49:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy8SY-0002Ze-2M for netconf-data@psg.com; Tue, 12 Jun 2007 15:39:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy8SM-0002Z6-Iv for netconf@ops.ietf.org; Tue, 12 Jun 2007 15:39:00 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 064E421176 for ; Tue, 12 Jun 2007 17:38:52 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-e1-466ebe0bd45f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD95B20F8A for ; Tue, 12 Jun 2007 17:38:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:38:51 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:38:51 +0200 Message-ID: <466EBE0B.3040208@ericsson.com> Date: Tue, 12 Jun 2007 17:38:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: notification-07 replay complete References: <46632921.1010403@andybierman.com> In-Reply-To: <46632921.1010403@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 15:38:51.0475 (UTC) FILETIME=[C6C87230:01C7AD07] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hello, Chapter 3.3.2) indicates that replayComplete is sent even if a stopTime was not specified. Chapter 3.3.3) states that replayComplete is sent only if stopTime was specified. Which is true? Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 11:57:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8kB-0001O1-9R for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 11:57:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8k9-0006uP-O3 for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 11:57:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy8dl-0003KE-SR for netconf-data@psg.com; Tue, 12 Jun 2007 15:50:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy8da-0003JQ-Im for netconf@ops.ietf.org; Tue, 12 Jun 2007 15:50:36 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1055203C0; Tue, 12 Jun 2007 17:50:28 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-36-466ec0c449ab Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5ECB32107E; Tue, 12 Jun 2007 17:50:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:50:28 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:50:28 +0200 Message-ID: <466EC0C3.1000602@ericsson.com> Date: Tue, 12 Jun 2007 17:50:27 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: notification-07 issue list References: <46632921.1010403@andybierman.com> In-Reply-To: <46632921.1010403@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 15:50:28.0147 (UTC) FILETIME=[66082830:01C7AD09] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hello, I believe defining _any_ XML as configuration data in a datastore is saying: "Vendor specific, unspecified". I don't like that. A workaround could be to restrict the _any_ using plain english. However specifying XML in plain english sounds bad. I would rather delay named profiles then have _any_ as part of a standard data model. As an alternative we could refer to named profiles without actually defining them like we do with eventStreams. This would be a cleaner way to say: vendor specific. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 12:45:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9V5-0003kF-0R for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 12:45:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9V3-00047y-II for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 12:45:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy9NS-0006Sd-6o for netconf-data@psg.com; Tue, 12 Jun 2007 16:37:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hy9NH-0006Rn-1R for netconf@ops.ietf.org; Tue, 12 Jun 2007 16:37:48 +0000 Received: (qmail 72006 invoked from network); 12 Jun 2007 16:36:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2007 16:36:44 -0000 X-YMail-OSG: 4C7gMaIVM1l3n4SKP4D7EqBSNJqTDau8SUiZJl2q4.E4hC7q Message-ID: <466ECB69.1090503@andybierman.com> Date: Tue, 12 Jun 2007 09:35:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: notification-07 issue list References: <46632921.1010403@andybierman.com> <466EC0C3.1000602@ericsson.com> In-Reply-To: <466EC0C3.1000602@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Balazs Lengyel wrote: > Hello, > I believe defining _any_ XML as configuration data in a datastore is > saying: "Vendor specific, unspecified". I don't like that. A workaround > could be to restrict the _any_ using plain english. However specifying > XML in plain english sounds bad. This sounds like even more special-case (hack) code to deal with NETCONF's version of XML, instead of "real XML". > > I would rather delay named profiles then have _any_ as part of a > standard data model. I agree, if it means (and it does) backing into an important data modeling decision without thinking it through or specifying any of the details. > > As an alternative we could refer to named profiles without actually > defining them like we do with eventStreams. This would be a cleaner way > to say: vendor specific. I disagree. 1) The eventStreams are defined well enough to be used within the notification system. How they get there in the first place is outside the standard. Without specifying the contents of the named profile, there are missing pieces (like the filter). The way subtree filtering is defined, the only data type that works is 'any'. Well-formed junk is just no-match, nothing more. 2) It is not vendor-specific. The 'any' node (filter) has a conceptual definition and there are standard algorithms for determining the filter output. The real problem is that itself is not fully specified for all possible data-model related corner-cases. IMO, the NETMOD specification should fill in those gaps, not the protocol spec. I am definitely in favor of creating standard data models whenever possible, but a data model containing a template for every conceivable data model is problematic, and perhaps not that important in our notification delivery system. Passing the as an RPC parameter places it immediately into the 'internal format', not available to . > > Balazs > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 16:40:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDAI-0001pZ-8O for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 16:40:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDAG-0004AX-Ve for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 16:40:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyD3T-000KNY-M9 for netconf-data@psg.com; Tue, 12 Jun 2007 20:33:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyD3I-000KMy-NM for netconf@ops.ietf.org; Tue, 12 Jun 2007 20:33:26 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 12 Jun 2007 13:33:20 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5CKX7J98412; Tue, 12 Jun 2007 13:33:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5CKfYjw033743; Tue, 12 Jun 2007 16:41:34 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706122041.l5CKfYjw033743@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements In-Reply-To: Your message of "Mon, 11 Jun 2007 09:40:17 +0200." <20070611.094017.27243838.mbj@tail-f.com> Date: Tue, 12 Jun 2007 16:41:34 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Martin Bjorklund writes: >But can you really write a capability which modifies the schema in >rfc4741? If you can't, the protocol isn't extensible. If I came up with a new value for the "operation" attribute, I should be able to define a capability that defines my new operation. I can then advertise that capability and clients that understand it can use it. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 16:49:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDIg-0001Z3-7U for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 16:49:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDIe-0006yq-Ix for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 16:49:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyDDI-000Kzc-Pn for netconf-data@psg.com; Tue, 12 Jun 2007 20:43:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyDD7-000Kys-Ip for netconf@ops.ietf.org; Tue, 12 Jun 2007 20:43:35 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 643B61B80C6; Tue, 12 Jun 2007 22:43:26 +0200 (CEST) Date: Tue, 12 Jun 2007 22:43:11 +0200 (CEST) Message-Id: <20070612.224311.114664448.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements From: Martin Bjorklund In-Reply-To: <200706122041.l5CKfYjw033743@idle.juniper.net> References: <20070611.094017.27243838.mbj@tail-f.com> <200706122041.l5CKfYjw033743@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Phil Shafer wrote: > Martin Bjorklund writes: > >But can you really write a capability which modifies the schema in > >rfc4741? > > If you can't, the protocol isn't extensible. If I came up with a > new value for the "operation" attribute, I should be able to define > a capability that defines my new operation. I can then advertise > that capability and clients that understand it can use it. Agreed. I meant from a IETF / process point of view. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 17:11:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDeS-0005oL-Sz for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 17:11:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDeR-0006aa-Fo for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 17:11:44 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyDZp-000MKm-CY for netconf-data@psg.com; Tue, 12 Jun 2007 21:06:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyDZe-000MK9-HE for netconf@ops.ietf.org; Tue, 12 Jun 2007 21:06:51 +0000 Received: (qmail 5310 invoked from network); 12 Jun 2007 21:06:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 12 Jun 2007 21:06:46 -0000 X-YMail-OSG: ODVzw_8VM1lo.6Kty7XktNUuT8XHTkYRqyzxHwQwRaVOLaT5 Message-ID: <466F0AB2.6060105@andybierman.com> Date: Tue, 12 Jun 2007 14:05:54 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements References: <20070611.094017.27243838.mbj@tail-f.com> <200706122041.l5CKfYjw033743@idle.juniper.net> <20070612.224311.114664448.mbj@tail-f.com> In-Reply-To: <20070612.224311.114664448.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> But can you really write a capability which modifies the schema in >>> rfc4741? >> If you can't, the protocol isn't extensible. If I came up with a >> new value for the "operation" attribute, I should be able to define >> a capability that defines my new operation. I can then advertise >> that capability and clients that understand it can use it. > > Agreed. I meant from a IETF / process point of view. > > The issue is extension vs. restriction. There is no problem advertising a "clean extension". But let's say (hypothetical) you advertised a capability that said "I do not support the operation" and you also advertise the netconf-base capability that implies you do support the operation. That is not allowed in the protocol. > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 12 23:54:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJvx-0004fH-Ev for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 23:54:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyJvw-0001WY-4o for netconf-archive@lists.ietf.org; Tue, 12 Jun 2007 23:54:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyJoq-000FZl-29 for netconf-data@psg.com; Wed, 13 Jun 2007 03:46:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HyJof-000FZB-FM for netconf@ops.ietf.org; Wed, 13 Jun 2007 03:46:46 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 12 Jun 2007 20:46:42 -0700 X-IronPort-AV: i="4.16,414,1175497200"; d="scan'208"; a="18124759:sNHT28566548" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5D3keJ90874; Tue, 12 Jun 2007 20:46:40 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5D3ssjw035476; Tue, 12 Jun 2007 23:55:02 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706130355.l5D3ssjw035476@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , johan.rydberg@edgeware.tv, netconf@ops.ietf.org Subject: Re: subelements In-Reply-To: Your message of "Tue, 12 Jun 2007 14:05:54 PDT." <466F0AB2.6060105@andybierman.com> Date: Tue, 12 Jun 2007 23:54:53 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Andy Bierman writes: >But let's say (hypothetical) you advertised a capability >that said "I do not support the operation" and you >also advertise the netconf-base capability that implies you >do support the operation. That is not allowed >in the protocol. Right, because by advertising the base netconf capability, you've agreed to abide by a set of behavior specified on the capability definition. This serves as a contract between the client and server. If your server don't implement parts of a contract that you advertise, you've lied and misled the client into performing operations that may fail in ways the client is not prepared to handle. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 14 14:01:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytdQ-00059y-LZ for netconf-archive@lists.ietf.org; Thu, 14 Jun 2007 14:01:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytdP-0005hM-QI for netconf-archive@lists.ietf.org; Thu, 14 Jun 2007 14:01:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HytVh-000D47-Ls for netconf-data@psg.com; Thu, 14 Jun 2007 17:53:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.210] (helo=smtp111.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HytVV-000D3F-CB for netconf@ops.ietf.org; Thu, 14 Jun 2007 17:53:23 +0000 Received: (qmail 55004 invoked from network); 14 Jun 2007 17:53:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 14 Jun 2007 17:53:16 -0000 X-YMail-OSG: 1mRlN1wVM1lcyNCkLfSqIw9KAiJUo5WNgWytn4Q5cC8cypMU0fch320NA0TjrmeEaz_o3myK7TgJhguMPHCGoo3EyA-- Message-ID: <46718050.1040704@andybierman.com> Date: Thu, 14 Jun 2007 10:52:16 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: netconf@ops.ietf.org Subject: Re: review of draft-ietf-netconf-notification-07.txt References: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> In-Reply-To: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df David B Harrington wrote: > Hi, > > I haven't had a chance to complete my review of this revision; I'll > try to review the remaining pages soon. In the meantime, I'll provide > input on pages 1-21. > thanks for this review. I think the clarifications you suggest are good. The issues you raised will require some edits. The named profiles and notification replay features (bells & whistles to some degree) are not as precise and clear to implementers as we require for standards-track RFCs. I thought the sec. 1.3 capability about RPC processing was already removed. It was supposed to be removed. Andy > section 1.1 > "Subscription" does not define what a subscription is. > "Operation" is self-referential, which is a bad thing for definition. > ("an operation refers to an operation." Not very helpful. > "Named Profile" is included, but not "Filter". Section 2.1.1 defines > both. > What is a "Network Element"? This is used in a definition but is nto > defined itself. > > > section 1.2 > "this work is to enable ... sending ... messages ... consistent with > the data model ... and security model ..." I am not sure what data > model and security model refers to; I'm not sure they are defined > anywhere yet. I don't know how this document will make things > consistent with them. Would it be more accurate to change "consistent > with" to "independent of"? or independent of specific data models and > specific security models? > > What is a security model in netconf terms? It is not defined here or > in RFC4741. > > section 1.3 > "A capability may be advertised to announce that a server is able to > process RPCs while a notification stream is active on a session. The > behaviour of such a capability is outside the scope of this document." > > As I read this, I thought "if it is outside the scope of this > document, then why mention it here?". But if oyu remove this text, > then you miss an important decision made by this WG about the netconf > notifications protocol, which seems to argue that it is in scope for > this document. Shouldn't it be discussed here to ensure > interoperability of this feature of the notification protocol? We > certainly spent a lot of time debating it in the Montreal interim > meeting, because it was important to understand the implications of > this feature, and I don't see much of that debate captured here. > > Section 1.4 > consistent capitalization of the bullets, please. > > "(syslog and SNMP are rather constrained in terms of message sizes)" > is not actually true any longer. draft-ietf-syslog-protocol-20 defines > no upper limit to message size. and "When an SNMP entity uses the > snmpSSHDomain transport model, it must be capable of accepting > messages up to and including 8192 octets in size. Implementation of > larger values is encouraged whenever possible." > > "Data content must not preclude the use of the same data model as > used in configuration" > I'm not quite sure what this means, since this document does not > define data content, does it? > If you keep the sentence, I think it should read "same data model for > notifications as is used in configuration." > > " o solution should send sufficient information in a notification so > that it can be analyzed independent of the transport mechanism > (data content fully describes a notification; protocol > information > is not needed to understand a notification)" > Isn't thsi about data modeling, not the protocol? > > section 2.1 > capitalization in the section title: > s/Subscribing to receive Event Notifications/Subscribing to Receive > Event Notifications/ > > s/When the event notification subscription is created, the events of > interest are specified./The events of interest MUST be specified when > the event notification subscription is created./ > > section 2.1.1 > Filter: > s/This is mutually exclusive/The filter parameter is mutually > exclusive/ ("this" could refer to the behavior described in the > previous sentence.) > > Named profile: > Is the sentence needed that says "If not present, no additional > filtering will be applied."? > > s/Note that changes/Changes/ > s/This/The Named Profile parameter/ > > Start Time > s/indicates/indicate/ > > Stop Time: > Can stop time precede start time? Hasn't this been asked before? I > don't see it mentioned here. > > section 2.2.1 > s/event of interest (i.e., ...) to them/event of interest to them > (i.e., ...)/ > > section 2.3 > Are there any security considerations for this still being an active > session after terminating? > > section 3.2 > Figure 4 does not show where access control is applied, but section > 3.2.5.1 mentions that a session must have sufficient privilege. I > assume the "privilege" check is perfomed after the stream is formed, > and probably before the Filter is applied. Or is "privilege" > determined by the netconf server, after filtering? Should the concept > of "privilege" or "access control" be included in this diagram > someplace, so operators and implementers can tell where the access > control occurs in the flow? Should it be mentioned explciitly? > > section 3.2.2 > Is "contents" or "content" approrpiate here? > Must the XML be well-formed? Must it be valid? > > > 3.2.3 > s/NETCONF XML event notifications/NETCONF event notifications/ > > 3.2.5.1 > s/where element is/where the element is/ > "value is unique" - within what scope? > > s/snmp/SNMP/g > > section 3.2.5.2 > s/available event streams to/event streams available to/ > > section 3.3.1 > Is "recently" accurate? who defines what recent means? > Would "previously" be accurate? > > Is "resend" accurate? what if the event were logged and never sent > (due to loss of connectivity, for example)? Don't those also get > "replayed"? > > section 3.3.2 > Is the "replay complete" notification of section 3.3.2 the same as the > replayComplete notification of section 3.3.3? There are a number of > these that should be made consistent. I personally found the > replayComplete easier to recognize as a specific notiication than the > "replay complete notification" which has to be parsed (just slightly) > to make sure "replay" or "complete" were not being used as verbs in > the sentence. If you keep replay complete, then please quote it. > > section 3.3.2 and 3.3.3 have text about when the replay complete > notification is sent. section 3.3.2 says it is sent to indicate that > all of the replay notications have been sent, but 3.3.3 says it will > only be sent if a stopTime was specified. So, I assume this menas only > the replay notificiaitons with a time less than or equal to stopTime > are sent, not "all of the replay notificiaitons". > > If I understand correctly, if I am replaying notifications, and I set > the stopTime to be the time of my request, the channel may not be > available for new notifications while I am replaying, so they get > logged into the stream. They do not get "replayed" if I set a stopTime > when I make the request for replay, since they are later than that > stopTime. If I don't set a stopTime, the new logged notifications are > also replayed, and new (non-replay) notifications will be sent as they > arise naturally (per 3.3.2). Will netconf let me know when everything > logged has been replayed (so I can tell that subsequent notifications > in the stream will be real-time)? I think I'd like to know that. > > What is a "normal" NETCONF session? Is there a difference between a > subscription with no stopTime that sends notificiaitons as they arise > naturally, and a subscription with a stopTime that becomes a "normal" > netconf session? > > section 3.4 > s/and the query/and to query/ > > The XSD: > "Named Profile" discusses the fact that it can be created, read, > deleted, and modified. Should this documentation also include mention > of the fact that once applied to a subscription, that instance cannot > be modified, i.e., modifications will not impact the already-created > subscription? > > "lastModified" says "Therefore, this time should be compared with the > last modified time asscoiated with the subscription. If ..." > I recommend s/subscription. If/subscription; if/ > > s/Note that//g - Please get rid of (at least) some of these > unnecessary "Note that" phrases; everything in the spec is important, > but that doesn't mean every sentence should start with "Note that". > They are just not needed. > > "notethere is no guarantee that the profile named in the subscription > will be found at all." - So what happens when that occurs? Should > nothing be sent? should everything be sent? shoul dit generate an > error because obviously there is a mismatch of expectations? > > section 3.6 > "it will be filtered out" - what is filtered out? the data? the > notification? > > Note that "Note that ... Note that ... Note that ... Note that" is > irritating! > > Did we ever resolve the lowerCamel vs C-style naming? I see > "named-profile" and stopTime. Can we be consistent? > > Note that ... I will send more later if I have time. ;-) > > [a quick glance at security considerations - I recommend this section > include a discussion of the threats specific to notifications, and > specifically how to mitigate those threats (e.g., use the SSH > transport defined in RFCxxxx). I think this whole section will need > work to pass security review. I'll try to make some recommendations > later.] > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 15 10:16:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCaq-0006Bi-Pm for netconf-archive@lists.ietf.org; Fri, 15 Jun 2007 10:16:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCan-0006vM-Uz for netconf-archive@lists.ietf.org; Fri, 15 Jun 2007 10:16:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzCTl-000Btl-I5 for netconf-data@psg.com; Fri, 15 Jun 2007 14:08:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.208] (helo=smtp109.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzCS7-000BmP-Lb for netconf@ops.ietf.org; Fri, 15 Jun 2007 14:08:18 +0000 Received: (qmail 67637 invoked from network); 15 Jun 2007 14:00:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.156 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2007 14:00:23 -0000 X-YMail-OSG: 1ozRg1sVM1l8RSl0UUe4ct8uFXliRC60ER24CRIvU.H7QKbxHIAxBTZqz_xSMm.8uosmjsgV6TgXYoyRhRc_QLBjHg-- Message-ID: <46729B3B.9090403@andybierman.com> Date: Fri, 15 Jun 2007 06:59:23 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: NETCONF over TLS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, I'm not sure if the WG was ever officially asked to comment on the draft by Mohamad Badra called "NETCONF over TLS". So I am asking now. http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt Please send comments on this draft and the feature itself to the WG mailing list. Are there implementations of this feature (not just this draft)? Should this work be standardized? If not, should it be published as Informational or Experimental? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 15 13:42:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFom-0001GZ-LF for netconf-archive@lists.ietf.org; Fri, 15 Jun 2007 13:42:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFoj-0005mo-W2 for netconf-archive@lists.ietf.org; Fri, 15 Jun 2007 13:42:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzFcb-0002vs-17 for netconf-data@psg.com; Fri, 15 Jun 2007 17:30:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzFcQ-0002tv-Ce for netconf@ops.ietf.org; Fri, 15 Jun 2007 17:29:59 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Jun 2007 10:29:53 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5FHTqJ18372; Fri, 15 Jun 2007 10:29:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5FHcLjw048897; Fri, 15 Jun 2007 13:38:21 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706151738.l5FHcLjw048897@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: NETCONF over TLS In-Reply-To: Your message of "Fri, 15 Jun 2007 06:59:23 PDT." <46729B3B.9090403@andybierman.com> Date: Fri, 15 Jun 2007 13:38:21 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Andy Bierman writes: >Are there implementations of this feature (not just this draft)? Haven't read the draft, but we've had JUNOScript over SSL/TLS since 2001. The only difference between this and normal JUNOScript is an initial RPC that gives a user and password (). We use certificates as host-verification, but didn't go very far down this path (user certs, etc). Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 16 08:47:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzXgt-00033E-OW for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 08:47:43 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzXgq-0002hA-6j for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 08:47:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzXZG-000JhT-RN for netconf-data@psg.com; Sat, 16 Jun 2007 12:39:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzGJd-0005qR-5u for netconf@ops.ietf.org; Fri, 15 Jun 2007 18:14:39 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C284583121; Fri, 15 Jun 2007 20:14:30 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28389-02; Fri, 15 Jun 2007 20:14:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D536F830AC; Fri, 15 Jun 2007 20:14:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCB59294AD3; Fri, 15 Jun 2007 20:14:23 +0200 (CEST) Date: Fri, 15 Jun 2007 20:14:23 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: NETCONF over TLS Message-ID: <20070615181423.GC13774@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Andy Bierman , "Netconf (E-mail)" References: <46729B3B.9090403@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46729B3B.9090403@andybierman.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Fri, Jun 15, 2007 at 06:59:23AM -0700, Andy Bierman wrote: > I'm not sure if the WG was ever officially asked to comment > on the draft by Mohamad Badra called "NETCONF over TLS". > So I am asking now. > > http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt > > Please send comments on this draft and the feature itself > to the WG mailing list. > > Are there implementations of this feature (not just this draft)? I know that early implementations from INRIA were running over TLS instead of SSH. They then switched over to SSH after I told them that TLS is a non-defined transport mapping. Not sure what this means; at least there were people implementing something like NETCONF over TLS. > Should this work be standardized? > > If not, should it be published as Informational or Experimental? I don't care so much about the political implications of this question. In practice, I believe a NETCONF over TLS mapping has at least the same changes of implementation and deployment than some of the other transport we have put on the standards track and hence I would vote for a fair treatment of all the transports and then in three-five years we can decide which ones to declare historic when the others go for Draft Standard. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 16 12:20:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzb0q-0008Gm-Fw for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 12:20:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzb0o-0006dn-V1 for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 12:20:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzarN-000Akv-Qh for netconf-data@psg.com; Sat, 16 Jun 2007 16:10:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzarC-000AkO-0w for netconf@ops.ietf.org; Sat, 16 Jun 2007 16:10:40 +0000 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id SAA655592 ; Sat, 16 Jun 2007 18:08:28 +0100 Received: from 86.72.162.197 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 16 Jun 2007 19:11:40 +0200 (CEST) Message-ID: <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> In-Reply-To: <20070615181423.GC13774@elstar.local> References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> Date: Sat, 16 Jun 2007 19:11:40 +0200 (CEST) Subject: =?utf-8?Q?Re:=C2=A0NETCONF=C2=A0over=C2=A0TLS?= From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de Cc: =?utf-8?Q?Andy=C2_Bierman=C2?= , =?utf-8?Q?=C2_Netconf=C2_=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Dear Andy, Thank you for your request to the WG review. >>Are there implementations of this feature (not just this draft)? > > Haven't read the draft, but we've had JUNOScript over SSL/TLS since > 2001. The only difference between this and normal JUNOScript is > an initial RPC that gives a user and password (). > We use certificates as host-verification, but didn't go very > far down this path (user certs, etc). You are right, Phil. The draft says: When public key is used for authentication, TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. User authentication in unauthenticated or authenticated client mode is outside the scope of this document. User authentication should be handled by either an extension of TLS (such as the TLS Inner Application Extension [IATLS]) or an authentication extension of NETCONF. So, the peer acting as the NETCONF agent (acting also as TLS server) may be configured to authenticate the NETCONF manager at the TLS layer, at the NETCONF layer, or at both of these two layers. In last two cases, we need a NETCONF-specific mechanism ofr manager authentication and therefore an initial RPC is needed to convey the username and password, as in JUNOScript I will update the draft consequently, or send a separated document for with NETCONF. > Thanks, > Phil Best regard, Badra > On Fri, Jun 15, 2007 at 06:59:23AM -0700, Andy Bierman wrote: > >> I'm not sure if the WG was ever officially asked to comment >> on the draft by Mohamad Badra called "NETCONF over TLS". >> So I am asking now. >> >> http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt >> >> Please send comments on this draft and the feature itself >> to the WG mailing list. >> >> Are there implementations of this feature (not just this draft)? > > I know that early implementations from INRIA were running over TLS > instead of SSH. They then switched over to SSH after I told them that > TLS is a non-defined transport mapping. Not sure what this means; at > least there were people implementing something like NETCONF over TLS. > >> Should this work be standardized? >> >> If not, should it be published as Informational or Experimental? > > I don't care so much about the political implications of this > question. In practice, I believe a NETCONF over TLS mapping has at > least the same changes of implementation and deployment than some of > the other transport we have put on the standards track and hence I > would vote for a fair treatment of all the transports and then in > three-five years we can decide which ones to declare historic when the > others go for Draft Standard. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 16 16:24:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzepB-00054a-OA for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 16:24:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzepA-0007NQ-Dw for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 16:24:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzehb-0001EM-92 for netconf-data@psg.com; Sat, 16 Jun 2007 20:16:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzehQ-0001Dn-J9 for netconf@ops.ietf.org; Sat, 16 Jun 2007 20:16:49 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 16 Jun 2007 13:16:44 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5GKGbJ87984; Sat, 16 Jun 2007 13:16:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5GKOxjw055055; Sat, 16 Jun 2007 16:25:02 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706162025.l5GKOxjw055055@idle.juniper.net> To: badra@isima.fr cc: j.schoenwaelder@jacobs-university.de, =?utf-8?Q?Andy=C2_Bierman=C2?= , =?utf-8?Q?=C2_Netconf=C2_=C2?= Subject: Re: =?utf-8?Q?Re:=C2=A0NETCONF=C2=A0over=C2=A0TLS?= In-Reply-To: Your message of "Sat, 16 Jun 2007 19:11:40 +0200." <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> Date: Sat, 16 Jun 2007 16:24:59 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 badra@isima.fr writes: >I will update the draft consequently, or send a separated document for > with NETCONF. Don't make it 'rpc-login', since that implies it's at the layer. Use or something like that. Heck, even would be fine. Also you should specify (if it's not there already) that the client needs a cert the server recognises, so the client isn't throwing a password at a third party. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 16 21:48:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjsl-0007c5-UY for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 21:48:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzjsl-0000uk-Hn for netconf-archive@lists.ietf.org; Sat, 16 Jun 2007 21:48:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzjkP-000Ip5-FR for netconf-data@psg.com; Sun, 17 Jun 2007 01:40:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzjkE-000Inc-01 for netconf@ops.ietf.org; Sun, 17 Jun 2007 01:40:03 +0000 Received: (qmail 83531 invoked from network); 17 Jun 2007 01:39:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2007 01:39:57 -0000 X-YMail-OSG: hjmkj4kVM1n88z1wtzY648Y8dZS0QyyRwDZZ2ZfE9CSGlofJ0TI9XYWPUVioaJ2UNqAb0XCSUPBHy5qV0YINRUSC Message-ID: <467490B1.50005@andybierman.com> Date: Sat, 16 Jun 2007 18:38:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> In-Reply-To: <20070615181423.GC13774@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Juergen Schoenwaelder wrote: > On Fri, Jun 15, 2007 at 06:59:23AM -0700, Andy Bierman wrote: > >> I'm not sure if the WG was ever officially asked to comment >> on the draft by Mohamad Badra called "NETCONF over TLS". >> So I am asking now. >> >> http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt >> >> Please send comments on this draft and the feature itself >> to the WG mailing list. >> >> Are there implementations of this feature (not just this draft)? > > I know that early implementations from INRIA were running over TLS > instead of SSH. They then switched over to SSH after I told them that > TLS is a non-defined transport mapping. Not sure what this means; at > least there were people implementing something like NETCONF over TLS. > >> Should this work be standardized? >> >> If not, should it be published as Informational or Experimental? > > I don't care so much about the political implications of this > question. In practice, I believe a NETCONF over TLS mapping has at > least the same changes of implementation and deployment than some of > the other transport we have put on the standards track and hence I > would vote for a fair treatment of all the transports and then in > three-five years we can decide which ones to declare historic when the > others go for Draft Standard. > It is not political, but rather the level of peer review and consensus. However, a non-WG RFC can be published as Proposed Standard with the consent of the relevant WG, I think. Perhaps if Badra, Juergen, and others get help from the Security area on TLS and Security Considerations, publishing an Informational or Proposed Standard RFC (from the individual submission, with WG approval) would be possible. There are some features waiting in line, like partial locks and access control, and I don't think the priority of new transport mapping work is very high. In 3 - 5 years (or maybe less), the mappings that are not being used will be classified as Historic. Maybe TLS will become the default instead of SSH someday. As long as TLS is implemented in addition to the mandatory SSH mapping, I don't think interoperability is harmed. > /js > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 01:49:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzneA-0005fC-TM for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 01:49:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzndr-0007lF-82 for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 01:49:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HznWv-0006hU-8l for netconf-data@psg.com; Sun, 17 Jun 2007 05:42:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HznWj-0006g1-R6 for netconf@ops.ietf.org; Sun, 17 Jun 2007 05:42:23 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2007 01:42:15 -0400 X-IronPort-AV: i="4.16,430,1175486400"; d="scan'208"; a="27651670:sNHT9774978" 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 Subject: RE: NETCONF over TLS Date: Sun, 17 Jun 2007 07:41:33 +0200 Message-ID: In-Reply-To: <467490B1.50005@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF over TLS Thread-Index: AcewgOt2pWDoBAY7QSalFus4Do1GfQAH1UTg References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <467490B1.50005@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e In-line.=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Sunday, June 17, 2007 4:39 AM > To: Netconf (E-mail) > Subject: Re: NETCONF over TLS >=20 > Juergen Schoenwaelder wrote: > > On Fri, Jun 15, 2007 at 06:59:23AM -0700, Andy Bierman wrote: > >=20 > >> I'm not sure if the WG was ever officially asked to comment on the=20 > >> draft by Mohamad Badra called "NETCONF over TLS". > >> So I am asking now. > >> > >> http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt > >> > >> Please send comments on this draft and the feature itself=20 > to the WG=20 > >> mailing list. > >> > >> Are there implementations of this feature (not just this draft)? > >=20 > > I know that early implementations from INRIA were running over TLS=20 > > instead of SSH. They then switched over to SSH after I told=20 > them that=20 > > TLS is a non-defined transport mapping. Not sure what this=20 > means; at=20 > > least there were people implementing something like NETCONF=20 > over TLS. > >=20 > >> Should this work be standardized? > >> > >> If not, should it be published as Informational or Experimental? > >=20 > > I don't care so much about the political implications of this=20 > > question. In practice, I believe a NETCONF over TLS mapping has at=20 > > least the same changes of implementation and deployment=20 > than some of=20 > > the other transport we have put on the standards track and hence I=20 > > would vote for a fair treatment of all the transports and then in=20 > > three-five years we can decide which ones to declare=20 > historic when the=20 > > others go for Draft Standard. > >=20 >=20 > It is not political, but rather the level of peer review and=20 > consensus. >=20 > However, a non-WG RFC can be published as Proposed Standard=20 > with the consent of the relevant WG, I think. Indeed. This can be done as a AD-sponsored individual submission. Actually this is what Mohamad requested, with the observation that he is targeting Informational RFC status. The process is documented in http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html.=20 >=20 > Perhaps if Badra, Juergen, and others get help from the=20 > Security area on TLS and Security Considerations, publishing=20 > an Informational or Proposed Standard RFC (from the=20 > individual submission, with WG approval) would be possible. This falls mainly on the AD, as you can see in the ION. This discussions is part of my verification about the level of interest and the availability of expert resources, so please everybody express you opinions on this list. My estimation until now is that there is a certain level of interest, but this document needs expert reviews from NETCONF experts and in the security area, so I would like to make sure that resources are available for these reviews.=20 >=20 > There are some features waiting in line, like partial locks=20 > and access control, and I don't think the priority of new=20 > transport mapping work is very high. It would probably be good to discuss this submission also in the nee BOF in Chicago, to see how it rates as level of interest relative to the other NETCONF extension subjects.=20 >=20 > In 3 - 5 years (or maybe less), the mappings that are not=20 > being used will be classified as Historic. Maybe TLS will=20 > become the default instead of SSH someday. As long as TLS is=20 > implemented in addition to the mandatory SSH mapping, I don't=20 > think interoperability is harmed. Yes. Dan >=20 > > /js > >=20 >=20 > Andy >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 06:45:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzsGc-0001fB-3i for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 06:45:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzsGa-0003GR-Pq for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 06:45:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzs8p-000OO3-02 for netconf-data@psg.com; Sun, 17 Jun 2007 10:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzs8e-000ONZ-7C for netconf@ops.ietf.org; Sun, 17 Jun 2007 10:37:49 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2007 12:37:43 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5HAbg8e006151; Sun, 17 Jun 2007 12:37:42 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp301.cisco.com [10.61.65.45]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5HAbcDR017970; Sun, 17 Jun 2007 10:37:38 GMT Message-ID: <46750EF0.7090900@cisco.com> Date: Sun, 17 Jun 2007 12:37:36 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Andy Bierman , "Netconf (E-mail)" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> In-Reply-To: <20070615181423.GC13774@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=389; t=1182076662; x=1182940662; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=dX+ghB/JMwlFp4d9KEfjGI6KO8kKWDDRNbdF9OrkfQ4=; b=ngRRBoyVG+mCEJGTunlqmuIwQmgAAbDgbrVMNDSpup3hKRDR55eWnnGBGZ/3ObLEwLhHidh4 Ud9wKv0ivHVgSIj7a5HWB65pP3mUPH008JhMimFLboTmfci3fbhrF2PH; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Juergen Schoenwaelder wrote: > I know that early implementations from INRIA were running over TLS > instead of SSH. They then switched over to SSH after I told them that > TLS is a non-defined transport mapping. Not sure what this means; at > least there were people implementing something like NETCONF over TLS. > NETCONF/BEEP+TLS gets you there, if this is what people want. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 09:04:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzuQc-0005nB-Aj for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 09:04:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzuQb-00032r-Mz for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 09:04:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzuJh-0006Kk-2Q for netconf-data@psg.com; Sun, 17 Jun 2007 12:57:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzuJV-0006Jx-G4 for netconf@ops.ietf.org; Sun, 17 Jun 2007 12:57:11 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id AB3371B80C3; Sun, 17 Jun 2007 14:57:01 +0200 (CEST) Date: Sun, 17 Jun 2007 14:56:58 +0200 (CEST) Message-Id: <20070617.145658.29449012.mbj@tail-f.com> To: badra@isima.fr Cc: j.schoenwaelder@jacobs-university.de, ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: =?iso-8859-1?Q?=A0NETCONF=A0over=A0TLS?= From: Martin Bjorklund In-Reply-To: <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 badra@isima.fr wrote: > I will update the draft consequently, or send a separated document for > with NETCONF. I think this is crucial for the TLS transport to work for NETCONF. RFC4741 says in section 2.3: NETCONF connections must be authenticated. The transport protocol is responsible for authentication. [...] The authentication process should result in an identity whose permissions are known to the device. I don't see how this requirement is met with the current draft. So, adding a rpc to this document is probably a good idea. But do we want to limit TLS usage to using the method? People are also using some field in the 'subject' of a client certificate to get a user name (or other info) which is then mapped to access rights. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 11:09:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwNl-0004YB-TR for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:09:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwNj-0001Zf-BT for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:09:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzwJL-000EXF-MI for netconf-data@psg.com; Sun, 17 Jun 2007 15:05:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzwJA-000EVm-7X for netconf@ops.ietf.org; Sun, 17 Jun 2007 15:04:58 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 402CB832D8; Sun, 17 Jun 2007 17:04:51 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30334-02; Sun, 17 Jun 2007 17:04:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C3E9832D6; Sun, 17 Jun 2007 17:04:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 054B4295DB2; Sun, 17 Jun 2007 17:04:43 +0200 (CEST) Date: Sun, 17 Jun 2007 17:04:43 +0200 From: Juergen Schoenwaelder To: Eliot Lear Cc: Andy Bierman , "Netconf (E-mail)" Subject: Re: NETCONF over TLS Message-ID: <20070617150443.GB15233@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Eliot Lear , Andy Bierman , "Netconf (E-mail)" References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <46750EF0.7090900@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46750EF0.7090900@cisco.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Sun, Jun 17, 2007 at 12:37:36PM +0200, Eliot Lear wrote: > Juergen Schoenwaelder wrote: >> I know that early implementations from INRIA were running over TLS >> instead of SSH. They then switched over to SSH after I told them that >> TLS is a non-defined transport mapping. Not sure what this means; at >> least there were people implementing something like NETCONF over TLS. > > NETCONF/BEEP+TLS gets you there, if this is what people want. Obviously, the implementors at that time did not want NETCONF/BEEP+TLS nor NETCONF/SOAP+HTTPS+TLS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 11:09:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwNo-0004dX-EC for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:09:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwNo-0001a0-2n for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:09:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzwEP-000ECN-0Z for netconf-data@psg.com; Sun, 17 Jun 2007 14:59:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzwEE-000EBn-8P for netconf@ops.ietf.org; Sun, 17 Jun 2007 14:59:51 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2007 16:59:41 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5HExeSE004774; Sun, 17 Jun 2007 16:59:40 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4416.cisco.com [10.61.81.63]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5HExbDR017232; Sun, 17 Jun 2007 14:59:38 GMT Message-ID: <46754C58.3060603@cisco.com> Date: Sun, 17 Jun 2007 16:59:36 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> In-Reply-To: <46729B3B.9090403@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=472; t=1182092380; x=1182956380; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=BDt1kH9m8sR0GZypKR1ebm+tyrGXaLGNzz7avl7fJJ4=; b=pm9gP+uiGQkiLLf4Dd0HSTK5azzbA9NJ0vDZfmwzo3dH3ErLXbkvfAQmBwRoAhHjKsSLdphx mOy6ZU6fMoUu0N8cIMlH4Wn1kXJZR9/88fipfKAY/3kXfB/RGTzMICfj; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, I think this draft is a mistake. When you add the "simple framing" used in SSH, you end up with something that is only slightly less complex than BEEP but with no libraries, and from a performance perspective requires a content scan. Far better to use BEEP which has a byte count. Hence I do not believe this draft should be published as an experimental document (I disapprove of protocols that are "informational" - makes no sense to me). Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 11:42:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwtQ-00026w-Gu for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:42:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwtO-00088u-60 for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:42:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzwmp-000GRO-PD for netconf-data@psg.com; Sun, 17 Jun 2007 15:35:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzwme-000GOs-P3 for netconf@ops.ietf.org; Sun, 17 Jun 2007 15:35:26 +0000 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id RAA1323194 ; Sun, 17 Jun 2007 17:33:12 +0100 Received: from 86.72.162.197 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 17 Jun 2007 18:36:21 +0200 (CEST) Message-ID: <61783.86.72.162.197.1182098181.squirrel@www.isima.fr> In-Reply-To: <20070617.145658.29449012.mbj@tail-f.com> References: <46729B3B.9090403@andybierman.com><20070615181423.GC13774@elstar.local><63214.86.72.162.197.1182013900.squirrel@www.isima.fr> <20070617.145658.29449012.mbj@tail-f.com> Date: Sun, 17 Jun 2007 18:36:21 +0200 (CEST) Subject: =?utf-8?Q?Re:=C2=A0=EF=BF=BDNETCONF=EF=BF=BDover=EF=BF=BDTLS?= From: badra@isima.fr To: =?utf-8?Q?Martin=C2_Bjorklund=C2?= Cc: badra@isima.fr, =?utf-8?Q?=C2?= , =?utf-8?Q?=C2?= , =?utf-8?Q?=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Dear Martin, > > I think this is crucial for the TLS transport to work for NETCONF. > RFC4741 says in section 2.3: > > NETCONF connections must be authenticated. The transport protocol is > responsible for authentication. > > [...] > > The authentication process should result in an identity whose > permissions are known to the device. > > I don't see how this requirement is met with the current draft. > > So, adding a rpc to this document is probably a good idea. > But do we want to limit TLS usage to using the method? People > are also using some field in the 'subject' of a client certificate to > get a user name (or other info) which is then mapped to access > rights. TLS is always responsible for authentication. Section 3 of the document explain how peers can examine the certificate presented by an entity in order to determine if it meets their expectations and therefore to identify the entity's permissions. The concern is that not all NETCONF peers can have certificates or vendor-certificates to get a user name and therefore to map to the access rights. The alternative is to establish a TLS session to authenticate the TLS server (the NETCONF agent) and then use a NETCONF-specific mechanism () to authenticate the manager. Note that TLS can provide mutual authentication at the transport layer using preshared keys. In this case, may be used for sending more authorization and authentication information. In any case, the document doesn't limit TLS usage to using the method. Best regards. Badra -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 11:57:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzx8H-0008Vb-7y for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:57:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzx8F-00028E-UL for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 11:57:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzx3p-000HVj-72 for netconf-data@psg.com; Sun, 17 Jun 2007 15:53:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Hzx3e-000HV2-FS for netconf@ops.ietf.org; Sun, 17 Jun 2007 15:52:59 +0000 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id RAA520206 ; Sun, 17 Jun 2007 17:50:52 +0100 Received: from 86.72.162.197 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 17 Jun 2007 18:54:02 +0200 (CEST) Message-ID: <61851.86.72.162.197.1182099242.squirrel@www.isima.fr> In-Reply-To: <46754C58.3060603@cisco.com> References: <46729B3B.9090403@andybierman.com> <46754C58.3060603@cisco.com> Date: Sun, 17 Jun 2007 18:54:02 +0200 (CEST) Subject: =?utf-8?Q?Re:=C2=A0NETCONF=C2=A0over=C2=A0TLS?= From: badra@isima.fr To: =?utf-8?Q?Eliot=C2_Lear=C2?= Cc: =?utf-8?Q?Andy=C2_Bierman=C2?= , =?utf-8?Q?=C2_Netconf=C2_=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi Lear, > When you add the "simple framing" used > in SSH, you end up with something that is only slightly less complex > than BEEP but with no libraries, and from a performance perspective > requires a content scan. Far better to use BEEP which has a byte count. I won't make a comparison for the moment between SSH and TLS to defend this latter but IMHO, all the points you listed above are given in a fashion way within NETCONF over TLS: - The document implements the same SSH "simple framing" - The content scan and byte count should be done at the TLS Record layer. Best regards, Badra -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 17 16:28:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I01Mp-0007xG-Qh for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 16:28:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I01Mo-0000zu-Ga for netconf-archive@lists.ietf.org; Sun, 17 Jun 2007 16:28:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I01F9-000BNo-Qa for netconf-data@psg.com; Sun, 17 Jun 2007 20:21:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I01Ey-000BNK-LO for netconf@ops.ietf.org; Sun, 17 Jun 2007 20:20:58 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2007 13:20:52 -0700 X-IronPort-AV: i="4.16,432,1175497200"; d="scan'208"; a="494989650:sNHT48221036" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5HKKp43029787; Sun, 17 Jun 2007 13:20:51 -0700 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4556.cisco.com [10.61.81.203]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5HKKbtV008825; Sun, 17 Jun 2007 20:20:38 GMT Message-ID: <46759772.8010409@cisco.com> Date: Sun, 17 Jun 2007 22:20:02 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: badra@isima.fr CC: =?UTF-8?B?77+9?= , =?UTF-8?B?77+9?= Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <46754C58.3060603@cisco.com> <61851.86.72.162.197.1182099242.squirrel@www.isima.fr> In-Reply-To: <61851.86.72.162.197.1182099242.squirrel@www.isima.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=415; t=1182111651; x=1182975651; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20=20NETCONF=20over=20TLS |Sender:=20; bh=s1iS9LyAQodwmgjZQv8UMMCWUA8oBJ+hjUQwxiHU6PQ=; b=rOFKN7/yTRJBXrHV63dcS8uSsfRR3j+XDOOMwf2ci7AG4YWI9aYOxHRHxLwMvjlVtKc1Syez DocMHrbLjufQ8iEu90CRn/uP81LSLOW0YGxZ/RvbNZVbvIiVraKKvr9c; Authentication-Results: sj-dkim-4; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c badra@isima.fr wrote: > I won't make a comparison for the moment between SSH and TLS to defend > this latter but IMHO, all the points you listed above are given in a > fashion way within NETCONF over TLS: > > - The document implements the same SSH "simple framing" > - The content scan and byte count should be done at the TLS Record layer. > My point is not to compare your draft to SSH but to BEEP. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 03:57:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C71-0004N8-0t for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 03:57:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0C70-0000zu-M1 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 03:57:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ByV-0007UP-GI for netconf-data@psg.com; Mon, 18 Jun 2007 07:48:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ByJ-0007Tq-Ip for netconf@ops.ietf.org; Mon, 18 Jun 2007 07:48:29 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJT00M0MN0KQ4@szxga04-in.huawei.com> for netconf@ops.ietf.org; Mon, 18 Jun 2007 15:48:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJT00FH4N0JP9@szxga04-in.huawei.com> for netconf@ops.ietf.org; Mon, 18 Jun 2007 15:48:20 +0800 (CST) Received: from m03573B ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJT00GK5N0FDA@szxml04-in.huawei.com> for netconf@ops.ietf.org; Mon, 18 Jun 2007 15:48:19 +0800 (CST) Date: Mon, 18 Jun 2007 15:48:15 +0800 From: Ma Yuzhi Subject: RE: ??NETCONF?over?TLS In-reply-to: <61783.86.72.162.197.1182098181.squirrel@www.isima.fr> To: badra@isima.fr, netconf@ops.ietf.org Message-id: <00f401c7b17d$07684210$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acew9oHUnt1o41x6QrGzfw6Bu0vRdgAgualg Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi, > > So, adding a rpc to this document is probably a good idea. > > But do we want to limit TLS usage to using the > method? People > > are also using some field in the 'subject' of a client > certificate to > > get a user name (or other info) which is then mapped to > access rights. > The concern is that not all NETCONF peers can have > certificates or vendor-certificates to get a user name and > therefore to map to the access rights. The alternative is to > establish a TLS session to authenticate the TLS server (the > NETCONF agent) and then use a NETCONF-specific mechanism > () to authenticate the manager. > > Note that TLS can provide mutual authentication at the > transport layer using preshared keys. In this case, > may be used for sending more authorization > and authentication information. > so, I personally would prefer we use as a new operation rather than rpc. The maybe provide authentication function via third party mechanism. Yuzhi > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of badra@isima.fr > Sent: Monday, June 18, 2007 12:36 AM > Subject: Re:??NETCONF?over?TLS > > Dear Martin, > > > > > I think this is crucial for the TLS transport to work for NETCONF. > > RFC4741 says in section 2.3: > > > > NETCONF connections must be authenticated. The > transport protocol is > > responsible for authentication. > > > > [...] > > > > The authentication process should result in an identity whose > > permissions are known to the device. > > > > I don't see how this requirement is met with the current draft. > > > > So, adding a rpc to this document is probably a good idea. > > But do we want to limit TLS usage to using the > method? People > > are also using some field in the 'subject' of a client > certificate to > > get a user name (or other info) which is then mapped to > access rights. > > TLS is always responsible for authentication. Section 3 of > the document explain how peers can examine the certificate > presented by an entity in order to determine if it meets > their expectations and therefore to identify the entity's permissions. > > The concern is that not all NETCONF peers can have > certificates or vendor-certificates to get a user name and > therefore to map to the access rights. The alternative is to > establish a TLS session to authenticate the TLS server (the > NETCONF agent) and then use a NETCONF-specific mechanism > () to authenticate the manager. > > Note that TLS can provide mutual authentication at the > transport layer using preshared keys. In this case, > may be used for sending more authorization > and authentication information. > > In any case, the document doesn't limit TLS usage to using > the method. > > Best regards. > Badra > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org > with the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 07:53:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0FnO-0001zR-Rg for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 07:53:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0FnH-0005F9-MW for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 07:53:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Fg0-000OTd-0l for netconf-data@psg.com; Mon, 18 Jun 2007 11:45:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Ffo-000OSl-9x for netconf@ops.ietf.org; Mon, 18 Jun 2007 11:45:38 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id NAA409736 ; Mon, 18 Jun 2007 13:43:24 +0100 Message-ID: <46767037.9080803@isima.fr> Date: Mon, 18 Jun 2007 13:44:55 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ma Yuzhi CC: netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <00f401c7b17d$07684210$350c6f0a@china.huawei.com> In-Reply-To: <00f401c7b17d$07684210$350c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Ma Yuzhi a écrit : > so, I personally would prefer we use as a new operation > rather than rpc. > The maybe provide authentication function via third party > mechanism. > > Yuzhi Hi Yuzhi, Let's start with the following. Comments are very welcome.. (The peer acting as NETCONF manager acts also as TLS client.) Upon the successful run of protocol's standard authentication mechanism (e.g. TLS), the agent may submit an authentication request to have more authentication and authorization information from the manager. The agent begins the authentication process by emitting the tag element within an tag element: Username: Password: To provide the password along with the username, the manager emits the following tag sequence: username password The and tag elements specify respectively the manager's password and username. The maybe provide authentication function via third party mechanism. Their tag elements contains the username and the password that the application provided to an authentication utility such as RADIUS. After receiving the manager's username and password, the agent emits the tag element to indicate whether the authentication attempt is successful. The agent (or the authentication utility) checks its database for a match. If a match is found, the authentication attempt succeeds and the agent emits the following tag sequence: success If a match is not found or the password is not correct or the tag element is malformed, the authentication attempt fails and the agent emits the following tag sequence: fail error-message The error-message string in the tag element explains why the authentication attempt failed. The agent remits the authentication request up to two more times before rejecting the authentication attempt and closing the connection. The agent remits also the tag element when the tag elements emitted by the manager does not enclose a tag element or when the password enclosed in a tag element is incorrect (in the latter case, the agent also emits an tag element enclosing child tag elements that indicate the password is incorrect). P.S. The defined here is heavily based on work done by Juniper and borrows text from the reference posted by Phil Shafer on the mailing list: https://www.juniper.net/techpubs/software/junos/junos82/junoscript82-guide/download/junoscript82-guide.pdf Best regards, Badra -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 07:53:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0FnP-00020E-9c for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 07:53:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0FnJ-0005FN-1y for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 07:53:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Fhg-000Oaz-ED for netconf-data@psg.com; Mon, 18 Jun 2007 11:47:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0FhV-000OZz-Eu for netconf@ops.ietf.org; Mon, 18 Jun 2007 11:47:23 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l5IBkX8b020894; Mon, 18 Jun 2007 13:46:33 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.1+Sun/8.14.1/Submit) id l5IBkWD8020893; Mon, 18 Jun 2007 13:46:32 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f To: Phil Shafer Cc: badra@isima.fr, j.schoenwaelder@jacobs-university.de, =?utf-8?B?QW5kecIgQmllcm1hbsI=?= , =?utf-8?B?wiBOZXRjb25mwiDC?= Subject: Re: =?utf-8?B?wqBORVRDT05GwqBvdmVywqBUTFM=?= X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <200706162025.l5GKOxjw055055@idle.juniper.net> (Phil Shafer's message of "Sat\, 16 Jun 2007 16\:24\:59 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (usg-unix-v) References: <200706162025.l5GKOxjw055055@idle.juniper.net> Date: Mon, 18 Jun 2007 13:46:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Phil Shafer writes: > Also you should specify (if it's not there already) that the > client needs a cert the server recognises, so the client isn't > throwing a password at a third party. I think you mean: "...the SERVER needs a cert the CLIENT recognises, so the client isn't throwing a password at a third party." If the client had a cert that the server recognises, that might be useful, but for a different reason: The server could use that cert to derive user identity or other attributes that it could use to authorise access to the NETCONF agent (login) and/or to individual operations. Then you would not need a NETCONF operation at all. NETCONF could then use TLS like it can use SSH or BEEP (it's a little less clear with SOAP); namely as a provider of user authentication/identity. This is also what Martin hinted at in message <20070617.145658.29449012.mbj@tail-f.com>, I think. -- Simon. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 08:14:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0G7v-0001y7-9k for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 08:14:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0G7t-0003eA-PN for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 08:14:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0G2X-0000Hr-8o for netconf-data@psg.com; Mon, 18 Jun 2007 12:09:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0G2M-0000Gg-5b for netconf@ops.ietf.org; Mon, 18 Jun 2007 12:08:55 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id OAA1306820 ; Mon, 18 Jun 2007 14:06:56 +0100 Message-ID: <467675BB.3000105@isima.fr> Date: Mon, 18 Jun 2007 14:08:27 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Simon Leinen CC: netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706162025.l5GKOxjw055055@idle.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Simon Leinen a écrit : > Phil Shafer writes: >> Also you should specify (if it's not there already) that the >> client needs a cert the server recognises, so the client isn't >> throwing a password at a third party. > > I think you mean: "...the SERVER needs a cert the CLIENT recognises, > so the client isn't throwing a password at a third party." > > If the client had a cert that the server recognises, that might be > useful, but for a different reason: The server could use that cert to > derive user identity or other attributes that it could use to > authorise access to the NETCONF agent (login) and/or to individual > operations. Then you would not need a NETCONF operation at > all. NETCONF could then use TLS like it can use SSH or BEEP (it's a > little less clear with SOAP); namely as a provider of user > authentication/identity. > > This is also what Martin hinted at in message > <20070617.145658.29449012.mbj@tail-f.com>, I think. Hi Simon, That's right, but if we want alike JUNOS mechanism or an authentication function via third parties, I think we will need to use the . This is in order to allow to the server to request the client's password (the manager). With regard to my last mail, the server will continue the authentication process by emitting the tag element within an tag element: Password: in which the client replies with: password Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 09:55:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Hhl-0002vj-TP for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 09:55:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Hhk-0003zq-7c for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 09:55:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0HaS-0006tN-D1 for netconf-data@psg.com; Mon, 18 Jun 2007 13:48:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0HaH-0006sU-3F for netconf@ops.ietf.org; Mon, 18 Jun 2007 13:48:02 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id D27571B80C3; Mon, 18 Jun 2007 15:47:53 +0200 (CEST) Date: Mon, 18 Jun 2007 15:47:33 +0200 (CEST) Message-Id: <20070618.154733.118574498.mbj@tail-f.com> To: badra@isima.fr Cc: myz@huawei.com, netconf@ops.ietf.org Subject: Re: NETCONF over TLS From: Martin Bjorklund In-Reply-To: <46767037.9080803@isima.fr> References: <00f401c7b17d$07684210$350c6f0a@china.huawei.com> <46767037.9080803@isima.fr> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi, Mohamad Badra wrote: > Let's start with the following. Comments are very welcome.. > > (The peer acting as NETCONF manager acts also as TLS client.) > > Upon the successful run of protocol's standard authentication mechanism > (e.g. TLS), the agent may submit an authentication request to have more > authentication and authorization information from the manager. The agent > begins the authentication process by emitting the tag > element within an tag element: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > Username: > Password: > I don't get this. Is this the first message the agent sends after a ? A spurious ?? IMO, the agent has to decide if more authentication is needed or not. For example: manager agent ------- ----- <---------> ----------> <---------- authentication-needed -----> and then the agent sends the message you wrote: Username: Password: etc. Maybe the agent can signal that authentication is needed in the hello message, by including the new capability for 'request-login'. Then the manager can do directly, if needed. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 10:08:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Htt-0002nM-H6 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:08:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Hts-0000k0-6s for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:08:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Hkr-0007b8-GF for netconf-data@psg.com; Mon, 18 Jun 2007 13:58:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Hkg-0007ac-LR for netconf@ops.ietf.org; Mon, 18 Jun 2007 13:58:48 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 15:58:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IDwZcl009930; Mon, 18 Jun 2007 15:58:35 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4497.cisco.com [10.61.81.144]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5IDwQDR001889; Mon, 18 Jun 2007 13:58:32 GMT Message-ID: <46768F81.5050405@cisco.com> Date: Mon, 18 Jun 2007 15:58:25 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Mohamad Badra CC: Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706162025.l5GKOxjw055055@idle.juniper.net> <467675BB.3000105@isima.fr> In-Reply-To: <467675BB.3000105@isima.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=624; t=1182175115; x=1183039115; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=nQEgm03ZjVIkHmT62I0fiQxiQFWJ4VB0jpLaqhAlCy4=; b=w6NyjSFfZUbOoB7yz1pUMsa44bI8w3tUw5ViRkaUoYL5Dc4r/uTe1s4RqTKciDeIDp2/pTS8 KKMxbT/3PdFzcCTvC3H0/A5LdVzccgI6yI6AUhquI6cVm4DOgAo5UYL4; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Mohamad Badra wrote: > That's right, but if we want alike JUNOS mechanism or an > authentication function via third parties, I think we will need to use > the . This is in order to allow to the server to > request the client's password (the manager). With regard to my last > mail, the server will continue the authentication process by emitting > the tag element within an tag element: First, you re-invented the TLS portion of BEEP, and now you are reinventing SASL, and you are going to do it far less functionally. Have you tried what's there already? Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 10:28:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IDG-0004J7-AZ for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:28:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IDF-0006LU-18 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:28:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0I59-0009An-TB for netconf-data@psg.com; Mon, 18 Jun 2007 14:19:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0I4z-0009AN-7k for netconf@ops.ietf.org; Mon, 18 Jun 2007 14:19:46 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Jun 2007 07:19:41 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5IEJdJ47714; Mon, 18 Jun 2007 07:19:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5IES6jw059162; Mon, 18 Jun 2007 10:28:06 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706181428.l5IES6jw059162@idle.juniper.net> To: Simon Leinen cc: badra@isima.fr, j.schoenwaelder@jacobs-university.de, =?utf-8?B?QW5kecIgQmllcm1hbsI=?= , =?utf-8?B?wiBOZXRjb25mwiDC?= Subject: Re: =?utf-8?B?wqBORVRDT05GwqBvdmVywqBUTFM=?= In-Reply-To: Your message of "Mon, 18 Jun 2007 13:46:32 +0200." Date: Mon, 18 Jun 2007 10:28:06 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Simon Leinen writes: >I think you mean: "...the SERVER needs a cert the CLIENT recognises, >so the client isn't throwing a password at a third party." Yup, my bad. >If the client had a cert that the server recognises, that might be >useful, but for a different reason: The server could use that cert to >derive user identity or other attributes that it could use to >authorise access to the NETCONF agent (login) and/or to individual >operations. Then you would not need a NETCONF operation at >all. NETCONF could then use TLS like it can use SSH or BEEP (it's a >little less clear with SOAP); namely as a provider of user >authentication/identity. Yup, this is the part (user certs) that we didn't do in JUNOS. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 10:28:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IDr-0004Mg-Me for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:28:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IDq-0006UD-Cz for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 10:28:51 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0I7Y-0009Mb-8g for netconf-data@psg.com; Mon, 18 Jun 2007 14:22:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0I7N-0009L1-96 for netconf@ops.ietf.org; Mon, 18 Jun 2007 14:22:14 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id QAA409658 ; Mon, 18 Jun 2007 16:20:12 +0100 Message-ID: <467694F7.6060705@isima.fr> Date: Mon, 18 Jun 2007 16:21:43 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: myz@huawei.com, netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <00f401c7b17d$07684210$350c6f0a@china.huawei.com> <46767037.9080803@isima.fr> <20070618.154733.118574498.mbj@tail-f.com> In-Reply-To: <20070618.154733.118574498.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Martin Bjorklund a écrit : > I don't get this. Is this the first message the agent sends after a > ? A spurious ?? This must be sent after the , but not necessary the first message. > Maybe the agent can signal that authentication is needed in the hello > message, by including the new capability for 'request-login'. Then > the manager can do directly, if needed. > Agree. > /martin Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 11:27:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J8f-00052t-GB for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 11:27:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0J8d-0004Cb-5x for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 11:27:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0J0e-000DKd-G3 for netconf-data@psg.com; Mon, 18 Jun 2007 15:19:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0J0T-000DJH-Hn for netconf@ops.ietf.org; Mon, 18 Jun 2007 15:19:11 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id RAA1015812 ; Mon, 18 Jun 2007 17:17:06 +0100 Message-ID: <4676A24D.5040105@isima.fr> Date: Mon, 18 Jun 2007 17:18:37 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear CC: Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706162025.l5GKOxjw055055@idle.juniper.net> <467675BB.3000105@isima.fr> <46768F81.5050405@cisco.com> In-Reply-To: <46768F81.5050405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Eliot Lear a écrit : > and you are going to do it far less functionally. Hi Eliot, I don't think I re-invent anything, especially the "TLS profile for BEEP". I proposed to adopt the of JUNOS because I estimated that people wish a NETCONF-specific authentication mechanism. Maybe I misestimated. Again, I don't want to compare existing solutions to TLS but I think all existing security protocols for NETCONF, excepting SSH, rely on TLS and require one or more sub-protocols to be implemented. What the document does propose is simplifying the TLS's use. As to , almost all existing applications have their specific authentication and/or authorization mechanisms. Between, could you please tell what "far less functionally" does mean? > Eliot Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 11:36:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JHf-0006eU-Gs for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 11:36:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0JHe-0005ex-5Y for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 11:36:51 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0JBZ-000E8B-4P for netconf-data@psg.com; Mon, 18 Jun 2007 15:30:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0JBO-000E6J-Ce for netconf@ops.ietf.org; Mon, 18 Jun 2007 15:30:27 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 17:30:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IFULSZ009100; Mon, 18 Jun 2007 17:30:21 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4497.cisco.com [10.61.81.144]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5IFUIDR004089; Mon, 18 Jun 2007 15:30:19 GMT Message-ID: <4676A509.5000008@cisco.com> Date: Mon, 18 Jun 2007 17:30:17 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Mohamad Badra CC: Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706162025.l5GKOxjw055055@idle.juniper.net> <467675BB.3000105@isima.fr> <46768F81.5050405@cisco.com> <4676A24D.5040105@isima.fr> In-Reply-To: <4676A24D.5040105@isima.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=496; t=1182180621; x=1183044621; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=fSNnkECY0/4F63/r3P3KGI+Ya1grVRU+nXJqtwyLxNo=; b=G/18EFDMpWhThLzDhvx5KFWQ4HnnTlWszRwejoHQQ7TG0v8GEF25TrgX6jz0sqSAObRU0BTB 0fhO1rnBTbcp7NErOxbsKRtq92K5tLyK5TqjMxzQFdAEwAgphAKp05SX; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Mohamad Badra wrote: > Between, could you please tell what "far less functionally" does mean? The whole point of SASL is to provide for multiple profiles so that if you want to use the GSSAPI or PLAIN or OTP or something else, you can do so. In fact this is a battle we keep fighting *and* losing in network management. Shall we some day plan to have an ISMS equivalent for netconf? I surely hope not. And of course, you get all of this for free with the BEEP spec. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 12:54:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KV4-0002Np-J2 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 12:54:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KV2-0005f7-H3 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 12:54:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0KNK-000LaJ-LL for netconf-data@psg.com; Mon, 18 Jun 2007 16:46:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.91] (helo=smtp118.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0KN9-000LZ7-Iu for netconf@ops.ietf.org; Mon, 18 Jun 2007 16:46:41 +0000 Received: (qmail 30278 invoked from network); 18 Jun 2007 16:46:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2007 16:46:34 -0000 X-YMail-OSG: 7cqM2LQVM1k_pJmvfzQfJ9mZ4JSPKGhpaIFHnGutabvsdrnR Message-ID: <4676B6AD.4060800@andybierman.com> Date: Mon, 18 Jun 2007 09:45:33 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear CC: Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706162025.l5GKOxjw055055@idle.juniper.net> <467675BB.3000105@isima.fr> <46768F81.5050405@cisco.com> <4676A24D.5040105@isima.fr> <4676A509.5000008@cisco.com> In-Reply-To: <4676A509.5000008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Eliot Lear wrote: > Mohamad Badra wrote: >> Between, could you please tell what "far less functionally" does mean? > > > The whole point of SASL is to provide for multiple profiles so that if > you want to use the GSSAPI or PLAIN or OTP or something else, you can do > so. In fact this is a battle we keep fighting *and* losing in network > management. Shall we some day plan to have an ISMS equivalent for > netconf? I surely hope not. > > And of course, you get all of this for free with the BEEP spec. > I have heard comments From Juergen that there are several foo-over-TLS drafts out there, and perhaps one specification for NM-over-TLS might be better. I heard concerns about 'vertical silos' from Dave H along the same lines. I also respect Eliot's concerns about reinventing things. The details are always messier than the "idea". So, with this new 'special' RPC (that creates a layer violation in itself) the agent needs to send 'operation-failed' errors for any other RPC received before this one? A special mode is needed in the RPC handler, based on, and coupled to, the transport protocol used to establish the session -- just to support this special RPC method. Yuch. > Eliot Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 14:30:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Lzu-0001oS-QQ for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:30:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Lzu-0000s4-HD for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:30:42 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0Ltb-0002fy-Br for netconf-data@psg.com; Mon, 18 Jun 2007 18:24:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0LtQ-0002eb-Nj for netconf@ops.ietf.org; Mon, 18 Jun 2007 18:24:05 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Jun 2007 11:24:00 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5IINwJ12799; Mon, 18 Jun 2007 11:23:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5IIWPjw060376; Mon, 18 Jun 2007 14:32:25 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706181832.l5IIWPjw060376@idle.juniper.net> To: Andy Bierman cc: Eliot Lear , Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS In-Reply-To: Your message of "Mon, 18 Jun 2007 09:45:33 PDT." <4676B6AD.4060800@andybierman.com> Date: Mon, 18 Jun 2007 14:32:25 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Andy Bierman writes: >So, with this new 'special' RPC (that creates >a layer violation in itself) the agent needs to send 'operation-failed' >errors for any other RPC received before this one? A special mode is needed >in the RPC handler, based on, and coupled to, the transport protocol >used to establish the session -- just to support this special RPC method. The rules to handle this were pretty simple: - The RPC could only be performed if the session wasn't authenicated. - No other RPCs could be performed if the session wasn't authenicated - The transport protocol can authenticate the session (internally) So over ssh, the session is authenticated by the transport protocol, which calls a function to pass this information up to the netconf layer. Over ssl/tls, the session starts with no authentication, leaving the RPC as the only valid RPC. Anything else is an error. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 14:53:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MLe-0005sP-Jn for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:53:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0MLc-0007n7-8z for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:53:10 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0MGC-0004Xj-Km for netconf-data@psg.com; Mon, 18 Jun 2007 18:47:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=unavailable version=3.1.8 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0MFp-0004VA-77; Mon, 18 Jun 2007 18:47:17 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-outbound.avaya.com with ESMTP; 18 Jun 2007 14:47:07 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="30814505:sNHT6742104" 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 Subject: Submission cut-off dates before Chicago Date: Mon, 18 Jun 2007 20:46:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submission cut-off dates before Chicago Thread-Index: Acex2PmEtxbDklB8TrC3YaXjv/x7Yw== From: "Romascanu, Dan (Dan)" To: , , "Netconf (E-mail)" , , , , , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Working Group and BOF Chairs and Contributors, Please note the submission dates for Internet-Drafts before Chicago.=20 July 2, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 UTC/GMT) July 9, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) Dan =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 14:58:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MR6-0007Jc-W0 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:58:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0MR5-0001FH-IF for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 14:58:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0MKG-0004wW-EX for netconf-data@psg.com; Mon, 18 Jun 2007 18:51:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0MK5-0004vr-It for netconf@ops.ietf.org; Mon, 18 Jun 2007 18:51:39 +0000 Received: (qmail 83705 invoked from network); 18 Jun 2007 18:51:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2007 18:51:33 -0000 X-YMail-OSG: 1RMnem0VM1kGSRiq5Mj.2hJB9BfvEsdY_.nKU4sl32p02EtL Message-ID: <4676D3F7.1040606@andybierman.com> Date: Mon, 18 Jun 2007 11:50:31 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: Eliot Lear , Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706181832.l5IIWPjw060376@idle.juniper.net> In-Reply-To: <200706181832.l5IIWPjw060376@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Phil Shafer wrote: > Andy Bierman writes: >> So, with this new 'special' RPC (that creates >> a layer violation in itself) the agent needs to send 'operation-failed' >> errors for any other RPC received before this one? A special mode is needed >> in the RPC handler, based on, and coupled to, the transport protocol >> used to establish the session -- just to support this special RPC method. > > The rules to handle this were pretty simple: > > - The RPC could only be performed if the session wasn't > authenicated. > - No other RPCs could be performed if the session wasn't authenicated > - The transport protocol can authenticate the session (internally) > > So over ssh, the session is authenticated by the transport protocol, > which calls a function to pass this information up to the netconf layer. > > Over ssl/tls, the session starts with no authentication, leaving the > RPC as the only valid RPC. Anything else is an error. > IMO, this should be handled with a different top-level element than , outside the scope of the NETCONF protocol. That way, no special RPC code is needed at all. Only sessions that have been properly authenticated, and messages are okay, should be allowed to use methods. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 15:45:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NAY-0003mE-OJ for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 15:45:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NAV-0008HQ-EN for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 15:45:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0N4X-0008q0-4r for netconf-data@psg.com; Mon, 18 Jun 2007 19:39:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0N4M-0008pJ-Gj for netconf@ops.ietf.org; Mon, 18 Jun 2007 19:39:27 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Jun 2007 12:39:21 -0700 X-IronPort-AV: i="4.16,435,1175497200"; d="scan'208"; a="21065818:sNHT27945500" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5IJdIJ34023; Mon, 18 Jun 2007 12:39:18 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5IJlhjw060784; Mon, 18 Jun 2007 15:47:43 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706181947.l5IJlhjw060784@idle.juniper.net> To: Andy Bierman cc: Eliot Lear , Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS In-Reply-To: Your message of "Mon, 18 Jun 2007 11:50:31 PDT." <4676D3F7.1040606@andybierman.com> Date: Mon, 18 Jun 2007 15:47:43 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Andy Bierman writes: >IMO, this should be handled with a different top-level element >than , outside the scope of the NETCONF protocol. So is another scenario where the generic RPC mechanism we defined in NETCONF can't be used? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 16:04:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NSO-0007ZV-Lj for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:04:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NSN-0002Ap-AM for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:04:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0NLo-000A8a-4H for netconf-data@psg.com; Mon, 18 Jun 2007 19:57:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0NLd-000A7s-CY for netconf@ops.ietf.org; Mon, 18 Jun 2007 19:57:18 +0000 Received: (qmail 25085 invoked from network); 18 Jun 2007 19:57:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2007 19:57:12 -0000 X-YMail-OSG: iqQ9IIQVM1kd5mZOFOtihcNViOxCl8d0Vl3O2MM7qhoLagXz Message-ID: <4676E35B.60602@andybierman.com> Date: Mon, 18 Jun 2007 12:56:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: Eliot Lear , Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706181947.l5IJlhjw060784@idle.juniper.net> In-Reply-To: <200706181947.l5IJlhjw060784@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Phil Shafer wrote: > Andy Bierman writes: >> IMO, this should be handled with a different top-level element >> than , outside the scope of the NETCONF protocol. > > So is another scenario where the generic RPC mechanism > we defined in NETCONF can't be used? > It is a matter of SHOULD be used rather than CAN be used. IMO the transport details should be taken care of before the NETCONF session mechanisms (rpc, rpc-reply, notification) are used. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 16:09:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NXN-00021l-SC for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:09:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NXM-0003we-HZ for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:09:21 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0NSE-000AfW-9U for netconf-data@psg.com; Mon, 18 Jun 2007 20:04:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.91] (helo=smtp118.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0NRz-000AeZ-HM for netconf@ops.ietf.org; Mon, 18 Jun 2007 20:03:55 +0000 Received: (qmail 69294 invoked from network); 18 Jun 2007 20:03:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2007 20:03:46 -0000 X-YMail-OSG: pDTdDe8VM1nhMqifSkuTkPvGJmPAeTfsBaqamGteKddJlEUy Message-ID: <4676E4E5.5030600@andybierman.com> Date: Mon, 18 Jun 2007 13:02:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: Eliot Lear , Mohamad Badra , Simon Leinen , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706181947.l5IJlhjw060784@idle.juniper.net> In-Reply-To: <200706181947.l5IJlhjw060784@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Phil Shafer wrote: > Andy Bierman writes: >> IMO, this should be handled with a different top-level element >> than , outside the scope of the NETCONF protocol. > > So is another scenario where the generic RPC mechanism > we defined in NETCONF can't be used? > My interpretation of the text in RFC 4741, sec. 2.2 and 2.3 is that these transport services must be provided to the NETCONF layer (meaning in this case), and implies that the NETCONF layer can assume that these services are established before a NETCONF session is used. IMO, using the layer to establish the session is not supported, or a good idea. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 16:52:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OCr-000151-L7 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:52:13 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0OCq-0002Pc-4u for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 16:52:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0O6P-000DWe-6S for netconf-data@psg.com; Mon, 18 Jun 2007 20:45:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0O6C-000DUZ-Mj for netconf@ops.ietf.org; Mon, 18 Jun 2007 20:45:26 +0000 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id WAA1282280 ; Mon, 18 Jun 2007 22:43:04 +0100 Received: from 86.72.162.197 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 18 Jun 2007 23:46:10 +0200 (CEST) Message-ID: <61868.86.72.162.197.1182203170.squirrel@www.isima.fr> In-Reply-To: <4676E4E5.5030600@andybierman.com> References: <200706181947.l5IJlhjw060784@idle.juniper.net> <4676E4E5.5030600@andybierman.com> Date: Mon, 18 Jun 2007 23:46:10 +0200 (CEST) Subject: =?utf-8?Q?Re:=C2=A0NETCONF=C2=A0over=C2=A0TLS?= From: badra@isima.fr To: =?utf-8?Q?Andy=C2_Bierman=C2?= Cc: =?utf-8?Q?Phil=C2_Shafer=C2?= , =?utf-8?Q?=C2_Eliot=C2_Lear=C2?= , =?utf-8?Q?=C2_Mohamad=C2_Badra=C2?= , =?utf-8?Q?=C2_Simon=C2_Leinen=C2?= , =?utf-8?Q?=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 > Phil Shafer wrote: >> Andy Bierman writes: >>> IMO, this should be handled with a different top-level element >>> than , outside the scope of the NETCONF protocol. >> >> So is another scenario where the generic RPC mechanism >> we defined in NETCONF can't be used? >> > > My interpretation of the text in RFC 4741, sec. 2.2 and 2.3 > is that these transport services must be provided to the NETCONF layer > (meaning in this case), and implies that the NETCONF layer > can assume that these services are established before a NETCONF > session is used. IMO, using the layer to establish the session > is not supported, or a good idea. Dear Andy, In this case, the mutual authentication must be then established by the transport layer. Currently, TLS specifies several authentication methods using namely certificates, preshared keys, and tokens. The password authentication is also possible by using some works in progress: Password Ciphersuites for TLS, EAP (e.g. EAP-TTLSv0), etc. Best regards, Badra -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 17:35:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ot4-0008CL-CC for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 17:35:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ot3-0004gv-7y for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 17:35:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0OjL-000GSE-Md for netconf-data@psg.com; Mon, 18 Jun 2007 21:25:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [63.240.77.84] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0OjA-000GQX-KT for netconf@ops.ietf.org; Mon, 18 Jun 2007 21:25:42 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007061821203401400l8ro2e>; Mon, 18 Jun 2007 21:20:34 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Netconf \(E-mail\)'" References: <46729B3B.9090403@andybierman.com> Subject: RE: NETCONF over TLS Date: Mon, 18 Jun 2007 17:20:17 -0400 Message-ID: <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46729B3B.9090403@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcevV7UtE5RMMjVJS/WtovDTnVB4WgCiiFLw Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi, BCP72 identifies TLS as the transport security mechanism of choice when traffic is over TCP. SSH is recommended for remote login security, for providing channel-level security directly in the application. Netconf is designed to do "network configuration" as a replacement/supplement to the CLI running over a remote login session. But when netconf starts to move into notifications and into monitoring, then I think the argument for remote login gets weaker. If netconf is meant for "network configuration", i.e., configuring all types of nodes in the network, then there are some questions to ask: 1) key distribution is important; do more network nodes already support TLS (and thus have certificates already distributed) or already support SSH (and already have SSH-related credentials distributed? 2) Will netconf provide application-level security beyond what the secure transport provides, such as data access controls? If so, will this be easier using TLS or SSH? What attributes need to be passed up from the transport security to the application to provide these extra services? 3) Which is easier to integrate with AAA protocols, such as RADIUS and Diameter? 4) and most important, what would the operators use if both SSH and TLS were available? Badra's draft is similar to RFC2818, the informational document for HTTPS. The Syslog WG has developed a draft for a TLS-based secure transport, as well, with some differences from RFC2818 based on new recommendations for TLS processing. Badra has had input from Juergen S, Miao Fuyo (author of the syslog/tls draft), and myself. The syslog/tls document has required some updates following security reviews, and Badra's draft may require some updates as well, but I think the draft will probably pass security review fairly easily. I would recommend including a section that describes the threats addressed by the proposal, and how those threats are mitigated. My recommendation is to ask Badra to publish the draft as experimental, and ask Badra to find other people willing to implement Netconf/TLS as part of the experiment. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Friday, June 15, 2007 9:59 AM > To: Netconf (E-mail) > Subject: NETCONF over TLS > > Hi, > > I'm not sure if the WG was ever officially asked to comment > on the draft by Mohamad Badra called "NETCONF over TLS". > So I am asking now. > > http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt > > Please send comments on this draft and the feature itself > to the WG mailing list. > > Are there implementations of this feature (not just this draft)? > > Should this work be standardized? > > If not, should it be published as Informational or Experimental? > > thanks, > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 18 19:05:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QII-0004DL-0Y for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 19:05:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0QIH-0002aL-F7 for netconf-archive@lists.ietf.org; Mon, 18 Jun 2007 19:05:57 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0QCM-0001CP-Ly for netconf-data@psg.com; Mon, 18 Jun 2007 22:59:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0QCB-0001By-1W for netconf@ops.ietf.org; Mon, 18 Jun 2007 22:59:45 +0000 Received: (qmail 98987 invoked from network); 18 Jun 2007 22:59:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2007 22:59:38 -0000 X-YMail-OSG: 9jXL_lUVM1mygCUboNFGqc2pmUgJv48fh_Ta9DgvuS.eVc8n Message-ID: <46770E1C.2080008@andybierman.com> Date: Mon, 18 Jun 2007 15:58:36 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: badra@isima.fr CC: =?UTF-8?B?77+9?= , =?UTF-8?B?77+9?= , =?UTF-8?B?77+9?= , netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <200706181947.l5IJlhjw060784@idle.juniper.net> <4676E4E5.5030600@andybierman.com> <61868.86.72.162.197.1182203170.squirrel@www.isima.fr> In-Reply-To: <61868.86.72.162.197.1182203170.squirrel@www.isima.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b badra@isima.fr wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> IMO, this should be handled with a different top-level element >>>> than , outside the scope of the NETCONF protocol. >>> So is another scenario where the generic RPC mechanism >>> we defined in NETCONF can't be used? >>> >> My interpretation of the text in RFC 4741, sec. 2.2 and 2.3 >> is that these transport services must be provided to the NETCONF layer >> (meaning in this case), and implies that the NETCONF layer >> can assume that these services are established before a NETCONF >> session is used. IMO, using the layer to establish the session >> is not supported, or a good idea. > > Dear Andy, > > In this case, the mutual authentication must be then established by the > transport layer. Currently, TLS specifies several authentication methods > using namely certificates, preshared keys, and tokens. The password > authentication is also possible by using some works in progress: Password > Ciphersuites for TLS, EAP (e.g. EAP-TTLSv0), etc. > Whatever the details, they need to be handled outside of the NETCONF session mechanisms. Translation: Use some sort of transaction that is finished before the session is deemed ready to receive PDUs. (My only objection is to the usage). > Best regards, > Badra > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 05:08:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Zhe-0001wn-00 for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 05:08:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Zhc-0000nu-Eo for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 05:08:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ZcM-000GF2-MX for netconf-data@psg.com; Tue, 19 Jun 2007 09:03:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ZcB-000GE1-Oa for netconf@ops.ietf.org; Tue, 19 Jun 2007 09:03:13 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5368C2049E; Tue, 19 Jun 2007 11:03:05 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-c8-46779bc9e725 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40EEB204DA; Tue, 19 Jun 2007 11:03:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:03:04 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:03:04 +0200 Message-ID: <46779BC8.9070505@ericsson.com> Date: Tue, 19 Jun 2007 11:03:04 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: badra@isima.fr CC: =?UTF-8?B?77+9?= Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> In-Reply-To: <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 09:03:04.0836 (UTC) FILETIME=[A5932440:01C7B250] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Hello, Why do you feel we need a new transport mapping? What would that give us, why is it better then SSH and BEEP? You describe in your document what you intend to do, but please motivate us by stating why is this a good idea? regards Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 05:11:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Zk3-0008Qj-7X for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 05:11:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Zk2-0002Qb-MC for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 05:11:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ZZa-000G5L-HH for netconf-data@psg.com; Tue, 19 Jun 2007 09:00:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ZZP-000G3P-1R for netconf@ops.ietf.org; Tue, 19 Jun 2007 09:00:21 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0DAA12071E for ; Tue, 19 Jun 2007 11:00:13 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-0d-46779b1c3784 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EFAD5206A5 for ; Tue, 19 Jun 2007 11:00:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:00:12 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:00:12 +0200 Message-ID: <46779B1B.5030204@ericsson.com> Date: Tue, 19 Jun 2007 11:00:11 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <467490B1.50005@andybierman.com> In-Reply-To: <467490B1.50005@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 09:00:12.0497 (UTC) FILETIME=[3EDA4C10:01C7B250] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello, Although we should treat all transports as equal and I have no BIG problems with the draft, I remember that we had problems with the Beep and SOAP transports as well to get people to review and update the transport documents. Balazs Andy Bierman wrote: > There are some features waiting in line, like partial locks and access > control, > and I don't think the priority of new transport mapping work is very high. > > Andy -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 06:23:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0asD-0002hd-Bu for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 06:23:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0asC-00057w-T9 for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 06:23:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0amE-000Nvj-Dj for netconf-data@psg.com; Tue, 19 Jun 2007 10:17:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0am3-000NuS-FA for netconf@ops.ietf.org; Tue, 19 Jun 2007 10:17:28 +0000 Received: from 14.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 19 Jun 2007 06:17:21 -0400 X-IronPort-AV: i="4.16,438,1175486400"; d="scan'208"; a="28936143:sNHT8669994" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: NETCONF over TLS Date: Tue, 19 Jun 2007 12:17:20 +0200 Message-ID: In-Reply-To: <46779B1B.5030204@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF over TLS Thread-Index: AceyUNZWRBUYnbqMQ8Cdo613V9gnCAACbsRA References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <467490B1.50005@andybierman.com> <46779B1B.5030204@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Looking from the AD perspective I have the same question.=20 I would suggest that the NEE BOF includes this document on the agenda of the meeting in Chicago, so that it can be discussed together with the other proposals for NETCONF extensions, and the community can provide feedback about its priority in the context of other work that needs to be done.=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Tuesday, June 19, 2007 12:00 PM > To: Netconf (E-mail) > Subject: Re: NETCONF over TLS >=20 > Hello, > Although we should treat all transports as equal and I have=20 > no BIG problems with the draft, I remember that we had=20 > problems with the Beep and SOAP transports as well to get=20 > people to review and update the transport documents. > Balazs >=20 > Andy Bierman wrote: >=20 > > There are some features waiting in line, like partial locks=20 > and access=20 > > control, and I don't think the priority of new transport=20 > mapping work=20 > > is very high. > >=20 > > Andy >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 07:36:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0c0L-00034U-P4 for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:36:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0c0L-0006GC-En for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:36:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0btl-0002ar-O3 for netconf-data@psg.com; Tue, 19 Jun 2007 11:29:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0bta-0002aB-Fo for netconf@ops.ietf.org; Tue, 19 Jun 2007 11:29:20 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id NAA409760 ; Tue, 19 Jun 2007 13:27:12 +0100 Message-ID: <4677BDEB.8060207@isima.fr> Date: Tue, 19 Jun 2007 13:28:43 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <63214.86.72.162.197.1182013900.squirrel@www.isima.fr> <46779BC8.9070505@ericsson.com> In-Reply-To: <46779BC8.9070505@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Balazs Lengyel writes: > Hello, > Why do you feel we need a new transport mapping? What would that give > us, why is it better then SSH and BEEP? > You describe in your document what you intend to do, but please > motivate us by stating why is this a good idea? > regards Balazs > Hi Lengyel, It is not so easy to make a comparison between available security protocols for a specific application and to recommend a single one. It is easier to define a model threat for that application and then looking for a security solution. It is right that BEEP, SSH and other security protocols are able to meet the Netconf security requirements, but TLS could be a good alternative; even if other protocols could be able to give the same services. There are several reasons why one might want to do Netconf over TLS, but please don't consider them as an XOR to the available solutions. some of these reasons: - People are interesting to adopt TLS to become the unifying transport for, especially, SYSLOG, IPFIX, SNMP. And I think it is a good idea to do that for Netconf too. One argument is the following text posted out by David Harrington: [BCP72 identifies TLS as the transport security mechanism of choice when traffic is over TCP. SSH is recommended for remote login security, for providing channel-level security directly in the application. Netconf is designed to do "network configuration" as a replacement/supplement to the CLI running over a remote login session]. - TLS natively integrates key distribution and mutual authentication based on certificates, preshared keys, tokens, passwords and other credential types. If you are going to distribute vendor-certificates for your network's devices, TLS will be able to integrate the PKI use in a fashion way. - TLS can provide a user-based access-control model (RFC 4681) and by its design it provides a facility for secure connection closure (close_notify alert) as well as a flexible way to encapsulate and protect EAP (for OTP, PLAIN, CHAP, etc.), AAA and RADIUS attributes. - As Juergen Schoenwaelder pointed out, the implementors at that time did not want NETCONF/BEEP+TLS nor NETCONF/SOAP+HTTPS+TLS. Best regards -- Mohamad Badra CNRS - LIMOS Laboratory -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 07:39:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0c37-0006Nd-UZ for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:39:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0c36-0006ol-L5 for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:39:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0bwY-0002nI-RX for netconf-data@psg.com; Tue, 19 Jun 2007 11:32:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0bwN-0002md-T5 for netconf@ops.ietf.org; Tue, 19 Jun 2007 11:32:13 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id NAA659542 ; Tue, 19 Jun 2007 13:30:10 +0100 Message-ID: <4677BE9D.3020605@isima.fr> Date: Tue, 19 Jun 2007 13:31:41 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: "'Andy Bierman'" , "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> In-Reply-To: <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 David B Harrington writes: > My recommendation is to ask Badra to publish the draft as > experimental, and ask Badra to find other people willing to implement > Netconf/TLS as part of the experiment. Dear David, I don't have any problem with that. Best regards, Badra -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 07:42:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0c6b-0000if-SV for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:42:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0c6b-0007Eg-F5 for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:42:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0c01-00032R-M0 for netconf-data@psg.com; Tue, 19 Jun 2007 11:35:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0bzq-00031o-Nh for netconf@ops.ietf.org; Tue, 19 Jun 2007 11:35:48 +0000 Received: from 14.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 19 Jun 2007 07:35:36 -0400 X-IronPort-AV: i="4.16,438,1175486400"; d="url'?scan'208"; a="28972144:sNHT10022082" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7B265.F4484B25" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: FW: I-D ACTION:draft-schoenw-sming-lessons-00.txt Date: Tue, 19 Jun 2007 13:35:35 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-schoenw-sming-lessons-00.txt Thread-Index: Acex4tL425YvGqACTXeztnJY2/kEFgAgquUQ From: "Romascanu, Dan (Dan)" To: "Netconf (E-mail)" , , , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B265.F4484B25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This I-D written by Juergen includes some information about the SMIng development experience. I believe that it's good reading for folks involved in the data modeling work related to NETCONF, and other discussions happening in the BOFs and lists of the area. Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, June 18, 2007 10:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-schoenw-sming-lessons-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Lessons Learned from the SMIng Project Author(s) : J. Schoenwaelder Filename : draft-schoenw-sming-lessons-00.txt Pages : 12 Date : 2007-6-18 =09 A data modeling language for network management protocols called SMIng was developed within the Network Management Research Group of the Internet Research Task Force over a period of several years. This memo documents some of the lessons learned during the project for consideration by designers of future data modeling languages for network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-sming-lessons-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-schoenw-sming-lessons-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schoenw-sming-lessons-00.txt". =09 ------_=_NextPart_001_01C7B265.F4484B25 Content-Type: application/octet-stream; name="draft-schoenw-sming-lessons-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-schoenw-sming-lessons-00.URL Content-Disposition: attachment; filename="draft-schoenw-sming-lessons-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2hvZW53LXNtaW5nLWxlc3NvbnMtMDAudHh0DQo= ------_=_NextPart_001_01C7B265.F4484B25-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 07:57:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cLI-0008C6-1c for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:57:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0cLG-0006FI-GR for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 07:57:51 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0cEk-00044E-0s for netconf-data@psg.com; Tue, 19 Jun 2007 11:51:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0cEY-00043L-VN for netconf@ops.ietf.org; Tue, 19 Jun 2007 11:51:00 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2007 13:50:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JBor0x021609; Tue, 19 Jun 2007 13:50:53 +0200 Received: from dhcp-wdata-vlan18-22-227.cisco.com (dhcp-wdata-vlan18-22-227.cisco.com [144.254.22.227]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JBomDR012467; Tue, 19 Jun 2007 11:50:49 GMT Message-ID: <4677C316.3080707@cisco.com> Date: Tue, 19 Jun 2007 13:50:46 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David B Harrington CC: "'Andy Bierman'" , "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: <46729B3B.9090403@andybierman.com> <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> In-Reply-To: <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2251; t=1182253853; x=1183117853; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=gC2Yg8/sDNXMWW+uEgjo2ETZGdVVzIF5R++NiKkyxo8=; b=Rbvh+yckIBCG1oosM6Dqs7TymHr1Pqy+yyCq8zxJC4kOjerRWELkcmfuJxn6OeYVS/qITBw7 Mb2N+6L98CKPckim7+MVIawbhyTKarf+xb6psueaeD+lXQEpQihUkjI4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a David B Harrington wrote: > 1) key distribution is important; do more network nodes already > support TLS (and thus have certificates already distributed) or > already support SSH (and already have SSH-related credentials > distributed? > I think you have to start by asking who is trusting whom and for what? Take for instance DOCSIS. Here the cable modems aren't really all that trusted, and yet they receive a configuration. But they have to trust the DOCSIS controller. If one uses NETCONF over BEEP in this way, then the clients don't need to log in at all, but they assuredly want some reason to trust their configuration server. TLS and the X.509 infrastructure is well suited for this, as it is fairly easy to configure a small number of DNs that are signed by well known CAs that can be trusted. And so to answer your question, certainly the CAs are more well known than SSH will key pairs will ever be. That leaves the configuring of which DN you want to trust. Oh and for good measure, a manufacturers cert could be demanded for *some* sort of authentication. > 2) Will netconf provide application-level security beyond what the > secure transport provides, such as data access controls? If so, will > this be easier using TLS or SSH? What attributes need to be passed up > from the transport security to the application to provide these extra > services? > I think an example of what you have in mind would help. I don't immediately see relevance between the difference in secure transport and what happens above it. > 3) Which is easier to integrate with AAA protocols, such as RADIUS and > Diameter? > This is where BEEP does its thing. You do both TLS *and* SASL, and voila: you can mix and match, even, based on deployment needs. > 4) and most important, what would the operators use if both SSH and > TLS were > available? > Operators need to answer this question. > My recommendation is to ask Badra to publish the draft as > experimental, and ask Badra to find other people willing to implement > Netconf/TLS as part of the experiment. > I would first like to understand from Badra why TLS+SASL/BEEP is not sufficient? Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 10:43:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0evI-0001kW-2L for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 10:43:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0evG-0005NX-Om for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 10:43:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0emF-000Edx-Px for netconf-data@psg.com; Tue, 19 Jun 2007 14:33:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0em5-000EdH-6k for netconf@ops.ietf.org; Tue, 19 Jun 2007 14:33:46 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 19 Jun 2007 07:33:41 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="21527636:sNHT31853160" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5JEXdJ05660; Tue, 19 Jun 2007 07:33:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id l5JEfwjw065141; Tue, 19 Jun 2007 10:41:58 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200706191441.l5JEfwjw065141@idle.juniper.net> To: Eliot Lear cc: David B Harrington , "'Andy Bierman'" , "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS In-Reply-To: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> Date: Tue, 19 Jun 2007 10:41:58 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Eliot Lear writes: >This is where BEEP does its thing. You do both TLS *and* SASL, and >voila: you can mix and match, even, based on deployment needs. Can we hear from folks with experience with netconf/beep? I was an early advocate for beep, but our experience was fairly negative. For us, the quality of the freely-available implementations, as well as issues with the spec, were seen as trouble, but the bigger issue was just the complexity. Yes, you can read a (decoded) beep session, but do developers understand what they are looking at without smoke pouring from their ears? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 10:45:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ex9-0005HJ-7m for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 10:45:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ex8-0005o6-RE for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 10:45:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0en2-000EhG-2E for netconf-data@psg.com; Tue, 19 Jun 2007 14:34:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0emq-000Egd-UZ for netconf@ops.ietf.org; Tue, 19 Jun 2007 14:34:34 +0000 Received: (qmail 72698 invoked from network); 19 Jun 2007 14:34:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2007 14:34:28 -0000 X-YMail-OSG: 3.hFyjcVM1lVUPwnqJsNfrh.FGznNNVPW_BcQT9mIjUX97bv Message-ID: <4677E936.8030403@andybierman.com> Date: Tue, 19 Jun 2007 07:33:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Call for volunteer authors (was Re: NETCONF over TLS) References: <46729B3B.9090403@andybierman.com> <20070615181423.GC13774@elstar.local> <467490B1.50005@andybierman.com> <46779B1B.5030204@ericsson.com> In-Reply-To: <46779B1B.5030204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Balazs Lengyel wrote: > Hello, > Although we should treat all transports as equal and I have no BIG > problems with the draft, I remember that we had problems with the Beep > and SOAP transports as well to get people to review and update the > transport documents. This is an important point. We are still looking for volunteers (who understand the edits) to take over authorship of the SSH and BEEP transport documents. We somehow need to document the transport details for supporting notifications. The update for SSH seems very minor -- there are places where the and/or elements are mentioned explicitly, and the element also needs to be mentioned. There are no SSH protocol differences whatsoever, due to the notification feature. The BEEP document needs to be reviewed, and updated for notifications. Clearly the BEEP Profile needs to include the element, but there may be other text that needs updating. The SOAP document would require significant work to support Notifications, exactly as defined in the draft (e.g., without changes to any of the RPCs). Of course, the TLS document must support the Notification draft as well. Notifications is going to be done soon, and transports which do not get updated to support them will almost certainly be reclassified as Historic. > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 11:20:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fVP-0007Ig-2q for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:20:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fVN-0007Fu-NA for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:20:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fNd-000HJo-Ps for netconf-data@psg.com; Tue, 19 Jun 2007 15:12:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fNQ-000HIT-5W for netconf@ops.ietf.org; Tue, 19 Jun 2007 15:12:24 +0000 Received: from pc6 (1Cust4.tnt6.lnd4.gbr.da.uu.net [62.188.135.4]) by ranger.systems.pipex.net (Postfix) with SMTP id 90876E000745; Tue, 19 Jun 2007 16:12:10 +0100 (BST) Message-ID: <02f801c7b27b$384c6240$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" Cc: "Mohamad Badra" , "Simon Leinen" , References: <200706162025.l5GKOxjw055055@idle.juniper.net> <467675BB.3000105@isima.fr> <46768F81.5050405@cisco.com> <4676A24D.5040105@isima.fr> <4676A509.5000008@cisco.com> <4676B6AD.4060800@andybierman.com> Subject: Re: NETCONF over TLS Date: Tue, 19 Jun 2007 16:04:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ----- Original Message ----- From: "Andy Bierman" To: "Eliot Lear" Cc: "Mohamad Badra" ; "Simon Leinen" ; Sent: Monday, June 18, 2007 6:45 PM Subject: Re: NETCONF over TLS > Eliot Lear wrote: > > Mohamad Badra wrote: > >> Between, could you please tell what "far less functionally" does mean? > > > > The whole point of SASL is to provide for multiple profiles so that if > > you want to use the GSSAPI or PLAIN or OTP or something else, you can do > > so. In fact this is a battle we keep fighting *and* losing in network > > management. Shall we some day plan to have an ISMS equivalent for > > netconf? I surely hope not. > > > > And of course, you get all of this for free with the BEEP spec. > > > > I have heard comments From Juergen that there are several foo-over-TLS > drafts out there, and perhaps one specification for NM-over-TLS > might be better. I heard concerns about 'vertical silos' from Dave H > along the same lines. I also respect Eliot's concerns about reinventing > things. > > The details are always messier than the "idea". > > So, with this new 'special' RPC (that creates > a layer violation in itself) the agent needs to send 'operation-failed' > errors for any other RPC received before this one? A special mode is needed > in the RPC handler, based on, and coupled to, the transport protocol > used to establish the session -- just to support this special RPC method. > > Yuch. > My reaction is stronger than that. There are several warnings around that working groups should not attempt to design there own security mechanisms. There are too many pitfalls for those not experienced in the field and we should not go down that road. NETCONF allows you to change configurations so strong authentication of the 'manager' is a must. We need one security mechanism that is a MUST to implement to ensure interworking. As others have pointed out, there is a plethora of existing methods, to which I would add PSK and SRP for TLS, and several RFC reviewing authentication. Go choose. Tom Petch > > > Eliot > > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 11:25:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0faO-000371-NT for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:25:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0faO-0008H5-AL for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:25:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fSr-000Hi9-HJ for netconf-data@psg.com; Tue, 19 Jun 2007 15:17:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fSg-000HhG-1a for netconf@ops.ietf.org; Tue, 19 Jun 2007 15:17:48 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l5JFHUrQ003641; Tue, 19 Jun 2007 17:17:30 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.1+Sun/8.14.1/Submit) id l5JFHUre003640; Tue, 19 Jun 2007 17:17:30 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f To: "David B Harrington" Cc: "'Andy Bierman'" , "'Netconf \(E-mail\)'" Subject: Re: NETCONF over TLS X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> (David B. Harrington's message of "Mon\, 18 Jun 2007 17\:20\:17 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (usg-unix-v) References: <46729B3B.9090403@andybierman.com> <056601c7b1ee$785bbf80$0600a8c0@china.huawei.com> Date: Tue, 19 Jun 2007 17:17:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c David B Harrington writes: > BCP72 identifies TLS as the transport security mechanism of choice > when traffic is over TCP. SSH is recommended for remote login > security, for providing channel-level security directly in the > application. > Netconf is designed to do "network configuration" as a > replacement/supplement to the CLI running over a remote login > session. But when netconf starts to move into notifications and > into monitoring, then I think the argument for remote login gets > weaker. One could say that, conversely, the argument for other transport features (such as multiple channels) gets stronger. But so far the WG seems to tend to reduce the transport requirements, viz. the evolution of the notification mechanism, which now works over a single channel. > If netconf is meant for "network configuration", i.e., configuring > all types of nodes in the network, then there are some questions to > ask: 1) key distribution is important; do more network nodes already > support TLS (and thus have certificates already distributed) or > already support SSH (and already have SSH-related credentials > distributed? For the environments I'm familiar with ("classical" ISPs): * Fully manageable nodes support both SSH and TLS; SSH for access to the CLI, and TLS for access to the integrated HTTP server. * Operators often enable SSH but leave TLS disabled, because HTTP is not usually used for management in these environments. > 2) Will netconf provide application-level security beyond what the > secure transport provides, such as data access controls? I absolutely expect that at least some NETCONF implementations will provide facilities to restrict access to certain parts of the configuration based on user identities. Some vendors do this today for CLI-based configuration. > If so, will this be easier using TLS or SSH? What attributes need to > be passed up from the transport security to the application to > provide these extra services? The systems that I'm familiar with makes these decision based on user identity (username). This is readily available with SSH, but usually not with TLS. > 3) Which is easier to integrate with AAA protocols, such as RADIUS > and Diameter? SSH has been integrated with AAA protocols (RADIUS and TACACS+ in our case). I don't know whether this has been done with TLS. > 4) and most important, what would the operators use if both SSH and > TLS were available? The one that's more likely to be widely implemented and that fits better into their existing AAA infrastructure, I would guess. -- Simon. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 11:25:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0faf-0003Cp-Ty for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:25:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fae-0008Ib-Hm for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:25:57 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fUf-000Hpn-LR for netconf-data@psg.com; Tue, 19 Jun 2007 15:19:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fUU-000Hp3-MX for netconf@ops.ietf.org; Tue, 19 Jun 2007 15:19:40 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007061915193301300sp7lve>; Tue, 19 Jun 2007 15:19:33 +0000 From: "David B Harrington" To: "'Phil Shafer'" , "'Eliot Lear'" Cc: "'Andy Bierman'" , "'Netconf \(E-mail\)'" References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> Subject: RE: NETCONF over TLS Date: Tue, 19 Jun 2007 11:19:15 -0400 Message-ID: <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200706191441.l5JEfwjw065141@idle.juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceyftTZKNVtokujS3ylr/gvM+iitgAA0OEQ Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, In the Syslog WG, we debated having a TLS transport draft, since we already had a syslog over BEEP RFC. The WG is primarily made up of implementers, and they found very little demand for BEEP from operators. Many already know I favor a common secure transport layer for multiple NM protocols. I think the concept of BEEP is wonderful, since it **standardizes** secure transport for NM, providing a more secure environment across NM interfaces, and reducing security configuration work. But operators seem to refuse to use it, either because the toolkits that have been available were not good enough, or the deployment introduces more problems than it solves. I do not know how to convince operators to adopt BEEP. I think the best approach will be to make it available in widely-used products, and get operators to try out a good solid implementation with solid support. I believe BEEP is now being shipped in Cisco products, and new BEEP toolkit implementations are becoming available, so maybe that will help turn the tide on BEEP deployment. Until BEEP is accepted by operators, I do not believe we should disallow a Netconf/TLS transport just because there is a Netconf/BEEP transport. If BEEP is accepted by operators because it reduces the work of deploying security for multiple NM protocols, the TLS transport might just go away. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, June 19, 2007 10:42 AM > To: Eliot Lear > Cc: David B Harrington; 'Andy Bierman'; 'Netconf (E-mail)' > Subject: Re: NETCONF over TLS > > Eliot Lear writes: > >This is where BEEP does its thing. You do both TLS *and* SASL, and > >voila: you can mix and match, even, based on deployment needs. > > Can we hear from folks with experience with netconf/beep? I was > an early advocate for beep, but our experience was fairly negative. > > For us, the quality of the freely-available implementations, as > well as issues with the spec, were seen as trouble, but the bigger > issue was just the complexity. Yes, you can read a (decoded) beep > session, but do developers understand what they are looking at > without smoke pouring from their ears? > > Thanks, > Phil > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 11:44:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fsT-00021r-6n for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:44:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fsR-0004W8-SS for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 11:44:21 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fjR-000JGH-W3 for netconf-data@psg.com; Tue, 19 Jun 2007 15:35:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0fjG-000JFC-N1 for netconf@ops.ietf.org; Tue, 19 Jun 2007 15:34:56 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2007 17:34:50 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JFYnnY001469; Tue, 19 Jun 2007 17:34:49 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp473.cisco.com [10.61.65.217]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JFYmDR029433; Tue, 19 Jun 2007 15:34:48 GMT Message-ID: <4677F796.6070507@cisco.com> Date: Tue, 19 Jun 2007 17:34:46 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David B Harrington CC: "'Phil Shafer'" , "'Andy Bierman'" , "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> In-Reply-To: <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1046; t=1182267289; x=1183131289; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=tFiS6/9eZzhTVnaTe1k/yTvp/Hx16XDv06hwT5Zj/vM=; b=drFlqb0DqzN8U8J7jVOd29yorK7kUvkQejfvAmxvNMY+R46s7T/CX5CnN9IaJYKp8BGbUa8a FDd7EA+IKP1Yeo6LMKeoxLts29vDXt8r3kOY/ky91pS65LlapQnVDfy8; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Dave, > Many already know I favor a common secure transport layer for multiple > NM protocols. I think the concept of BEEP is wonderful, since it > **standardizes** secure transport for NM, providing a more secure > environment across NM interfaces, and reducing security configuration > work. But operators seem to refuse to use it, either because the > toolkits that have been available were not good enough, or the > deployment introduces more problems than it solves. Until recently operators didn't have a choice to even deploy it, so I'd not read too much into what operators think right just yet. > Until BEEP is accepted by operators, I do not believe we should > disallow a Netconf/TLS transport just because there is a Netconf/BEEP > transport. If BEEP is accepted by operators because it reduces the > work of deploying security for multiple NM protocols, the TLS > transport might just go away. > But it's not just TLS- it's TLS + User level authentication + framing. Guys, that's what BEEP is. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 12:32:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gcu-0008D3-TH for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 12:32:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gcu-0002Uo-Db for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 12:32:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0gX5-000N0y-Mq for netconf-data@psg.com; Tue, 19 Jun 2007 16:26:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [63.240.77.85] (helo=sccrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0gWu-000N0K-PV for netconf@ops.ietf.org; Tue, 19 Jun 2007 16:26:14 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <20070619161605015007q7sce>; Tue, 19 Jun 2007 16:16:05 +0000 From: "David B Harrington" To: "'Netconf \(E-mail\)'" References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> <4677F796.6070507@cisco.com> Subject: RE: NETCONF over TLS Date: Tue, 19 Jun 2007 12:15:47 -0400 Message-ID: <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4677F796.6070507@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: Aceyh1++Reb+TID0QTOXBdGQgkBnugAA0nYw Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Eliot, > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Tuesday, June 19, 2007 11:35 AM > To: David B Harrington > Cc: 'Phil Shafer'; 'Andy Bierman'; 'Netconf (E-mail)' > Subject: Re: NETCONF over TLS > > Dave, > > Many already know I favor a common secure transport layer > for multiple > > NM protocols. I think the concept of BEEP is wonderful, since it > > **standardizes** secure transport for NM, providing a more secure > > environment across NM interfaces, and reducing security > configuration > > work. But operators seem to refuse to use it, either because the > > toolkits that have been available were not good enough, or the > > deployment introduces more problems than it solves. > > Until recently operators didn't have a choice to even deploy > it, so I'd > not read too much into what operators think right just yet. I understand the sentiment, and maybe we shouldn't put much stock in what operators have done so far. However, I think operators did have a choice of multiple syslog implementations that implemented syslog/BEEP, and weren't sold by that solution. I don't understand why they will be sold by Netconf/BEEP. > > > Until BEEP is accepted by operators, I do not believe we should > > disallow a Netconf/TLS transport just because there is a > Netconf/BEEP > > transport. If BEEP is accepted by operators because it reduces the > > work of deploying security for multiple NM protocols, the TLS > > transport might just go away. > > > > But it's not just TLS- it's TLS + User level authentication + > framing. > Guys, that's what BEEP is. If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL + framing? Where is the value-add for using BEEP instead of using the independent components? How does BEEP make it easier for an operator to operate their network than if they simply used TLS + SASL + a standardized framing approach? > > Eliot > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 19 14:59:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ivc-0005V4-8o for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 14:59:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ivb-0006Ik-Ru for netconf-archive@lists.ietf.org; Tue, 19 Jun 2007 14:59:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0imY-0007bh-4t for netconf-data@psg.com; Tue, 19 Jun 2007 18:50:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.201] (helo=smtp102.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0imM-0007Zw-PI for netconf@ops.ietf.org; Tue, 19 Jun 2007 18:50:20 +0000 Received: (qmail 73225 invoked from network); 19 Jun 2007 18:50:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 19 Jun 2007 18:50:13 -0000 X-YMail-OSG: To0M1qkVM1kM9YpWMp0D3t1jKl4OBclY.fRZ3_QYFnwVx5w.qVMcR0o98U7GbHYKxmeUcLGVzrpekF95nCOiwTj9Dcmx6iSY9sUaTT7mZDNP Message-ID: <46782527.7050308@andybierman.com> Date: Tue, 19 Jun 2007 11:49:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> <4677F796.6070507@cisco.com> <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> In-Reply-To: <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac David B Harrington wrote: > Hi Eliot, This whole thing is sounding more TLS-specific and less NETCONF-specific every day. IMO, the Network Configuration WG is working on a network configuration protocol. The optional notifications do not change the focus of the protocol. Transport and security problems are not the focus of this WG either. I would rather the WG spend energy on finishing the Notifications draft, or even discussing access control or data modeling on the NGO list. Or even better, ignore this email thread altogether because you are too busy implementing NETCONF to notice ;-) Andy > >> -----Original Message----- >> From: Eliot Lear [mailto:lear@cisco.com] >> Sent: Tuesday, June 19, 2007 11:35 AM >> To: David B Harrington >> Cc: 'Phil Shafer'; 'Andy Bierman'; 'Netconf (E-mail)' >> Subject: Re: NETCONF over TLS >> >> Dave, >>> Many already know I favor a common secure transport layer >> for multiple >>> NM protocols. I think the concept of BEEP is wonderful, since it >>> **standardizes** secure transport for NM, providing a more secure >>> environment across NM interfaces, and reducing security >> configuration >>> work. But operators seem to refuse to use it, either because the >>> toolkits that have been available were not good enough, or the >>> deployment introduces more problems than it solves. >> Until recently operators didn't have a choice to even deploy >> it, so I'd >> not read too much into what operators think right just yet. > > I understand the sentiment, and maybe we shouldn't put much stock in > what operators have done so far. However, I think operators did have a > choice of multiple syslog implementations that implemented > syslog/BEEP, and weren't sold by that solution. I don't understand why > they will be sold by Netconf/BEEP. >>> Until BEEP is accepted by operators, I do not believe we should >>> disallow a Netconf/TLS transport just because there is a >> Netconf/BEEP >>> transport. If BEEP is accepted by operators because it reduces the >>> work of deploying security for multiple NM protocols, the TLS >>> transport might just go away. >>> >> But it's not just TLS- it's TLS + User level authentication + >> framing. >> Guys, that's what BEEP is. > > If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL > + framing? Where is the value-add for using BEEP instead of using the > independent components? How does BEEP make it easier for an operator > to operate their network than if they simply used TLS + SASL + a > standardized framing approach? >> Eliot >> > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 20 03:38:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ulY-0007cX-2C for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 03:38:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ulW-0001QS-5M for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 03:38:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ubH-0007ch-9X for netconf-data@psg.com; Wed, 20 Jun 2007 07:27:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I0ub6-0007cL-9O for netconf@ops.ietf.org; Wed, 20 Jun 2007 07:27:29 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 09:27:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5K7RNXx031687; Wed, 20 Jun 2007 09:27:23 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp258.cisco.com [10.61.65.2]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K7RMDR008533; Wed, 20 Jun 2007 07:27:22 GMT Message-ID: <4678D6D7.8020400@cisco.com> Date: Wed, 20 Jun 2007 09:27:19 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David B Harrington CC: "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> <4677F796.6070507@cisco.com> <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> In-Reply-To: <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2019; t=1182324443; x=1183188443; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20NETCONF=20over=20TLS |Sender:=20; bh=zBbMGqEgj1lLXPMYocM7VciXb2YhHixw2mzDOcNzby0=; b=oYYo6AQl/IsHpbym9tgEcPiGCxbpuspn8NXh03uALbuHmkO7hkAssqfl2GZ1z24p+TXbO6nf aWvKplQX1LvMJdJKX7G2JQ5BV0XxwMja32d9KA7geCWOR++pOdJIh7Pl; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a David B Harrington wrote: > If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL > + framing? Where is the value-add for using BEEP instead of using the > independent components? How does BEEP make it easier for an operator > to operate their network than if they simply used TLS + SASL + a > standardized framing approach? > I think these are good and fair questions. First, I didn't say that BEEP is *only* that. BEEP has a couple of what I would call frills, like the ability eliminate directionality to ease "call home". That's going to valuable to operators who need to manage hundreds of thousands of devices. Again, think along the lines of DOCSIS. A management model where the manager connects to hundreds of thousands of devices is just a non-starter. In addition, the framing allows interspersing of different (presumably related) applications. This would simplify operator access-lists, not to mention AAA operations (one versus N). SSH offers this sort of functionality, as you correctly pointed out elsewhere yesterday. But beyond that, I'd tend to agree with your sentiment. If you wanted to do what I would call a "BEEP light" that does TLS + user login, then I implement SASL first, and then a very simple framing protocol that NETCONF sits above, particularly one that doesn't require funky tags in the data, making parsing a pain. And so before you start NETCONF you add some gook along the lines of: C: start-netconf S: 354-authenticate first S: 354-SASL/PLAIN S: 354-SASL/OTP (...) S: 354 SASL/GSS-API C: SASL PLAIN username=foo password=bar S: 250 OK C: start-netconf S: 350 228 greeting follows ... C: 278 ... (where 228 and 278 are byte counts) What this gets you is integrated authentication and out of the byte counting business. You might even be able to steel the byte count code from either SMTP CHUNKING or IMAP (although IMAP is a bit weird). Eliot Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 20 20:06:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ACD-00022z-P3 for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 20:06:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ACD-00006F-Ag for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 20:06:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I1A4W-0009zg-TT for netconf-data@psg.com; Wed, 20 Jun 2007 23:58:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.8 Received: from [133.145.228.42] (helo=mail7.hitachi.co.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I1A4L-0009yf-Cl for netconf@ops.ietf.org; Wed, 20 Jun 2007 23:58:43 +0000 Received: from mlsv16.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id B924737ACE for ; Thu, 21 Jun 2007 08:58:36 +0900 (JST) Received: from mfilter-s5.hitachi.co.jp by mlsv16.hitachi.co.jp (8.13.1/8.13.1) id l5KNwaeu029681; Thu, 21 Jun 2007 08:58:36 +0900 Received: from vshuts1.hitachi.co.jp (unverified) by mfilter-s5.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id for ; Thu, 21 Jun 2007 08:58:36 +0900 Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by vshuts1.hitachi.co.jp with SMTP id M2007062108583521356 for ; Thu, 21 Jun 2007 08:58:35 +0900 Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id l5KNwal876720; Thu, 21 Jun 2007 08:58:36 +0900 Message-ID: <4679BEF9.6080904@hitachi.com> Date: Thu, 21 Jun 2007 08:57:45 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "'Netconf (E-mail)'" Subject: Re: NETCONF over TLS References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> <4677F796.6070507@cisco.com> <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> <4678D6D7.8020400@cisco.com> In-Reply-To: <4678D6D7.8020400@cisco.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Hi, I agree with the following Andy's comment. Andy Bierman wrote: > > IMO, this should be handled with a different top-level element > > than , outside the scope of the NETCONF protocol. > > That way, no special RPC code is needed at all. > > Only sessions that have been properly authenticated, and > > messages are okay, should be allowed to use methods. NETCONF and TLS are completely separeted mechanism. TLS were standardized to carry any application/transport protocol. Since SOAP/BEEP have been chosen as transport protocol of NETCONF, we don't need to care about TLS over which SOAP/BEEP would run. Additionaly, TLS's authentication mechanism is described fully in the RFC 2246. So, NETCONF does not need to care about authentication. It is unnecessary to publish NETCONF/TLS-like document. In the following draft, I wrote my view about security in the case of NETCONF/SOAP. http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementation-02.txt 4. Security Consideration Security should be considered from 2 angles. One is transport-level security, and the other is message-level security. Transport-level security such as encryption of entire message is left to SSL/TLS. However, the message-level security such as partial encryption of message or signature should be achieved by other technologies. To fulfill that need, WS-security has been stipulated. -- Eliot Lear wrote: > David B Harrington wrote: >> If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL >> + framing? Where is the value-add for using BEEP instead of using the >> independent components? How does BEEP make it easier for an operator >> to operate their network than if they simply used TLS + SASL + a >> standardized framing approach? >> > > I think these are good and fair questions. First, I didn't say that > BEEP is *only* that. BEEP has a couple of what I would call frills, > like the ability eliminate directionality to ease "call home". That's > going to valuable to operators who need to manage hundreds of thousands > of devices. Again, think along the lines of DOCSIS. A management model > where the manager connects to hundreds of thousands of devices is just a > non-starter. In addition, the framing allows interspersing of different > (presumably related) applications. This would simplify operator > access-lists, not to mention AAA operations (one versus N). SSH offers > this sort of functionality, as you correctly pointed out elsewhere > yesterday. > > But beyond that, I'd tend to agree with your sentiment. If you wanted > to do what I would call a "BEEP light" that does TLS + user login, then > I implement SASL first, and then a very simple framing protocol that > NETCONF sits above, particularly one that doesn't require funky tags in > the data, making parsing a pain. > > And so before you start NETCONF you add some gook along the lines of: > > C: start-netconf > > S: 354-authenticate first > S: 354-SASL/PLAIN > S: 354-SASL/OTP > (...) > S: 354 SASL/GSS-API > C: SASL PLAIN username=foo password=bar > S: 250 OK > C: start-netconf > S: 350 228 greeting follows > > ... > C: 278 > > ... > > (where 228 and 278 are byte counts) > > What this gets you is integrated authentication and out of the byte > counting > business. You might even be able to steel the byte count code from > either SMTP > CHUNKING or IMAP (although IMAP is a bit weird). > -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory 1-280, Higashi-koigakubo Kokubunji-shi, Tokyo 185-8601, Japan Tel:+81-42-323-1111 ext.3579 Fax:+81-42-327-7868 E-mail:tomoyuki.iijima.fg@hitachi.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 22 10:28:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k7E-00086X-5Y for netconf-archive@lists.ietf.org; Fri, 22 Jun 2007 10:28:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1k7B-0004oF-PN for netconf-archive@lists.ietf.org; Fri, 22 Jun 2007 10:28:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I1jzV-000BTT-PG for netconf-data@psg.com; Fri, 22 Jun 2007 14:20:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I1jzK-000BT0-OB for netconf@ops.ietf.org; Fri, 22 Jun 2007 14:19:56 +0000 Received: (qmail 2812 invoked from network); 22 Jun 2007 14:19:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Jun 2007 14:19:50 -0000 X-YMail-OSG: rRrpOlQVM1mxd40dgCUaXRksUTRhHwELI5ovat00qOwWnroV Message-ID: <467BDA45.6080909@andybierman.com> Date: Fri, 22 Jun 2007 07:18:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Decision Point: Named Profiles Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi, Let's see if we can reach some decisions on named profiles on the mailing list. They were originally added as a way for sessions to store and share static filters on the agent, instead of passing the filter directly in the RPC. The use of the 'any' data type is problematic for , and there is not consensus on any deterministic algorithm for processing this operation on a data node like this, such as . Two people have strongly objected to usage of the 'any' data type at all in NETCONF data models. Top Level Options: * Keep Named Profiles in this document and fix the problems * Defer named profiles until data modeling issues with resolved * Remove named profiles from this document If decision is to keep named profiles: Clear Consensus: * add a definition identifying 'name' as the index Proposed Consensus: * remove no-op 'stream' element * declare the operation on the contents of the parameter to be 'undefined' Comments? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 24 12:58:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2VPa-0006dq-QJ for netconf-archive@lists.ietf.org; Sun, 24 Jun 2007 12:58:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2VPX-0007rB-9z for netconf-archive@lists.ietf.org; Sun, 24 Jun 2007 12:58:06 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I2VH6-000ESE-9Y for netconf-data@psg.com; Sun, 24 Jun 2007 16:49:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I2VGu-000ERd-Sa for netconf@ops.ietf.org; Sun, 24 Jun 2007 16:49:14 +0000 Received: (qmail 46045 invoked from network); 24 Jun 2007 16:49:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2007 16:49:08 -0000 X-YMail-OSG: aMuHlXQVM1nCLl8Gu3OBsXXFYdlZzIehsCxKePtvr9g9XeMx Message-ID: <467EA043.40306@andybierman.com> Date: Sun, 24 Jun 2007 09:48:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: netconf@ops.ietf.org Subject: Re: review of draft-ietf-netconf-notification-07.txt References: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> In-Reply-To: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 David B Harrington wrote: >.... > Note that "Note that ... Note that ... Note that ... Note that" is > irritating! > yes -- this is my fault -- I will stop doing it, and this redundant text should be removed from this draft is well. > Did we ever resolve the lowerCamel vs C-style naming? I see > "named-profile" and stopTime. Can we be consistent? > yes -- at the Prague meeting, and I think documented in the minutes. Since we started using c-style-naming for our RPC method names and their parameters, we decided to keep doing that. To be more consistent with MIB object naming, the data model objects are named with the lowerCamelNaming. (It was a compromise to make both camps happy ;-) IMO, it doesn't matter that much. An implementation should be able to handle any valid XML 'Name', and ignore these NETCONF distinctions. > Note that ... I will send more later if I have time. ;-) > > [a quick glance at security considerations - I recommend this section > include a discussion of the threats specific to notifications, and > specifically how to mitigate those threats (e.g., use the SSH > transport defined in RFCxxxx). I think this whole section will need > work to pass security review. I'll try to make some recommendations > later.] Please do. The sooner the better (i.e., better we do it now then wait for the DISCUSS from Sam ;-) > > David Harrington Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 24 20:49:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2cls-0001LY-9F for netconf-archive@lists.ietf.org; Sun, 24 Jun 2007 20:49:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2clr-00073V-NQ for netconf-archive@lists.ietf.org; Sun, 24 Jun 2007 20:49:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I2ceH-0006Ot-2K for netconf-data@psg.com; Mon, 25 Jun 2007 00:41:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I2ce5-0006OC-Ql for netconf@ops.ietf.org; Mon, 25 Jun 2007 00:41:39 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5P0fTL13715 for ; Mon, 25 Jun 2007 00:41:29 GMT 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 Subject: RE: notification-07 issue list (4 & 5) Date: Sun, 24 Jun 2007 20:41:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> In-Reply-To: <46632921.1010403@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notification-07 issue list (4 & 5) Thread-Index: AcemIagc6M2lB+ZITKi6+EiRWJTM7QQnc0/g References: <46632921.1010403@andybierman.com> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 4) XSD template for wrapper a) current definition is not what the WG agreed to, and does not even support the replayComplete notification correctly b) definition is not extensible, such that XSD cannot be properly used to specify extensions and restrictions Actually, after Andy suggested some XSD to achieve being able to define notifications as proper extensions of the notification=20 https://ops.ietf.org/lists/netconf/netconf.2007/msg00123.html=20 I responded https://ops.ietf.org/lists/netconf/netconf.2007/msg00131.html suggesting that the XSD did not work as advertised in my tools, so I proposed something in the spirit of what Andy's stuff was trying to achieve but that validated in my tools. If there are other things it should be able to do, please clarify since it does what it needs to do from what I can see. 5) XML representation of the notification a) new element named has been added to the XSD. The WG never discussed adding this element. There is no text in the document about this element, including its actual XML type definition, purpose, or value for the notification. This is residue. It was suppose to have been removed. It will be removed in the update. =20 Sharon =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 26 10:38:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CC0-0005UP-W8 for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 10:38:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CBl-0006ge-Ni for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 10:38:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3C1x-000I99-U2 for netconf-data@psg.com; Tue, 26 Jun 2007 14:28:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3C1m-000I7h-Im for netconf@ops.ietf.org; Tue, 26 Jun 2007 14:28:28 +0000 Received: (qmail 83086 invoked from network); 26 Jun 2007 14:28:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2007 14:28:22 -0000 X-YMail-OSG: 3HAc2WIVM1kYt.P1OFgQ91CVg_Pir8WbM7A4lTPygYapQmb5R.fgF3Pq24J6gWQTm1ne5_RbHWH3YIhp3v90G0xI Message-ID: <46812244.90603@andybierman.com> Date: Tue, 26 Jun 2007 07:27:16 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: notification-07 issue list (4 & 5) References: <46632921.1010403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Sharon Chisholm wrote: > > > 4) XSD template for wrapper > > a) current definition is not what the WG agreed to, and does not > even support the replayComplete notification correctly > > b) definition is not extensible, such that XSD cannot be properly > used > to specify extensions and restrictions > > > > Actually, after Andy suggested some XSD to achieve being able to define > notifications as proper extensions of the notification > https://ops.ietf.org/lists/netconf/netconf.2007/msg00123.html > I responded > https://ops.ietf.org/lists/netconf/netconf.2007/msg00131.html > suggesting that the XSD did not work as advertised in my tools, so I > proposed something in the spirit of what Andy's stuff was trying to > achieve but that validated in my tools. If there are other things it > should be able to do, please clarify since it does what it needs to do > from what I can see. > The current XSD definition is for a wrapper that cannot have any XML attributes defined, and must contain an element called . The notification does not have an element called . This may not be the only notification ever defined that does not have any additional data to include. I think other people in the WG need to comment on this issue. Should this 'data' element be defined in the base type? Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 26 11:00:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CX3-0000VT-Kh for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:00:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CWH-0004qq-DL for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:00:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3CR2-000KEy-7k for netconf-data@psg.com; Tue, 26 Jun 2007 14:54:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3CQr-000KEE-C3 for netconf@ops.ietf.org; Tue, 26 Jun 2007 14:54:22 +0000 Received: (qmail 8590 invoked from network); 26 Jun 2007 14:54:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2007 14:54:16 -0000 X-YMail-OSG: VwlQuZ4VM1lY_MS99gY75db_tKR..Zf2CGTs2SfCavQ..tmH Message-ID: <46812857.1090602@andybierman.com> Date: Tue, 26 Jun 2007 07:53:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification XSD Bugs (2nd try) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi, Here is the XSD snippet from RFC 4741 for the element: As I pointed out in my email on May 4th, the XSD definition MUST be in the same form as the element, in order to support 'substitutionGroup' replacement of the one abstract element (ala 'rpcOperation'). The form of a NETCONF notification is: * There must be an abstract element (only child of ) to specify the 'specificNotificationType' node. The notification contents are defined by the specific notification type, just as the RPC parameters are defined by the specific RPC operation. The template is the correct one to use, not . Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 26 11:12:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ciu-0007Dg-2U for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:12:56 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Cit-00015d-QK for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:12:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3Ccz-000LNg-7V for netconf-data@psg.com; Tue, 26 Jun 2007 15:06:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3Ccd-000LLf-KY for netconf@ops.ietf.org; Tue, 26 Jun 2007 15:06:33 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 776BE1B80C3; Tue, 26 Jun 2007 17:06:24 +0200 (CEST) Date: Tue, 26 Jun 2007 17:06:48 +0200 (CEST) Message-Id: <20070626.170648.31006314.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification-07 issue list (4 & 5) From: Martin Bjorklund In-Reply-To: <46812244.90603@andybierman.com> References: <46632921.1010403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> <46812244.90603@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Andy Bierman wrote: > The current XSD definition is for a wrapper > that cannot have any XML attributes defined, and must contain > an element called . > > > > > > > > > > > > > > > > > > > The notification does not have an element called . > This may not be the only notification ever defined that does > not have any additional data to include. I think the idea is that a notification looks like this: ... There are no examples of what a looks like though. The element does seem to be superflous though. I think this approach works, although an alternative is to use a subsitution group like the rpc, which you pointed out earlier. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 26 11:39:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D8l-0004fm-M0 for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:39:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3D7y-0007LM-Ew for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:39:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3D1h-000Nch-Pv for netconf-data@psg.com; Tue, 26 Jun 2007 15:32:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.201] (helo=smtp102.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3D1X-000Nbv-01 for netconf@ops.ietf.org; Tue, 26 Jun 2007 15:32:16 +0000 Received: (qmail 67214 invoked from network); 26 Jun 2007 15:32:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2007 15:32:09 -0000 X-YMail-OSG: w5t7zwQVM1kG8RDMiqt1CQLHl6n11i_fbP9S_N5VdQesBIcar2.3yREKDCA83Eu9rySPqFjXv69bIvhG856nKMq1tg-- Message-ID: <46813137.3030108@andybierman.com> Date: Tue, 26 Jun 2007 08:31:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification-07 issue list (4 & 5) References: <46632921.1010403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> <46812244.90603@andybierman.com> <20070626.170648.31006314.mbj@tail-f.com> In-Reply-To: <20070626.170648.31006314.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Martin Bjorklund wrote: > Andy Bierman wrote: >> The current XSD definition is for a wrapper >> that cannot have any XML attributes defined, and must contain >> an element called . >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The notification does not have an element called . >> This may not be the only notification ever defined that does >> not have any additional data to include. > > I think the idea is that a notification looks like this: > > URN is wrong! Use the Namespace format, not the Capability format. > > > ... > > > > Can you find some examples on the mailing list where this sort of structure is used? I think we have been assuming the following format, as we agreed to for the notification: > > There are no examples of what a looks like though. > > The element does seem to be superflous though. > > I think this approach works, although an alternative is to use a > subsitution group like the rpc, which you pointed out earlier. I don't see why the extra XML layer helps. > > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 26 11:45:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DE0-0002ta-9O for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:45:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3DE0-0003VR-0b for netconf-archive@lists.ietf.org; Tue, 26 Jun 2007 11:45:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3D9N-000OMM-KF for netconf-data@psg.com; Tue, 26 Jun 2007 15:40:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3D9C-000OLN-R0 for netconf@ops.ietf.org; Tue, 26 Jun 2007 15:40:12 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C59211B80C3; Tue, 26 Jun 2007 17:40:05 +0200 (CEST) Date: Tue, 26 Jun 2007 17:40:30 +0200 (CEST) Message-Id: <20070626.174030.107291878.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification-07 issue list (4 & 5) From: Martin Bjorklund In-Reply-To: <46813137.3030108@andybierman.com> References: <46812244.90603@andybierman.com> <20070626.170648.31006314.mbj@tail-f.com> <46813137.3030108@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The current XSD definition is for a wrapper > >> that cannot have any XML attributes defined, and must contain > >> an element called . > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> The notification does not have an element called . > >> This may not be the only notification ever defined that does > >> not have any additional data to include. > > > > I think the idea is that a notification looks like this: > > > > > > URN is wrong! Use the Namespace format, not the Capability format. Actually, I just copied from the targetNamespace in the XSD in -07. > > > > > > > ... > > > > > > > > > > Can you find some examples on the mailing list where this sort > of structure is used? > > I think we have been assuming the following format, as we agreed to > for the notification: > > > > I agree. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 27 18:16:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3foJ-0004Uv-3R for netconf-archive@lists.ietf.org; Wed, 27 Jun 2007 18:16:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3foI-0007RD-QU for netconf-archive@lists.ietf.org; Wed, 27 Jun 2007 18:16:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3fdq-000Bgd-6Y for netconf-data@psg.com; Wed, 27 Jun 2007 22:05:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3fde-000Bf2-Ki for netconf@ops.ietf.org; Wed, 27 Jun 2007 22:05:32 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id E10FB1B80C3; Thu, 28 Jun 2007 00:05:21 +0200 (CEST) Date: Thu, 28 Jun 2007 00:03:38 +0200 (CEST) Message-Id: <20070628.000338.53090871.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: notification-07 issue list (4 & 5) From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> References: <46632921.1010403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FA139CF@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 "Sharon Chisholm" wrote: > > 4) XSD template for wrapper > > a) current definition is not what the WG agreed to, and does not > even support the replayComplete notification correctly > > b) definition is not extensible, such that XSD cannot be properly > used > to specify extensions and restrictions > > > > Actually, after Andy suggested some XSD to achieve being able to define > notifications as proper extensions of the notification > https://ops.ietf.org/lists/netconf/netconf.2007/msg00123.html > I responded > https://ops.ietf.org/lists/netconf/netconf.2007/msg00131.html > suggesting that the XSD did not work as advertised in my tools, so I > proposed something in the spirit of what Andy's stuff was trying to > achieve but that validated in my tools. Missing from both these posts are the XML that you actually got validated. I can't get your suggestion to validate... I think Andy's definition works fine (with some prefix/namespace fixes) -- although the replayComplete can be made simpler like this: Using this, I can validate: You can also define: And validate: foo As Andy pointed out, this is consistent with how rpcs are done in the base protocol. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kimiki_u3@so-net.ne.jp Wed Jun 27 21:37:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3iwZ-00063g-6o for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 27 Jun 2007 21:37:11 -0400 Received: from [60.218.222.78] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3iwY-00070O-8p for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 27 Jun 2007 21:37:11 -0400 Received: from wftkp7 (unknown [84.36.87.218]) by smtp39 (Coremail) with SMTP id EwFqR9QywGsqVkW3.1 for ; Thu, 28 Jun 2007 09:36:58 +0800 (CST) X-Originating-IP: [84.36.87.218] Subject: =?iso-2022-jp?B?GyRCJDMkTk1NJEo9UDJxJCQkcjVhJGEkRiRrSn0kSxsoQg==?= From: =?shift-jis?B?bmFuYWtv?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7A6C7.D4ED4250" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C7A6C7.D4ED4250 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B!&??7u$K(B30$BBe0J>e$N0[@-$H$*IU$-9g$$$7$?$$!#(B $B!&=P0)$C$?AjD$;$:$K3d$j@Z$C$?4X78$,$7$?$$(B $B!&7k:'$^$G$O$G$-$J$$$,!"JL$N0[@-$H8r:]$G$-$k?M$,$[$7$$(B $B!&(B30$BBe0J>e$N0[@-$HCN$j9g$$$?$$(B $B$=$s$J!"(B30$BBe!A(B70$BBe$,Cf?4$NCK=w$NBg?M$N=P2q$$$r7R$0%3%_%e%K%F%#$G$9!#(B $B59$7$+$C$?$i!"0lEYGA$$$F$_$F2<$5$$!#(B $B$-$C$H5.J}$K%T%C%?%j$J%Q!<%H%J!<$,8+$D$+$j$^$9!#(B http://serebu.biz/cas/?nh23 $B=P2q$$$,I,MW$J$$J}$O$3$A$i$^$G(B maki_noda21@yahoo.co.uk ------=_NextPart_000_0008_01C7A6C7.D4ED4250 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B!&??7u$K=1B(B30=1B$BBe0J>e$N0[@-$H$*IU$-9g$$$7$?$$!#= =1B(B
 
=1B$B!&=3DP0)$C$?AjD$;$:$K3d$j@Z$C$?= 4X78$,$7$?$$=1B(B
 
=1B$B!&7k:'$^$G$O$G$-$J$$$,!"JL$N0[@-$H8r:]$G$-$k?M$,$[$7= $$=1B(B
 
=1B$B!&=1B(B30=1B$BBe0J>e$N0[@-$HCN$j9g$$$?$$=1B(B=
 
=1B$B$=3D$s$J!"=1B(B30=1B$BBe!A=1B(B70=1B$BBe$,Cf?4$NCK=3Dw$NBg?M= $N=3DP2q$$$r7R$0%3%_%e%K%F%#$G$9!#=1B(B
 
=1B$B59$7$+$C$?$i!"0lEYGA$$$F$_$F2<$5$$!#=1B(B
 
=1B$B$-$C$H5.J}$K%T%C%?%j$J%Q!<%H%J!<$,8+$D$+$j$^$9!#=1B(B=
 
http://serebu.biz/cas/?nh23
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B=3DP2q$$$,I,MW$J$$J}$O$3$A$i$^$G=1B(B
maki_noda21@yahoo.co.uk
= ------=_NextPart_000_0008_01C7A6C7.D4ED4250-- From owner-netconf@ops.ietf.org Thu Jun 28 22:37:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I46M9-0003Zi-Bh for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:37:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I46M4-00050c-V0 for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:37:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46Dn-000IeM-9C for netconf-data@psg.com; Fri, 29 Jun 2007 02:28:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46Dc-000IdX-4I for netconf@ops.ietf.org; Fri, 29 Jun 2007 02:28:25 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5T2SFb22088 for ; Fri, 29 Jun 2007 02:28:15 GMT 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 Subject: RE: comments on notification-07 draft Date: Thu, 28 Jun 2007 22:27:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF1F@zcarhxm2.corp.nortel.com> In-Reply-To: <20070516.112746.09414354.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on notification-07 draft Thread-Index: AceXncj/2zNGsokqT9awRBzvyY7mhQiVfVJw References: <20070516.112746.09414354.mbj@tail-f.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Comments inline -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund Sent: Wednesday, May 16, 2007 5:28 AM To: netconf@ops.ietf.org Subject: comments on notification-07 draft Hi, Here are some comments on the latest draft. Some comments are the same as before (http://ops.ietf.org/lists/netconf/netconf.2007/msg00035.html). o 2.1.1=20 The missing-element's error-info is broken: Error-info: I believe there were previously comments to not have special error messages. This was discussed in Prague too. It involves reving the base protocol I think. o 3.2.5.1 In the rpc-reply example, none of the streams returned have the element 'replayLogStartTime', which according to the schema must be there. Personally, I'd rather see the schema modified so that replayLogStartTime has minOccurs=3D"0", and the description changed to: The start time of the log used to support the replay function. If replay is not supported, this element is not present. I can go either way on this. As it is, the text is conditional (if replay is supported ...), but it might be cleaner to set minOccurs=3D0 o 3.4 I've pointed out before that the 'stream' element makes no sense within a named profile. If you think it does, the text for create-subscription must be modified to allow for this case. I guess the problem is that stream has a minOccurs > 0 in the subscription. I think it does make sense to be able to save this in the named profile since it filters content. o 3.6 =20 Why does this section talk about "multiple filters"? In the schema for 'create-subscription', the description for the 'filter' parameter says:=20 This is mutually exclusive with the named profile parameter. So when/how can multiple filters be specified? It doesn't. It talks about multiple filter elements. This is the term used in the base protocol document. If it talks about multiple filters anywhere this is residue, but I believe this has been corrected everywhere now. o 5.1 I've also said before that this example doesn't make much sense. It also contains some XML errors. =20 I thought you and Hector had worked on the updated examples and agreed to the text offline? I guess Hector can comment on your proposed changes and you can reach agreement here on the list. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 28 22:42:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I46RL-00085n-5t for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:42:31 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I46RK-0007F4-Ts for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:42:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46Kh-000JHJ-Q4 for netconf-data@psg.com; Fri, 29 Jun 2007 02:35:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46KX-000JGi-1X for netconf@ops.ietf.org; Fri, 29 Jun 2007 02:35:34 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5T2ZPq06904 for ; Fri, 29 Jun 2007 02:35:25 GMT 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 Subject: RE: few quick comments on notification-07 Date: Thu, 28 Jun 2007 22:34:58 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF25@zcarhxm2.corp.nortel.com> In-Reply-To: <464B6BF0.7050300@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: few quick comments on notification-07 Thread-Index: AceX+2Aw+6BikiJlRBqSWP+qnBZ8vAh+bI3w References: <464B3B7B.5000707@andybierman.com> <20070516.194316.63807660.mbj@tail-f.com> <464B5B9E.1040108@andybierman.com> <20070516.215751.10233808.mbj@tail-f.com> <464B6BF0.7050300@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 hi Having read through this Martin & Andy thread, here are my thoughts 1) If there are ambiguities in the base protocol that the notification draft brings up, it likely makes sense to clarify them in the base document so that all capabilities can take advantage of them 2) In general, 'any' is viewed as something you want to avoid, but seeing as we have it in subtree filtering, we should just clarify whether merging is supported on the subtree object and if so what the expected behaviour is. Were there any other issues with the edit-config of the named profiles?=20 3) Does the named profile really need a key? It is easy enough to add one, but if we don't actually need it, then I'd say leave things as is. The current XSD, based on earlier discussion, allows people to rename named profiles and I don't know whether making name a key still allows that. 4) It seems we have raised minor issues with named profiles, which in the spirit of a second working group last call, it would seem that the correct thing to do would be to fix them, not to make drastic changes to the document. Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 28 22:42:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I46Rh-0008N2-S2 for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:42:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I46Rh-0007Kl-J1 for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 22:42:53 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46Mi-000JTh-Tq for netconf-data@psg.com; Fri, 29 Jun 2007 02:37:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.8 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46MY-000JSo-07 for netconf@ops.ietf.org; Fri, 29 Jun 2007 02:37:39 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l5T2a5x23067 for ; Fri, 29 Jun 2007 02:36:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B9F6.5F3FC7E0" Subject: RE: Some trivial comments on notification-07 Date: Thu, 28 Jun 2007 22:37:00 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF26@zcarhxm2.corp.nortel.com> In-Reply-To: <009601c798a4$04b92710$3415c00a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some trivial comments on notification-07 Thread-Index: AceYpYBCVJPGELZfS0WqYtW+zmPchQhULOsw References: <009601c798a4$04b92710$3415c00a@china.huawei.com> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B9F6.5F3FC7E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Li Yan Sent: Thursday, May 17, 2007 12:54 PM To: Netconf (E-mail) Subject: Some trivial comments on notification-07 =20 o pg 12, Figure 4 should be Figure 2. =20 o pg 22, Figure 8 should be Figure 3. =20 This is a result of the tools I am using (xml2rfc) and I have not yet figured out how to fix that. =20 ------_=_NextPart_001_01C7B9F6.5F3FC7E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Li = Yan
Sent:=20 Thursday, May 17, 2007 12:54 PM
To: Netconf=20 (E-mail)
Subject: Some trivial comments on=20 notification-07

 <clip> 
o pg 12, Figure 4 should be Figure 2.
 
o pg 22, Figure 8 should be Figure 3.
 
<sharon>
This is a result of = the tools I=20 am using (xml2rfc) and I have not yet figured out how to fix=20 that.
 
</sharon>
------_=_NextPart_001_01C7B9F6.5F3FC7E0-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 28 23:12:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I46u7-00038a-T7 for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 23:12:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I46tx-0004jo-Mp for netconf-archive@lists.ietf.org; Thu, 28 Jun 2007 23:12:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46oI-000MHW-Gd for netconf-data@psg.com; Fri, 29 Jun 2007 03:06:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I46o7-000MEn-Jb for netconf@ops.ietf.org; Fri, 29 Jun 2007 03:06:09 +0000 Received: (qmail 52177 invoked from network); 29 Jun 2007 03:06:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 29 Jun 2007 03:06:02 -0000 X-YMail-OSG: aHk5XjEVM1lSpVkFVtkWWmNKRUM1xg0_SXzqVjZAfUI5VxfL Message-ID: <468476D9.1030906@andybierman.com> Date: Thu, 28 Jun 2007 20:04:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: few quick comments on notification-07 References: <464B3B7B.5000707@andybierman.com> <20070516.194316.63807660.mbj@tail-f.com> <464B5B9E.1040108@andybierman.com> <20070516.215751.10233808.mbj@tail-f.com> <464B6BF0.7050300@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FB7BF25@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF25@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Sharon Chisholm wrote: > hi > > Having read through this Martin & Andy thread, here are my thoughts > > 1) If there are ambiguities in the base protocol that the notification > draft brings up, it likely makes sense to clarify them in the base > document so that all capabilities can take advantage of them > > 2) In general, 'any' is viewed as something you want to avoid, but > seeing as we have it in subtree filtering, we should just clarify > whether merging is supported on the subtree object and if so what the > expected behaviour is. Were there any other issues with the edit-config > of the named profiles? > The WG has to decide how important the "feature" of using the 'any' data type in data models is to have. Revising the base protocol document is not easy, or something done lightly. > 3) Does the named profile really need a key? It is easy enough to add > one, but if we don't actually need it, then I'd say leave things as is. > The current XSD, based on earlier discussion, allows people to rename > named profiles and I don't know whether making name a key still allows > that. Yes, the namedProfile needs a key, which is the 'name'. This allows interoperability wrt/ edit-config operation. What use-case is served by renaming the profiles? Why can't somebody just edit the XSD by hand if they want it to represent some non-standard schema, unrelated to this document? > > 4) It seems we have raised minor issues with named profiles, which in > the spirit of a second working group last call, it would seem that the > correct thing to do would be to fix them, not to make drastic changes to > the document. It depends how important people think this feature is. It might be that there is no suitable fix to the 'any' data type problem. Perhaps the WG does not want to hold up this draft to solve that problem. > > Sharon Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 29 03:55:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BKR-0006aI-5g for netconf-archive@lists.ietf.org; Fri, 29 Jun 2007 03:55:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4BKN-0007lk-MW for netconf-archive@lists.ietf.org; Fri, 29 Jun 2007 03:55:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I4BB2-000NjA-Cj for netconf-data@psg.com; Fri, 29 Jun 2007 07:46:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I4BAq-000NiP-IR for netconf@ops.ietf.org; Fri, 29 Jun 2007 07:45:54 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id BFD6C1B80C3; Fri, 29 Jun 2007 09:45:36 +0200 (CEST) Date: Fri, 29 Jun 2007 09:46:07 +0200 (CEST) Message-Id: <20070629.094607.242464045.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: comments on notification-07 draft From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF1F@zcarhxm2.corp.nortel.com> References: <20070516.112746.09414354.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B40FB7BF1F@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 "Sharon Chisholm" wrote: > Comments inline > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Martin Bjorklund > Sent: Wednesday, May 16, 2007 5:28 AM > To: netconf@ops.ietf.org > Subject: comments on notification-07 draft > > Hi, > > Here are some comments on the latest draft. Some comments are the same > as before > (http://ops.ietf.org/lists/netconf/netconf.2007/msg00035.html). > > > o 2.1.1 > > The missing-element's error-info is broken: > > Error-info: missing. > > I think that you should define an error-app-tag for the second > error, i.e. replay asked for when it's not available. > > > I believe there were previously comments to not have special error > messages. This was discussed in Prague too. It involves reving the base > protocol I think. > Ok. So will you remove this text instead? And just refer to the 'missing-element' and 'operation-failed' standard error codes? > o 3.4 > > I've pointed out before that the 'stream' element makes no sense > within a named profile. If you think it does, the text for > create-subscription must be modified to allow for this case. > > I guess the problem is that stream has a minOccurs > 0 in the > subscription. I think it does make sense to be able to save this in the > named profile since it filters content. > If you don't specify a stream in create-subscription, it defaults to NETCONF. So a stream in a named-profile doesn't make much sense. > o 3.6 > > Why does this section talk about "multiple filters"? In the > schema for 'create-subscription', the description for the > 'filter' parameter says: > > This is mutually exclusive with the named profile parameter. > > So when/how can multiple filters be specified? > > It doesn't. It talks about multiple filter elements. This is the term > used in the base protocol document. If it talks about multiple filters > anywhere this is residue, but I believe this has been corrected > everywhere now. > Ok. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From yuri17@so-net.ne.jp Fri Jun 29 15:36:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4MGk-0007MQ-KK for NETCONF-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 15:36:38 -0400 Received: from [59.44.230.240] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4MGj-0001si-S1 for NETCONF-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 15:36:38 -0400 Received: from rdktua9 (unknown [198.64.241.242]) by smtp98 (Coremail) with SMTP id aMk1ViEjypOolAUQ.1 for ; Mon, 30 Jun 2008 03:37:29 +0800 (CST) X-Originating-IP: [198.64.241.242] Subject: =?iso-2022-jp?B?GyRCJVUlJyVpJE4kXxsoQjMwMDAbJEIxXxsoQg==?= From: =?shift-jis?B?bWF5dW1p?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7AF50.66C85D00" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C7AF50.66C85D00 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B$I$&$G$9$+!)(B $B$+$J$jF@0U$J$s$G$9!#(B $B$=$7$FBg9%$-$J$s$G$9!#(B 3000$B1_$GNI$+$C$?$iO"Mm2<$5$$$M!#(B http://serebu.biz/cas/?bt01 ------=_NextPart_000_0008_01C7AF50.66C85D00 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B$I$&$G$9$+!)=1B(B
=1B$B$+$J$jF@0U$J$s$G$9!#=1B(B
=1B$B$=3D$7$FBg9%$-$J$s$G$9!#=1B(B
=
3000=1B$B1_$GNI$+$C$?$iO"Mm2<$5$$$M!#=1B(B
http://serebu.biz/cas/?bt01<= /STRONG>
------=_NextPart_000_0008_01C7AF50.66C85D00-- From owner-netconf@ops.ietf.org Sat Jun 30 12:53:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gCA-0005M5-NN for netconf-archive@lists.ietf.org; Sat, 30 Jun 2007 12:53:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4gC6-0006Te-A6 for netconf-archive@lists.ietf.org; Sat, 30 Jun 2007 12:53:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I4g3n-000Lln-0Q for netconf-data@psg.com; Sat, 30 Jun 2007 16:44:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I4g3b-000Lkz-S1 for netconf@ops.ietf.org; Sat, 30 Jun 2007 16:44:29 +0000 Received: (qmail 3463 invoked from network); 30 Jun 2007 16:44:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 Jun 2007 16:44:22 -0000 X-YMail-OSG: m_AuWn0VM1l0OXO1NqRtSIZZHeLzHuiWoZw2eLQtLbH3gVId Message-ID: <46868824.3030801@andybierman.com> Date: Sat, 30 Jun 2007 09:43:16 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: few quick comments on notification-07 References: <464B3B7B.5000707@andybierman.com> <20070516.194316.63807660.mbj@tail-f.com> <464B5B9E.1040108@andybierman.com> <20070516.215751.10233808.mbj@tail-f.com> <464B6BF0.7050300@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FB7BF25@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FB7BF25@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Sharon Chisholm wrote: >... > 3) Does the named profile really need a key? It is easy enough to add > one, but if we don't actually need it, then I'd say leave things as is. > The current XSD, based on earlier discussion, allows people to rename > named profiles and I don't know whether making name a key still allows > that. I am still trying to understand this comment. Imagine if we were writing a MIB, and decided to leave the INDEX clause out of the 'namedProfileEntry' OBJECT-TYPE macro, in case somebody wanted a different INDEX clause. Priority 1 is multi-vendor interoperability. The document should focus entirely on the standard mechanisms agreed to by the WG. Clearly, the 'name' of a named profile is its key. Without a key, none of the edit-config operations (create, delete, merge, replace) can be implemented. I am unaware of any earlier discussion proposing a different INDEX for this table. >>... > Sharon > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: