From owner-netconf@ops.ietf.org Mon Feb 7 16:40:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25009 for ; Mon, 7 Feb 2005 16:40:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyGOl-000DTN-FX for netconf-data@psg.com; Mon, 07 Feb 2005 21:26:23 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyFjZ-0007fi-Rn for netconf@ops.ietf.org; Mon, 07 Feb 2005 20:43:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12025; Mon, 7 Feb 2005 15:43:46 -0500 (EST) Message-Id: <200502072043.PAA12025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-soap-04.txt Date: Mon, 07 Feb 2005 15:43:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) Author(s) : T. Goddard Filename : draft-ietf-netconf-soap-04.txt Pages : 22 Date : 2005-2-7 The device management protocol NETCONF is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of SOAP over HTTP. NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe a SOAP over HTTP binding that, when used with persistent HTTP connections, yields an application protocol sufficient for NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-soap-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html 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-ietf-netconf-soap-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-7160653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-soap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-soap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-7160653.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Feb 10 21:02:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18165 for ; Thu, 10 Feb 2005 21:02:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzPyg-000H0P-Df for netconf-data@psg.com; Fri, 11 Feb 2005 01:52:14 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzPyb-000GzM-9X for netconf@ops.ietf.org; Fri, 11 Feb 2005 01:52:09 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 284585; Thu, 10 Feb 2005 20:50:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050119232729.GA2908@james> References: <20050119232729.GA2908@james> Date: Thu, 10 Feb 2005 20:51:57 -0500 To: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org From: Margaret Wasserman Subject: Re: last call comments on the mapping documents Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Thanks for the comments on the SSH document, Juergen. I'll try to get an update out that addresses them before the I-D deadline. Most of them are straightforward and/or editorial, but there is one topic that I think should be discussed in the WG before I make the changes you have suggested... You seem to think that we should remove everything about how NETCONF could be run in an interactive command-line environment (such as a standard SSH login or telnet session), but that information has been in the document since the beginning (literally years ago at this point), and I think that you have been the only person to make that suggestion. Do others agree? Or are there folks who would prefer that we keep the information in the document about how to run over interactive login sessions? Margaret At 12:27 AM +0100 1/20/05, Juergen Schoenwaelder wrote: >I finally managed to write down my last call review comments for >the NETCONF mappings documents. [...] -- 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 Feb 11 01:42:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09989 for ; Fri, 11 Feb 2005 01:42:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzUKk-000HmV-FH for netconf-data@psg.com; Fri, 11 Feb 2005 06:31:18 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzUKd-000Hl4-6k for netconf@ops.ietf.org; Fri, 11 Feb 2005 06:31:11 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1E491E774; Fri, 11 Feb 2005 07:31:10 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11445-05; Fri, 11 Feb 2005 07:31:09 +0100 (CET) Received: from james (Ib0ba.i.pppool.de [85.73.176.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E8003C96E; Fri, 11 Feb 2005 07:31:08 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CzUKW-0000oC-CV; Fri, 11 Feb 2005 07:31:05 +0100 Date: Fri, 11 Feb 2005 07:31:03 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Cc: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Message-ID: <20050211063103.GA2302@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret Wasserman , netconf@ops.ietf.org References: <20050119232729.GA2908@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Feb 10, 2005 at 08:51:57PM -0500, Margaret Wasserman wrote: > You seem to think that we should remove everything about how NETCONF > could be run in an interactive command-line environment (such as a > standard SSH login or telnet session), but that information has been > in the document since the beginning (literally years ago at this > point), and I think that you have been the only person to make that > suggestion. Here is what I wrote: : 2) I think sections 2, 3, and 4 stress too much the interactive start : of the ssh subsystem. I would prefer that the text really just : explains how NETCONF runs over ssh. In other words, I suggest to : show the capability exchange currently shown in section 2 in : section 3 where it is discussed. All the material specific to : typical ssh clients should IMHO go into section 5. : If people prefer to keep the command line to start an ssh : conversation in the document, then it should at least be changed : to accomodate the netconf specific port since I understand that : NETCONF over ssh uses a new well-known port to be assigned by : IANA. I guess the beginning of the second paragraph is confusing. I just want a separation of the definition or running netconf over ssh from the specifics how to invoke a netconf subsystem from an interactive shell. The proposal is simply to move all text that talks about command line client specifics from section 2 and 3 to section 5. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Feb 11 14:56:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01092 for ; Fri, 11 Feb 2005 14:56:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Czgjl-000CSn-CD for netconf-data@psg.com; Fri, 11 Feb 2005 19:45:57 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Czgjh-000CSW-3c for netconf@ops.ietf.org; Fri, 11 Feb 2005 19:45:53 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j1BJjc917482; Fri, 11 Feb 2005 11:45:38 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1BJjWe09800; Fri, 11 Feb 2005 11:45:32 -0800 (PST) (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 j1BJshHe012240; Fri, 11 Feb 2005 14:54:43 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200502111954.j1BJshHe012240@idle.juniper.net> To: Margaret Wasserman cc: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents In-Reply-To: Your message of "Thu, 10 Feb 2005 20:51:57 EST." Date: Fri, 11 Feb 2005 14:54:43 -0500 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Margaret Wasserman writes: >You seem to think that we should remove everything about how NETCONF >could be run in an interactive command-line environment (such as a >.. >Do others agree? I agree. 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 Feb 11 15:55:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10999 for ; Fri, 11 Feb 2005 15:55:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Czhie-000OUH-75 for netconf-data@psg.com; Fri, 11 Feb 2005 20:48:52 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzhiS-000OSQ-U1 for netconf@ops.ietf.org; Fri, 11 Feb 2005 20:48:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 12:57:48 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKmdTj029304 for ; Fri, 11 Feb 2005 12:48:39 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-788.cisco.com [10.21.83.19]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BDQ88369; Fri, 11 Feb 2005 12:48:37 -0800 (PST) Message-Id: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Feb 2005 12:48:37 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Proposed Resolution to PROT I-D Issues List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_444668479==_" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --=====================_444668479==_ Content-Type: text/plain; charset="us-ascii" Hi, The attached list contains the previous issues list with my suggested resolutions. Since the WG has not commented on this list, there seems little consensus to make many requested changed. The status values are: ** CLOSED ** - change not accepted or no concrete change requested ** CLOSED ** CHANGE REQUIRED ** - all or part of change accepted; change considered a clarification ** OPEN ** - no resolution yet Please review this list and send comments to the WG mailing list ASAP. The editor needs to finalize the changes for the -05 version before the ID cutoff. thanks, Andy --=====================_444668479==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="netconf_prot_issues_R1.txt" I001) Locking) 4 emails supporting requirement to allow get and get-config even if the confitg is locked. ** CLOSED ** No Change; lock does not prevent reads. An app should lock the dB even for reading if concerned it may change during the read transactions. -------------------------- I002) Session ID) How is this conveyed to the client? ** OPEN ** Doesn't seem to be a mechanism for an app to know its own session ID. -------------------------- I003) 1.1: "MUST support at least one, and MAY support more than one." For security I'd really rather see the MAY be a SHOULD in that sentence. ** CLOSED ** CHANGE REQUIRED ** Change MAY to SHOULD in PROT:sec1.1:p2:s2 -------------------------- I004) 4.5: pipelining: " request are processed serially" This should be a MUST. Doing otherwise leads to indeterminate results. ** CLOSED ** CHANGE REQUIRED ** Clarification/consistency Change PROT:sec4.5:p1:s1 OLD: NETCONF requests are processed serially by the managed device. NEW: NETCONF requests MUST be processed serially by the managed device. --------------------------- I005) section 6: I don't think this section is ready to go to the IESG yet. It needs more review and editing. ** CLOSED ** Consider adding some examples in sec 6.2 - 6.7. Hard to go back and forth between 6.8 and rest of section. --------------------------- I006) section 6: I have a few concerns about the filtering as defined. 1) I find it confusing that there is a subtle difference between selection of a particular set of values vs selecting a particular value. The difference between: and John Is very very subtle. Definable, certainly, but subtle as well. This means people will get it wrong and get confused (especially for more complex examples). ** CLOSED ** No change; This is explained in the text and examples (6.6 selection nodes and 6.5 content match nodes) 2) I don't think it's possible using the current filter system to select empty values. IE, this: Will select all user's names, not a user with a blank name. (please don't tell me you're going to distinguish between and ) ** CLOSED ** CHANGE REQUIRED ** Need to add clarification to sec6.1 that explicit selection of empty content (in a content match node) is not supported. (Should not count on XML parser distinguishing between long and short form of an empty node). 3) logical and vs logical or in selections In the document this example: root fred barney superuser Indicates that there is an implicit logical OR between the tags and an implicit logical AND between the sub-tags (name/type in the third user selection). This is, again, subtle and subject to poor understanding by users which will lead to errors. One solution to some of these problems would be to separate the selected nodes from the value matched nodes using different groups. Or add an attribute or something. Anything that makes it more obvious what is going on and is desired. ** CLOSED ** No change; Sections 6.1 - 6.7 document the rules for sub-tree filter processing. The example above isn't confusing. It is clear from the processing rules and the example that each top-level sub-tree processed will yield its own results (e.g., OR expression). ----------------------- I007) 7.2: default-operation: none... "as well allowing a simple existence test for configuration data". This statement should be stricken, IMHO. If you want an existence test, you should write one into the protocol (get-config will do this now). I don't think you should cobble in a feature this way. It may be that it exists and can be used this way, but I don't think documenting it this way so it becomes officially supported practice is wise. ** CLOSED ** CHANGE REQUIRED ** PROT:sec7.2:Parameters:default-operation:none OLD: Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted, as well allowing a simple existence test for configuration data. NEW: Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted. ------------------------- I008) 7.2 and others: Is it legal to specify config for non-existent devices. IE, can I upload a config for a interface which I haven't physically inserted yet? Or is this going to be implementation specific? It should be at least mentioned one way or another. ** CLOSED ** Data modeling issue Not NETCONF protocol issue to distinguish between config and pre-provisioning high-level operations -------------------------- I009) 7.2: I fail to see how these operations are going to work in some cases which I'm sure will come up in the future. I'm going to use the examples enclosed in the section, but I don't think they're necessarily the right ones to use. But you'll get the idea. The problem comes from the assumption of the data model that I'm not convinced will be true. Take the case of messing with an interface. The examples all show various operations working on an interface named "Ethernet0/0", and only in the sentences above is it sort-of-mentioned in English text that the index when searching for things to modify are going to be based on the name. There is no mention of this actually in the protocol. Sure, in this particular case it is likely this may be the only selectable method in the resulting data model and that is yet to be determined and out of scope. However, I think it is highly likely that we will end up with a data model(s) that will allow for separate indexes. So, for the purposes of example, lets say that you could select an interface by address as well (very conceivable). Is this legal for a replace: 1500
1.2.3.4
Would that allow you to replace the MTU just as you would if you specified the name? Or are you going to restrict data models in the future to only one set of unique indexes? Can I set the MTU of all interfaces which are up using something like: up 1500 This is a solvable problem, obviously. My only concern is that no where is this type of usage of the protocol discussed. It does have implications on the resulting data models that are allowed to be defined. Fundamentally, this results from data to change and selectors being intermixed, which technically I think is a mistake (they should be marked by attributes or in a special section of the tree. I'm sure that concept will die a horrible death and I'll get flamed for mentioning it. So, let me just end by repeating: it needs discussion regardless if you don't want to explicitly talk about how to select particular values. ** CLOSED ** No change; Data modeling issue No specific changes requested -------------------- I010) 7.2 replace: what happens if you replace a container with a set of elements (say A, B, and C) but the original object also contained a D element. Does the new one get D as well, or is that nuked (I think is the case) if operation=replace is put on the high level object (as opposed to each element for A B and C). ** CLOSED ** D would get nuked because that's the operation that was requested, or the operation will fail because D was required but not specified. -------------------- I011) 7.3 copy from remote to remote is a "may choose not to support". I think this is fundamentally a bad thing to ever allow. netconf should not be a file transfer protocol. The security issues surrounding such a notion haven't been discussed. You can't easily specify access control rights for when you're allowed to do so. It essentially lets any firewall implementing netconf (that implements URL to URL copying and has access to both an internal and external network) to be used as a transfer hole in a security domain. I really think you should say that implementations MUST NOT support this. It is well beyond the scope of what netconf should do. It is highly suspect from a security point of view and will only add more work in the future as you'll have to write access control rights for when this is acceptable and when it is not and by what users. ** CLOSED ** No change; Not a shared concern; WG would rather add usage restrictions later, and only if operational experience shows this is warranted. -------------------- I012) 7.3 example shows the use of ftp. Can we use something more secure in the example please? ** CLOSED ** No change; no suggested replacement text provided -------------------- I013) 7.4: #url allows a url to appear as a delete. doing remote file management using netconf is questionable at best. From a security point of view, it makes me cringe. ** CLOSED ** No change; no suggested replacement text provided -------------------- I014) 8.8.5.1: so with #url capability supporting ftp I can force a netconf client to remote edit files? Is this really wise? ** CLOSED ** No change; no suggested replacement text provided -------------------- I015) url summary: there are two types of urls: local and remote. Some operations make sense for some of those, some for others. Some operations, IMHO, should not be allowed on remote types. ** CLOSED ** No change; no suggested replacement text provided -------------------- I016) 9: Implementators SHOULD also provide a well thought out authorization scheme with NETCONF. => MUST ** CLOSED ** No change; no WG consensus for this change; subjective what "well thought out" means; consider removing this phrase. -------------------- I017) 9: you need to discuss that global operations MUST disallow the changing of information that an individual does not have authorization to perform. EG, if a user U is not allowed to configure an IP address on an interface but someone else has configured an IP address for an interface within the , then the user U must not be allowed to perform a copy-config or commit from to . ** CLOSED ** CHANGE REQUIRED ** Add a paragraph at the end of PROT:sec9 based on this suggested text. -------------------- I018) 9: Similarly, you need to discuss what happens if you don't use a lock. Specifically, if user U1 modifies the candidate config in a way that user U2 is not allowed to, and since U1 MUST NOT be able to commit those changes then not using a lock could leave a system in a state where neither U1 nor U2 can commit their changes to running. ** CLOSED ** No change; U1 cannot be aware of U2 (Un) and it is up to the agent to check access control during the and disallow unauthorized changes. There is already text that if locks are not implemented correctly then improper results may occur. -------------------- I019) Commit operation atomicity [PROT, missing section number] Proposed change: If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration must remain unchanged. Response: Capital "'MUST' remain unchanged" and I'm happy with the wording. ** CLOSED ** CHANGE REQUIRED ** Edit accepted -------------------- I020) d) The description of the error-info states that vendor specific elements may only be added at the end of the sequence. I do not really see the need for this rule since namespaces should be used anyway. I would prefer to not introduce such rules, the specification should instead spell out that any extensions/additions must have their own namespace. ** CLOSED ** CHANGE REQUIRED ** Edit accepted; CLR should be removed -------------------- I021) g) I had some trouble to figure out what RPC responses can contain. Section 4.4 says that an element is sent in messages if no error occurred. Looking at the examples shown later on, it looks like is only present if the RPC was successful and no other result data was returned. I am not sure why this is needed at all. Things get a bit more irritating if I look at the elements. Such an element is used to signal an error or a warning. This raises the question whether a warning can be returned even though the RPC succeeds. Will I then get or followed by an signalling a warning? Or will the warning come first? If the RPC does not abort on error, I would suggest that I can get multiple errors. But this does not seem to be the case (according to the NETCONF RelaxNG spec.) The RelaxNG spec (did not check the xsd) requires the element to be while section 4.2 shows an example which shows . If the idea is indeed that RPC results always show up in a element, then why not replace with an empty element? I recall some discussion that errors/warnings may actually be generated while an operation is processed and that they were even supposed at some point to interleave the data portion. So I assume there is something missing here. Perhaps the examples used later in the document focus too much on the no error cases. ** CLOSED ** No change; Not all operations have a element (e.g., ) -------------------- I022) r) Section 7.1 IMHO misses text which explain how overlapping operation attributes are handled. What for example happens if I have: <... operation="delete"> <... operation="merge"/> There might be more interesting combinations. I would prefer to have well defined rules so that all implementors do the same thing here. If there are nested operation attribute value combinations that do not make sense, I think it would be fair to request that such things are checked before starting the execution of the merge. ** CLOSED ** No change; This depends on the data model and common sense. We don't need CLRs that say the agent MUST or MUST NOT merge sub-tree X before deleting it and its parent in the same . -------------------- I023) t) After reading the part of the spec, I felt that there is in general a need to have more elements of the procedure spelled out. I think it would help implementors tremendously if it were spelled out which tests have to be performed, what the error codes are that can be generated and so on. At the moment, the document leaves it to the implementor to figure out what needs to be checked, in which order, before are while processing an edit-config and so on. I believe it would help interoperability if some more guidance would be given here. ** CLOSED ** No change; Could be a companion document after some implementation experience gained. -------------------- I024) E) Section 8.8.3 says shows the following urn format: urn:ietf:params:xml:ns:netconf:base:1.0#url?protocol={protocol-name,...} It is unclear what are meta characters here. I guess '{' and '}' are meta characters if I look at the subsequent examples. Anyway, the more general comment here is that you identity URI schemes and not protocols. So perhaps the example should be: urn:ietf:params:xml:ns:netconf:base:1.0#url?schemes=http,ftp,file Perhaps life would be even easier if the schemes were announce as separate capabilities: urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=http urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=ftp urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=file Perhaps a general discussion how to deal with parameters in capabilties would be useful. The later version has the advantage that I do not have to parse the full scheme to check whether the 'file' scheme is supported - a simle string match is good enough. (But parsing this on the other hand does not seem overly complex either). ** CLOSED ** No change; No consensus to change the #url capability syntax --=====================_444668479==_-- -- 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 Feb 11 19:26:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16040 for ; Fri, 11 Feb 2005 19:26:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Czkxl-0009Od-VO for netconf-data@psg.com; Sat, 12 Feb 2005 00:16:41 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Czkxk-0009Nd-RF for netconf@ops.ietf.org; Sat, 12 Feb 2005 00:16:40 +0000 Received: from [10.0.0.171] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 285443; Fri, 11 Feb 2005 19:15:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> References: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> Date: Fri, 11 Feb 2005 19:15:37 -0500 To: Andy Bierman , netconf@ops.ietf.org From: Margaret Wasserman Subject: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk A comment on issue I002: I002) Session ID) How is this conveyed to the client? ** OPEN ** Doesn't seem to be a mechanism for an app to know its own session ID. I have suggested in the past that the server should return the session ID to the client in the server's message. Is there some reason why that is impractical or undesirable? Margaret -- 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 Feb 11 19:44:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17110 for ; Fri, 11 Feb 2005 19:44:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzlK5-000Dps-7t for netconf-data@psg.com; Sat, 12 Feb 2005 00:39:45 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzlJw-000DpN-CS for netconf@ops.ietf.org; Sat, 12 Feb 2005 00:39:36 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 16:40:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1C0dXwN024024; Fri, 11 Feb 2005 16:39:34 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-788.cisco.com [10.21.83.19]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BDR16142; Fri, 11 Feb 2005 16:39:32 -0800 (PST) Message-Id: <4.3.2.7.2.20050211163904.02376c18@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Feb 2005 16:39:31 -0800 To: Margaret Wasserman From: Andy Bierman Subject: Re: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) Cc: netconf@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 04:15 PM 2/11/2005, Margaret Wasserman wrote: >A comment on issue I002: > >I002) > >Session ID) How is this conveyed to the client? > > ** OPEN ** > Doesn't seem to be a mechanism for an app to know its > own session ID. > > >I have suggested in the past that the server should return the session ID to the client in the server's message. Is there some reason why that is impractical or undesirable? no -- it needs to be specified in all the drafts. >Margaret 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 Feb 11 20:21:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18854 for ; Fri, 11 Feb 2005 20:21:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Czlte-000LNI-2x for netconf-data@psg.com; Sat, 12 Feb 2005 01:16:30 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Czltc-000LN4-RW for netconf@ops.ietf.org; Sat, 12 Feb 2005 01:16:29 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j1C1GK920345; Fri, 11 Feb 2005 17:16:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1C1GDe63121; Fri, 11 Feb 2005 17:16:14 -0800 (PST) (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 j1C1PPHe013338; Fri, 11 Feb 2005 20:25:25 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200502120125.j1C1PPHe013338@idle.juniper.net> To: Margaret Wasserman cc: Andy Bierman , netconf@ops.ietf.org Subject: Re: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) In-Reply-To: Your message of "Fri, 11 Feb 2005 19:15:37 EST." Date: Fri, 11 Feb 2005 20:25:25 -0500 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Margaret Wasserman writes: >I have suggested in the past that the server should return the >session ID to the client in the server's message. Is there >some reason why that is impractical or undesirable? Nope, sounds good. 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 Feb 12 11:48:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14429 for ; Sat, 12 Feb 2005 11:48:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D00JJ-000Apf-Qi for netconf-data@psg.com; Sat, 12 Feb 2005 16:39:57 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D00JH-000ApP-Tx for netconf@ops.ietf.org; Sat, 12 Feb 2005 16:39:55 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2005 09:52:14 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,197,1102291200"; d="scan'208"; a="225384198:sNHT19592976" Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1CGdrTj005869; Sat, 12 Feb 2005 08:39:53 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-556.cisco.com [10.21.98.44]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BDR40345; Sat, 12 Feb 2005 08:39:52 -0800 (PST) Message-Id: <4.3.2.7.2.20050212082458.027e3830@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 12 Feb 2005 08:39:51 -0800 To: Phil Shafer From: Andy Bierman Subject: Re: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) Cc: Margaret Wasserman , netconf@ops.ietf.org In-Reply-To: <200502120125.j1C1PPHe013338@idle.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 05:25 PM 2/11/2005, Phil Shafer wrote: >Margaret Wasserman writes: >>I have suggested in the past that the server should return the >>session ID to the client in the server's message. Is there >>some reason why that is impractical or undesirable? > >Nope, sounds good. Okay, now let's help Rob understand the edits. Here's the example from the draft: OLD: urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:base:1.0#startup http:/example.net/router/2.3/core#myfeature NEW: ... 4 okay? >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: -- 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 Feb 14 12:26:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24358 for ; Mon, 14 Feb 2005 12:26:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0jq0-0005yw-LP for netconf-data@psg.com; Mon, 14 Feb 2005 17:16:44 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0jpz-0005yj-OH for netconf@ops.ietf.org; Mon, 14 Feb 2005 17:16:43 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 09:26:25 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1EHGbuE016509 for ; Mon, 14 Feb 2005 09:16:39 -0800 (PST) Received: from sberlw2k01 (sjc-vpn7-315.cisco.com [10.21.145.59]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBP56728; Mon, 14 Feb 2005 09:16:38 -0800 (PST) Message-Id: <200502141716.BBP56728@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: and not in XSD? Date: Mon, 14 Feb 2005 09:16:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 thread-index: AcUSuPE+ad99C9vbQwmJmV5dXXteAA== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The hello message doesn't seem to be part of the XML schema in draft 4. Is there a newer version of the schema floating around? There also does not seem to be any way to have a vendor extension to the set of operations that can be contained in an . Do we need an in there someplace? -steve -- 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 Feb 14 20:35:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13314 for ; Mon, 14 Feb 2005 20:35:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0rSJ-0001rQ-Hx for netconf-data@psg.com; Tue, 15 Feb 2005 01:24:47 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0rSF-0001r9-Mr for netconf@ops.ietf.org; Tue, 15 Feb 2005 01:24:43 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 14 Feb 2005 17:24:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208"; a="232499339:sNHT20265960" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Feb 2005 17:24:42 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 14 Feb 2005 17:22:57 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440874B389@photon.jnpr.net> Thread-Topic: Issue I002 (Was Re: Proposed Resolution to PROT I-D Issues List) Thread-Index: AcURIcIngvOKx2DrQxqZLjwrdBofswB2wt3w From: "Rob Enns" To: "Andy Bierman" , "Phil Shafer" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 15 Feb 2005 01:24:43.0149 (UTC) FILETIME=[20843BD0:01C512FD] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > OLD: > > > > urn:ietf:params:xml:ns:netconf:base:1.0 > > > urn:ietf:params:xml:ns:netconf:base:1.0#startup > > > http:/example.net/router/2.3/core#myfeature > > > >=20 > NEW: >=20 > > > ... > > 4 > >=20 > Ack. Edits in progress... thanks, Rob -- 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 Feb 16 08:43:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09103 for ; Wed, 16 Feb 2005 08:43:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1PJX-0004ac-M7 for netconf-data@psg.com; Wed, 16 Feb 2005 13:33:59 +0000 Received: from [68.142.200.158] (helo=web30905.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D1PJW-0004aN-Ow for netconf@ops.ietf.org; Wed, 16 Feb 2005 13:33:58 +0000 Received: (qmail 8258 invoked by uid 60001); 16 Feb 2005 13:33:58 -0000 Message-ID: <20050216133358.8256.qmail@web30905.mail.mud.yahoo.com> Received: from [128.107.253.42] by web30905.mail.mud.yahoo.com via HTTP; Wed, 16 Feb 2005 05:33:58 PST Date: Wed, 16 Feb 2005 05:33:58 -0800 (PST) From: nag Subject: EditOperationType To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I am trying to implement netconf protocol manager and agent components. There are a few things I could not understand. I appreciate it highly if someone can help me with those. 1) The following from the draft04 xsd. Which element is supposed to have this attribute ? thanks nag __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.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 Wed Feb 16 09:00:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10554 for ; Wed, 16 Feb 2005 09:00:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1PeX-000ASe-Qs for netconf-data@psg.com; Wed, 16 Feb 2005 13:55:41 +0000 Received: from [68.142.200.156] (helo=web30903.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D1PeW-000ASQ-VU for netconf@ops.ietf.org; Wed, 16 Feb 2005 13:55:41 +0000 Received: (qmail 19940 invoked by uid 60001); 16 Feb 2005 13:55:40 -0000 Message-ID: <20050216135540.19938.qmail@web30903.mail.mud.yahoo.com> Received: from [128.107.253.42] by web30903.mail.mud.yahoo.com via HTTP; Wed, 16 Feb 2005 05:55:40 PST Date: Wed, 16 Feb 2005 05:55:40 -0800 (PST) From: nag Subject: session handling To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I have an implementation question on the session establishment and conducting the session. 1) Given that upon session creation the agent sends the session-id as part of the hello message, Is the client required to send the session-id in each of the requests to the agent. How else is the agent going to identify that a given request belongs to what session. Is it required that client and agent have a connection opened to each other for the entire duration of the session. What happens if the client loses the connection due to some network failure. Should agent implement that as a kill-session or end-session request. Will be great if someone help me with this. Thanks nag __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -- 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 Feb 16 23:15:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08487 for ; Wed, 16 Feb 2005 23:15:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1cwF-000B0A-FB for netconf-data@psg.com; Thu, 17 Feb 2005 04:06:51 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1cwE-000Azn-7J for netconf@ops.ietf.org; Thu, 17 Feb 2005 04:06:50 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 16 Feb 2005 20:06:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,92,1107763200"; d="txt'?scan'208"; a="232738548:sNHT47163300" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 20:06:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C514A6.1A4B3DF4" Subject: Netconf prot update Date: Wed, 16 Feb 2005 20:06:48 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440874B4CF@photon.jnpr.net> X-MS-Has-Attach: yes Thread-Topic: Netconf prot update Thread-Index: AcUUphol2wcxztYQQBihuRQtsK13WA== From: "Rob Enns" To: X-OriginalArrivalTime: 17 Feb 2005 04:06:49.0334 (UTC) FILETIME=[1A99C960:01C514A6] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C514A6.1A4B3DF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've completed the clarifications and issues updates to the protocol draft.=20 The issues resolution is identical to Andy's proposed=20 resolution. I made a few changes to the clarifications resolution=20 and have attached an updated status. The diff to Andy's status is: 15,16c15,16 < C012 PROT Hold Clarification=20 < C013 PROT Hold Clarification=20 --- > C012 PROT Accept Clarification=20 > C013 PROT Accept Clarification=20 22c22 < C019 PROT Hold Clarification=20 --- > C019 PROT Accept Clarification=20 32c32 < C029 PROT Accept Clarification=20 --- > C029 PROT Hold Clarification=20 47,48c47,48 < C044 PROT Accept Clarification=20 < C045 PROT Accept Clarification=20 --- > C044 PROT Hold Clarification=20 > C045 PROT Hold Clarification=20 56c56 < C053 PROT Hold Clarification=20 --- > C053 PROT Accept Clarification=20 62c62 < C059 PROT Hold Clarification=20 --- > C059 PROT Accept Clarification=20 Rob ------_=_NextPart_001_01C514A6.1A4B3DF4 Content-Type: text/plain; name="status_list_2.txt" Content-Description: status_list_2.txt Content-Disposition: attachment; filename="status_list_2.txt" Content-Transfer-Encoding: base64 ICAgICAgICAgICANCklEICAgICAgICAgIERPQyAgICAgICBTdGF0dXMgICAgIENvbW1lbnQNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkMwMDEgICAgICAgIEJFRVAgICAgICBBY2NlcHQgICAgIFR5cG8N CkMwMDIgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIGFkZCBzaG9ydCBkZWZlcnJlZCBmZWF0 dXJlcyBsaXN0IGFwcGVuZGl4DQpDMDAzICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICByZW1v dmUgdGhlIG5ldGNvbmYtc3RhdGUgZGF0YSBtb2RlbA0KQzAwNCAgICAgICAgUFJPVCAgICAgIEFj Y2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAwNSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAg Q2xhcmlmaWNhdGlvbg0KQzAwNiAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNh dGlvbg0KQzAwNyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAw OCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAwOSAgICAgICAg UFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxMCAgICAgICAgUFJPVCAgICAg IEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxMSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAg ICAgQ2xhcmlmaWNhdGlvbg0KQzAxMiAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlm aWNhdGlvbg0KQzAxMyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0K QzAxNCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxNSAgICAg ICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxNiAgICAgICAgUFJPVCAg ICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxNyAgICAgICAgUFJPVCAgICAgIEFjY2Vw dCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAxOCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgVHlw bw0KQzAxOSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAyMCAg ICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgVHlwbw0KQzAyMSAgICAgICAgUFJPVCAgICAgIEhv bGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzAyMiAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAg VHlwbw0KQzAyMyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAy NCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgVHlwbw0KQzAyNSAgICAgICAgUFJPVCAgICAg IEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzAyNiAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAg ICAgQ2xhcmlmaWNhdGlvbg0KQzAyNyAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlm aWNhdGlvbg0KQzAyOCAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0K QzAyOSAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzAzMCAgICAg ICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAzMSAgICAgICAgUFJPVCAg ICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzAzMiAgICAgICAgUFJPVCAgICAgIEFjY2Vw dCAgICAgQ2xhcmlmaWNhdGlvbg0KQzAzMyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xh cmlmaWNhdGlvbg0KQzAzNCAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlv bg0KQzAzNSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgVHlwbw0KQzAzNiAgICAgICAgUFJP VCAgICAgIEFjY2VwdCAgICAgVHlwbw0KQzAzNyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAg Q2xhcmlmaWNhdGlvbg0KQzAzOCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNh dGlvbg0KQzAzOSAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0 MCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0MSAgICAgICAg UFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0MiAgICAgICAgUFJPVCAgICAg IEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0MyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAg ICAgQ2xhcmlmaWNhdGlvbg0KQzA0NCAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlm aWNhdGlvbg0KQzA0NSAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0K QzA0NiAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0NyAgICAg ICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0OCAgICAgICAgUFJPVCAg ICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzA0OSAgICAgICAgUFJPVCAgICAgIEFjY2Vw dCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1MCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xh cmlmaWNhdGlvbg0KQzA1MSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlv bg0KQzA1MiAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1MyAg ICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1NCAgICAgICAgUFJP VCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1NSAgICAgICAgUFJPVCAgICAgIEFj Y2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1NiAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAg Q2xhcmlmaWNhdGlvbg0KQzA1NyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNh dGlvbg0KQzA1OCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA1 OSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA2MCAgICAgICAg UFJPVCAgICAgIFJlamVjdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA2MSAgICAgICAgUFJPVCAgICAg IEFjY2VwdCAgICAgVHlwbw0KQzA2MiAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlm aWNhdGlvbg0KQzA2MyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0K QzA2NCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA2NSAgICAg ICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA2NiAgICAgICAgUFJPVCAg ICAgIEhvbGQgICAgICAgVW5pdHMgY2hhbmdlIGZyb20gbWludXRlcyB0byBzZWNvbmRzDQpDMDY3 ICAgICAgICBQUk9UICAgICAgSG9sZCAgICAgICBDbGFyaWZpY2F0aW9uDQpDMDY4ICAgICAgICBQ Uk9UICAgICAgSG9sZCAgICAgICBDbGFyaWZpY2F0aW9uDQpDMDY5ICAgICAgICBQUk9UICAgICAg QWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpDMDcwICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAg ICBDbGFyaWZpY2F0aW9uDQpDMDcxICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZp Y2F0aW9uDQpDMDcyICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpD MDczICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpDMDc0ICAgICAg ICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uOyBkdXBsaWNhdGUNCkMwNzUgICAg ICAgIFBST1QgICAgICBSZWplY3QgICAgIENsYXJpZmljYXRpb247IG1pc3VuZGVyc3RhbmRpbmcN CkMwNzYgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb247IEV4cGVjdCAt PiBDTEkNCkMwNzcgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIFR5cG8NCkMwNzggICAgICAg IFBST1QgICAgICBIb2xkICAgICAgIENsYXJpZmljYXRpb24NCkMwNzkgICAgICAgIFBST1QgICAg ICBSZWplY3QgICAgIFRlcm1pbm9sb2d5IGNoYW5nZQ0KQzA4MCAgICAgICAgUFJPVCAgICAgIEFj Y2VwdCAgICAgQ2xhcmlmaWNhdGlvbjsgZHVwbGljYXRlDQpDMDgxICAgICAgICBQUk9UICAgICAg QWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpDMDgyICAgICAgICBQUk9UICAgICAgSG9sZCAgICAg ICBDbGFyaWZpY2F0aW9uDQpDMDgzICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZp Y2F0aW9uDQpDMDg0ICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpD MDg1ICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uDQpDMDg2ICAgICAg ICBQUk9UICAgICAgQWNjZXB0ICAgICBUeXBvDQpDMDg3ICAgICAgICBQUk9UICAgICAgQWNjZXB0 ICAgICBUeXBvDQpDMDg4ICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9u DQpDMDg5ICAgICAgICBQUk9UICAgICAgQWNjZXB0ICAgICBDbGFyaWZpY2F0aW9uOyBkdXBsaWNh dGUNCkMwOTAgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb247IGR1cGxp Y2F0ZQ0KQzA5MSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgVHlwbw0KQzA5MiAgICAgICAg UFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA5MyAgICAgICAgUFJPVCAgICAg IEFjY2VwdCAgICAgQ2xhcmlmaWNhdGlvbg0KQzA5NCAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAg ICAgQ2xhcmlmaWNhdGlvbg0KQzA5NSAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgQ2xhcmlm aWNhdGlvbg0KQzA5NiAgICAgICAgUFJPVCAgICAgIEhvbGQgICAgICAgQ2xhcmlmaWNhdGlvbg0K QzA5NyAgICAgICAgUFJPVCAgICAgIEFjY2VwdCAgICAgUGFnZSBmb3JtYXQNCkMwOTggICAgICAg IFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMwOTkgICAgICAgIFBST1QgICAg ICBBY2NlcHQgICAgIFR5cG8NCkMxMDAgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJp ZmljYXRpb24NCkMxMDEgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24N CkMxMDIgICAgICAgIFBST1QgICAgICBIb2xkICAgICAgIENsYXJpZmljYXRpb24NCkMxMDMgICAg ICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMxMDQgICAgICAgIFBST1Qg ICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMxMDUgICAgICAgIFBST1QgICAgICBBY2Nl cHQgICAgIENsYXJpZmljYXRpb24NCkMxMDYgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIFR5 cG8NCkMxMDcgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMxMDgg ICAgICAgIFBST1QgICAgICBIb2xkICAgICAgIFVSTiByZWdpc3RyYXRpb24gcnVsZXMNCkMxMDkg ICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMxMTAgICAgICAgIFBS T1QgICAgICBBY2NlcHQgICAgIENsYXJpZmljYXRpb24NCkMxMTEgICAgICAgIFBST1QgICAgICBI b2xkICAgICAgIENsYXJpZmljYXRpb24NCkMxMTIgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAg IFR5cG8NCkMxMTMgICAgICAgIFBST1QgICAgICBBY2NlcHQgICAgIFR5cG8NCg0KDQo= ------_=_NextPart_001_01C514A6.1A4B3DF4-- -- 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 Feb 17 14:34:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25159 for ; Thu, 17 Feb 2005 14:34:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1rH1-000AYu-2l for netconf-data@psg.com; Thu, 17 Feb 2005 19:25:15 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1rH0-000AYh-54 for netconf@ops.ietf.org; Thu, 17 Feb 2005 19:25:14 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 17 Feb 2005 11:25:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,95,1107763200"; d="scan'208"; a="232797129:sNHT20052060" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 11:25:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Section 6: Subtree Filtering Date: Thu, 17 Feb 2005 11:25:13 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440874B520@photon.jnpr.net> Thread-Topic: Section 6: Subtree Filtering Thread-Index: AcUVJmdaPMr99sWxRdai47nTgO/mpA== From: "Rob Enns" To: X-OriginalArrivalTime: 17 Feb 2005 19:25:13.0471 (UTC) FILETIME=[6739D0F0:01C51526] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable There were a number of comments from the WG on section 6 of the protocol draft, which deals with subtree filtering. There were some specific comments, which have been addressed in the -05 version, but also some comments requesting=20 rework of this section to make it easier to understand. I haven't had time to tackle this. Is there a volunteer in the WG that could contribute text and edits to improve section 6? Please let me know. regards, Rob -- 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 Feb 17 16:59:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12180 for ; Thu, 17 Feb 2005 16:59:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1tYc-000HB4-HT for netconf-data@psg.com; Thu, 17 Feb 2005 21:51:34 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1tYa-000HAi-Nw for netconf@ops.ietf.org; Thu, 17 Feb 2005 21:51:32 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id B92C91974CC for ; Thu, 17 Feb 2005 16:34:35 -0500 (EST) 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.0.6603.0 Subject: XML/netconf config of linux based routers Date: Thu, 17 Feb 2005 16:51:32 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E10138A453@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: XML/netconf config of linux based routers Thread-Index: AcUVOtfDwhnLyDqHTWiBmHZJVoG9aQ== From: To: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I am interested in open source implementations of netconf based (or other interesting XML based) approaches for config for linux based routers. Can you provide any pointers, clue, and opinion to albert@research.att.com? -- Albert -- 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 Feb 17 21:03:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10556 for ; Thu, 17 Feb 2005 21:03:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1xKE-000LpN-J5 for netconf-data@psg.com; Fri, 18 Feb 2005 01:52:58 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1xKC-000Lmw-On for netconf@ops.ietf.org; Fri, 18 Feb 2005 01:52:56 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 17 Feb 2005 17:52:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,96,1107763200"; d="scan'208"; a="232843826:sNHT2820564268" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 17:52:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: XML/netconf config of linux based routers Date: Thu, 17 Feb 2005 17:52:54 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440874B575@photon.jnpr.net> Thread-Topic: XML/netconf config of linux based routers Thread-Index: AcUVOtfDwhnLyDqHTWiBmHZJVoG9aQAIEAKw From: "Rob Enns" To: , X-OriginalArrivalTime: 18 Feb 2005 01:52:55.0249 (UTC) FILETIME=[90537410:01C5155C] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable YENCA is an open source netconf implementation with some basic interface and route management: http://sourceforge.net/projects/yenca/=20 Rob > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of=20 > albert@research.att.com > Sent: Thursday, February 17, 2005 1:52 PM > To: netconf@ops.ietf.org > Subject: XML/netconf config of linux based routers >=20 > Hi, >=20 > I am interested in open source implementations of netconf based (or > other interesting XML based) approaches for config for linux based > routers. >=20 > Can you provide any pointers, clue, and opinion to > albert@research.att.com? >=20 > -- Albert >=20 >=20 >=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: >=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 Fri Feb 18 06:28:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20142 for ; Fri, 18 Feb 2005 06:28:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D266N-0002gv-TL for netconf-data@psg.com; Fri, 18 Feb 2005 11:15:15 +0000 Received: from [68.142.200.157] (helo=web30904.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D266M-0002gc-Pb for netconf@ops.ietf.org; Fri, 18 Feb 2005 11:15:15 +0000 Received: (qmail 98986 invoked by uid 60001); 18 Feb 2005 11:15:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=2zpS3cyzw3rg1TwHyENt8tCzLHDw9x7FyOBMparCx6bN6Wix/PLwPAuLvIzwKpTfz3rJ3ZMiEq7DYISxRqSaKpe6QEwddqtE4bA1NOh9ZEUL4qGnJRem3ckryT4HYOCG8/kNH7c7HfXqgzuW7ic4DGLhSzAd1TNzaBa4iy+Kg38= ; Message-ID: <20050218111514.98984.qmail@web30904.mail.mud.yahoo.com> Received: from [128.107.253.42] by web30904.mail.mud.yahoo.com via HTTP; Fri, 18 Feb 2005 03:15:14 PST Date: Fri, 18 Feb 2005 03:15:14 -0800 (PST) From: nag Subject: error-info element does not allow for a bad-attribute child element .. To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, correct me if I am looking at wrong xsd. But, the following declaration does not allow for a bad-attribute or bad-element to be added as a child element to error-info element .. I have an example xml like this: protocol BAD_ATTRIBUTE error type filter ------------- xmlspy gave this validation error message ----- Only text allowed inside element "nc:error-info" I think this requires a change in the xsd. thanks Nag __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.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 Feb 22 14:14:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05652 for ; Tue, 22 Feb 2005 14:14:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3fHg-0009Xo-Ga for netconf-data@psg.com; Tue, 22 Feb 2005 19:01:24 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3fHf-0009XZ-Hi for netconf@ops.ietf.org; Tue, 22 Feb 2005 19:01:23 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2005 12:15:42 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,107,1107734400"; d="scan'208"; a="227898017:sNHT21283804" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1MJ1Gq8007110 for ; Tue, 22 Feb 2005 11:01:17 -0800 (PST) Received: from sberlw2k01 (sjc-vpn4-384.cisco.com [10.21.81.128]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCB01149; Tue, 22 Feb 2005 11:01:18 -0800 (PST) Message-Id: <200502221901.BCB01149@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: xml:lang attribute in netconf schema Date: Tue, 22 Feb 2005 11:01:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUZEON+E5yQXqhFRIiSXOwTbRkMRg== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Looking at http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt Sorry I didn't notice this earlier, but in order to comply with RFC3470 the element should have an xml:lang attribute. This should at least be an optional attribute if an implementation should choose to provide it. The edits would look like: In the example on pg 41 Lock failed, lock is already held Would become Lock failed, lock is already held In the XML schema insert an import for the xml namespace at the top Before: Get access to the xml: attribute groups for xml:lang as declared on 'schema' and 'documentation' below After: Get access to the xml: attribute groups for xml:lang as declared on 'schema' and 'documentation' below And finally Should become: -- 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 Feb 25 18:01:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11173 for ; Fri, 25 Feb 2005 18:01:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4oH5-000JM5-92 for netconf-data@psg.com; Fri, 25 Feb 2005 22:49:31 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3KVJ-000Gh8-G8 for netconf@ops.ietf.org; Mon, 21 Feb 2005 20:50:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13746; Mon, 21 Feb 2005 15:50:03 -0500 (EST) Message-Id: <200502212050.PAA13746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-05.txt Date: Mon, 21 Feb 2005 15:50:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Configuration Protocol Author(s) : R. Enns Filename : draft-ietf-netconf-prot-05.txt Pages : 87 Date : 2005-2-21 The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple RPC layer. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html 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-ietf-netconf-prot-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21151859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151859.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Feb 25 18:06:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11593 for ; Fri, 25 Feb 2005 18:06:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4oP7-000KZ1-Fk for netconf-data@psg.com; Fri, 25 Feb 2005 22:57:49 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3hEC-0003nl-9H for netconf@ops.ietf.org; Tue, 22 Feb 2005 21:05:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21587; Tue, 22 Feb 2005 16:05:53 -0500 (EST) Message-Id: <200502222105.QAA21587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-ssh-03.txt Date: Tue, 22 Feb 2005 16:05:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-ssh-03.txt Pages : 10 Date : 2005-2-22 This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-ssh-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html 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-ietf-netconf-ssh-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-ssh-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-ssh-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160530.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Feb 28 17:25:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14710 for ; Mon, 28 Feb 2005 17:25:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5tBi-000C81-N3 for netconf-data@psg.com; Mon, 28 Feb 2005 22:16:26 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D5tBh-000C7h-Q6 for netconf@ops.ietf.org; Mon, 28 Feb 2005 22:16:26 +0000 Received: (qmail 31870 invoked by uid 78); 28 Feb 2005 22:16:24 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.219.40) by mail.networksolutionsemail.com with SMTP; 28 Feb 2005 22:16:24 -0000 Message-Id: <6.2.1.2.0.20050228141036.021b9558@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 28 Feb 2005 14:16:23 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Begin WG Last Call: draft-ietf-netconf-beep-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The NETCONF WG has completed work on the document "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)". The WG proposes that the Internet draft 'draft-ietf-netconf-beep-03.txt' is the completed version of this document. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-03.txt The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in an email to the NETCONF WG mailing list. Unless there are strong objections, published on the NETCONF WG mailing list by March 18, 2005, this document will be forwarded to the OPS Area Directors for standards track consideration by the IESG. Please send all comments to the WG mailing list at netconf@ops.ietf.org. Andy and 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 Feb 28 17:26:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14741 for ; Mon, 28 Feb 2005 17:26:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5tBp-000C8h-Qt for netconf-data@psg.com; Mon, 28 Feb 2005 22:16:33 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D5tBo-000C8T-Uy for netconf@ops.ietf.org; Mon, 28 Feb 2005 22:16:33 +0000 Received: (qmail 32023 invoked by uid 78); 28 Feb 2005 22:16:32 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.219.40) by mail.networksolutionsemail.com with SMTP; 28 Feb 2005 22:16:32 -0000 Message-Id: <6.2.1.2.0.20050228141231.0225a5a8@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 28 Feb 2005 14:16:30 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Begin WG Last Call: draft-ietf-netconf-soap-04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The NETCONF WG has completed work on the document "Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)". The WG proposes that the Internet draft 'draft-ietf-netconf-soap-04.txt' is the completed version of this document. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-04.txt The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in an email to the NETCONF WG mailing list. Unless there are strong objections, published on the NETCONF WG mailing list by March 18, 2005, this document will be forwarded to the OPS Area Directors for standards track consideration by the IESG. Please send all comments to the WG mailing list at netconf@ops.ietf.org. Andy and 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 Feb 28 17:26:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14778 for ; Mon, 28 Feb 2005 17:26:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5tBf-000C7W-Q5 for netconf-data@psg.com; Mon, 28 Feb 2005 22:16:23 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D5tBc-000C7F-Nx for netconf@ops.ietf.org; Mon, 28 Feb 2005 22:16:20 +0000 Received: (qmail 11824 invoked by uid 78); 28 Feb 2005 22:16:15 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.219.40) by mail.networksolutionsemail.com with SMTP; 28 Feb 2005 22:16:15 -0000 Message-Id: <6.2.1.2.0.20050228140806.02250068@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 28 Feb 2005 14:16:14 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Begin WG Last Call: draft-ietf-netconf-prot-05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The NETCONF WG has completed work on the NETCONF Configuration Protocol. The WG proposes that the Internet draft 'draft-ietf-netconf-prot-05.txt' is the completed version of this document. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in an email to the NETCONF WG mailing list. Unless there are strong objections, published on the NETCONF WG mailing list by March 18, 2005, this document will be forwarded to the OPS Area Directors for standards track consideration by the IESG. Please send all comments to the WG mailing list at netconf@ops.ietf.org. Andy and 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 Feb 28 18:19:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14742 for ; Mon, 28 Feb 2005 17:26:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5tCA-000CAh-3N for netconf-data@psg.com; Mon, 28 Feb 2005 22:16:54 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D5tC9-000CAT-96 for netconf@ops.ietf.org; Mon, 28 Feb 2005 22:16:53 +0000 Received: (qmail 32389 invoked by uid 78); 28 Feb 2005 22:16:52 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.219.40) by mail.networksolutionsemail.com with SMTP; 28 Feb 2005 22:16:52 -0000 Message-Id: <6.2.1.2.0.20050228141407.0225f938@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 28 Feb 2005 14:16:51 -0800 To: netconf@ops.ietf.org From: Andy Bierman Subject: Begin WG Last Call: draft-ietf-netconf-ssh-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The NETCONF WG has completed work on the document "Using the NETCONF Configuration Protocol over Secure Shell (SSH)". The WG proposes that the Internet draft 'draft-ietf-netconf-ssh-03.txt' is the completed version of this document. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-03.txt The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in an email to the NETCONF WG mailing list. Unless there are strong objections, published on the NETCONF WG mailing list by March 18, 2005, this document will be forwarded to the OPS Area Directors for standards track consideration by the IESG. Please send all comments to the WG mailing list at netconf@ops.ietf.org. Andy and 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: