From owner-netconf@ops.ietf.org  Fri Apr  1 03:47:39 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02956
	for <netconf-archive@lists.ietf.org>; Fri, 1 Apr 2005 03:47:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DHHaj-000LCp-Ud
	for netconf-data@psg.com; Fri, 01 Apr 2005 08:33:21 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DHHag-000LC3-Py
	for netconf@ops.ietf.org; Fri, 01 Apr 2005 08:33:18 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-4.cisco.com with ESMTP; 01 Apr 2005 00:33:19 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j318XFgE001596;
	Fri, 1 Apr 2005 00:33:15 -0800 (PST)
Received: from ajamwalw2k02 (sjc-vpn4-405.cisco.com [10.21.81.149])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with SMTP id BFI85965;
	Fri, 1 Apr 2005 00:33:14 -0800 (PST)
Message-ID: <005f01c53695$72a17ca0$210110ac@amer.cisco.com>
Reply-To: "Arvind Jamwal" <ajamwal@cisco.com>
From: "Arvind Jamwal" <ajamwal@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "'Eliot Lear'" <lear@cisco.com>, <sberl@cisco.com>,
        "'netconf'" <netconf@ops.ietf.org>
References: <200503311932.BFI15128@mira-sjc5-c.cisco.com> <424C5DDC.9030007@andybierman.com>
Subject: Re: latest beep draft
Date: Fri, 1 Apr 2005 00:33:14 -0800
Organization: Cisco Systems Inc.
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 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
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

Sure, <session-id> would do the trick but I hate the idea of having xml
elements with overloaded meanings.

Also, I was wondering how you will define a common XML schema for the hello
message?
For the agent, <session-id> element is required and for the manager it is an
error to include it.

Having a role element will help.

-Arvind

----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: <ajamwal@cisco.com>
Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
<netconf@ops.ietf.org>
Sent: Thursday, March 31, 2005 12:30 PM
Subject: Re: latest beep draft


> Arvind Jamwal wrote:
>
> >Hi Andy,
> >
> >Would it make sense to specify the role as part of the hello message
rather
> >than relying on the presense/absense of session-id element?
> >
> >
> Why?
> Can you think of a reason why the <session-id> can't be used?
> By design, the agent gives out the session ID.  This isn't something
> that can change once decided.
>
> The WG already decided that it would be a very rare case (e.g.,
> misconfiguration)
> in which an agent connects to another agent or mgr to mgr.   And if this
> ever happens,
> the worst case scenario is that it uses up 1 TCP control block on an
> idle connection.
> That's why the #manager and #agent capabilities were removed from an
> early draft.
>
> Andy
>
> >What I am proposing is the following change to the hello message:
> >
> >   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >     <capabilities>
> >       <capability>
> >         urn:ietf:params:xml:ns:netconf:base:1.0
> >       </capability>
> >       ...
> >     </capabilities>
> >     <role>agent</role>         <------- new role element
> >     <session-id>4</session-id>
> >   </hello>
> >
> >Comments?
> >
> >-Arvind Jamwal
> >
> >
> >
> >-----Original Message-----
> >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> >Behalf Of Andy Bierman
> >Sent: Tuesday, March 29, 2005 11:29 AM
> >To: Eliot Lear
> >Cc: sberl@cisco.com; 'netconf'
> >Subject: Re: latest beep draft
> >
> >Eliot Lear wrote:
> >
> >
> >
> >>We talked about this.  A netconf manager is certainly going to know it
> >>is a netconf manager and a netconf agent is certainly going to know
> >>it's a netconf agent.  This leaves two cases:
> >> o where the server is also a client
> >> o where a client is misconfigured
> >>
> >>I think this could be handled with a netconf capability that says
> >>"iam-manager" or "iam-agent", but as I recall consensus was against
> >>me.  Now, I could introduce that concept as an option in the
> >><greeting> in the BEEP protocol mappin if there are no objections.
> >>That would handle the corner case...
> >>
> >>
> >
> >I don't want special-case handling for BEEP.
> >Steve already provided the answer -- only a NETCONF peer acting in the
agent
> >role should send the <session-id> element in the capabilities exchange.
If
> >neither send it or both send it, then the session should be shut down
> >immediately.
> >
> >Andy
> >
> >
> >
> >>Eliot
> >>
> >>Steven Berl (sberl) wrote:
> >>
> >>
> >>
> >>>Not sure if it is too late for comments on this doc, but here it is
> >>>anyway.
> >>>
> >>>Section 2.1 last paragraph
> >>>"it is assumed that each knows its role in the conversation."
> >>>
> >>>What happens when this assumption is wrong? How is it detected, and
> >>>what actions are to be taken?
> >>>
> >>>If I am a manager and I receive a <rpc> from someone I thought was an
> >>>agent, what should I do? Probably close the channel.
> >>>If 2 agents connect to each other, they can exchange <hello> messages
> >>>and then sit there forever waiting for the other to send an <rpc> of
> >>>some sort.
> >>>I suppose the agents could detect this by noticing that the received
> >>><hello> has a <session-id> element, and that only other agents send
> >>>this element.
> >>>The action again should probably be to close the channel.
> >>>
> >>>This situation is specific to BEEP because the SSH mapping specifies
> >>>that only managers can initiate sessions.
> >>>-steve
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> >>>>On Behalf Of Eliot Lear
> >>>>Sent: Tuesday, March 22, 2005 1:24 AM
> >>>>To: netconf
> >>>>Subject: latest beep draft
> >>>>
> >>>>I believe I have addressed issues raised in the WG last call. Can
> >>>>those who had comments (Juergen, Wes) take a quick scan? In
particular:
> >>>>
> >>>> - addressed security issues regarding SASL & TLS
> >>>> - added examples - are these enough?
> >>>> - clarified use of <hello> and <greeting>
> >>>>
> >>>>The draft is at the following URL and is still relatively short:
> >>>>
> >>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt
> >>>>
> >>>>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: <http://ops.ietf.org/lists/netconf/>

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Apr  1 19:00:59 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05241
	for <netconf-archive@lists.ietf.org>; Fri, 1 Apr 2005 19:00:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DHVv5-000Lia-4P
	for netconf-data@psg.com; Fri, 01 Apr 2005 23:51:19 +0000
Received: from [66.92.48.198] (helo=mycroft.greatcircle.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DHVv2-000Lhz-74
	for netconf@ops.ietf.org; Fri, 01 Apr 2005 23:51:16 +0000
Received: from [66.92.48.19] (localhost [127.0.0.1])
	by mycroft.greatcircle.com (Postfix) with ESMTP id 0C48C32C1AD
	for <netconf@ops.ietf.org>; Fri,  1 Apr 2005 15:51:14 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06210209be738d208158@[66.92.48.19]>
Date: Fri, 1 Apr 2005 15:51:12 -0800
To: netconf@ops.ietf.org
From: Brent Chapman <Brent@GreatCircle.COM>
Subject: Forums for discussing network automation?
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=0.0 required=5.0 tests=BAYES_50 autolearn=ham 
	version=3.0.1
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Where do the folks who are going to _use_ the Netconf protocol(s) 
hang out, and discuss their issues and solutions and such?  Where are 
folks discussing network automation in general?  What are the network 
automation equivalents of what http://www.infrastructures.org is for 
sysadmins?  Are there any?


Thanks!

-Brent
-- 
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 09:22:50 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04406
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 09:22:49 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIRQ0-000D6P-KX
	for netconf-data@psg.com; Mon, 04 Apr 2005 13:15:04 +0000
Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DIRPa-000D2u-9T
	for netconf@ops.ietf.org; Mon, 04 Apr 2005 13:14:38 +0000
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j34DEa315138
	for <netconf@ops.ietf.org>; Mon, 4 Apr 2005 09:14:36 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j34DEY910727
	for <netconf@ops.ietf.org>; Mon, 4 Apr 2005 09:14:34 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3R12VC>; Mon, 4 Apr 2005 09:14:35 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402F3B286@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: netconf@ops.ietf.org
Subject: Question: Expected Behaviour when edit-config matches two instanc
	es
Date: Mon, 4 Apr 2005 09:14:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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

Section 6 of the protocol speciation, which discussed subtree filtering,
claims to apply to <get> or <get-config> operation. My question is whether
we expect this behaviour to be different for the <edit-config> command, and
if so, where is this defined?

In particular, if the <edit-config> matches more than once instance of
something, are they both modified or is this an invalid command? If we
follow the model in 6, then they are both modified. If the command is
instead invalid, is this because 1) I did not provide the entire record, 2)
because it matched more than one instance at runtime or 3) because of some
yet to be defined concept of a key?

Given a bit of XML that looks like

<grommets>
<grommet>
  <foo> 12</foo>
  <bar> 1 </bar>
  <state> up </state>
</grommet>
<grommet>
   <foo> 12 </foo>
   <bar> 2 </bar>
   <state> up </state>
</grommet>
<grommets>

and we send the following command

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <grommets>
               <grommet>
                 <foo>12</foo>
                 <state>down</state>
               </grommet>
             </grommets>
           </top>
         </config>
       </edit-config>
     </rpc>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 10:38:48 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13909
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 10:38:47 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIScj-000NCV-NV
	for netconf-data@psg.com; Mon, 04 Apr 2005 14:32:17 +0000
Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com)
	by psg.com with smtp (Exim 4.44 (FreeBSD))
	id 1DISch-000NC6-FG
	for netconf@ops.ietf.org; Mon, 04 Apr 2005 14:32:15 +0000
Received: (qmail 4795 invoked by uid 78); 4 Apr 2005 14:32:09 -0000
Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209)
  by mail.networksolutionsemail.com with SMTP; 4 Apr 2005 14:32:09 -0000
Message-ID: <42514FE6.4040709@andybierman.com>
Date: Mon, 04 Apr 2005 07:32:06 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: netconf@ops.ietf.org
Subject: Re: Question: Expected Behaviour when edit-config matches two instanc
 es
References: <713043CE8B8E1348AF3C546DBE02C1B402F3B286@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402F3B286@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Sharon Chisholm wrote:

>hi
>
>Section 6 of the protocol speciation, which discussed subtree filtering,
>claims to apply to <get> or <get-config> operation. My question is whether
>we expect this behaviour to be different for the <edit-config> command, and
>if so, where is this defined?
>  
>
The filtering doesn't apply to edit-config.
The data models used in edit-config must exactly match some schema
(outside the scope of the current charter).  It depends on the data model
semantics whether or not "wildcard via omission" is a feature or a bug.
IMO, it's a bug and an NMS must provide all the required instance 
identifiers
or the agent returns an error.

Andy

>In particular, if the <edit-config> matches more than once instance of
>something, are they both modified or is this an invalid command? If we
>follow the model in 6, then they are both modified. If the command is
>instead invalid, is this because 1) I did not provide the entire record, 2)
>because it matched more than one instance at runtime or 3) because of some
>yet to be defined concept of a key?
>
>Given a bit of XML that looks like
>
><grommets>
><grommet>
>  <foo> 12</foo>
>  <bar> 1 </bar>
>  <state> up </state>
></grommet>
><grommet>
>   <foo> 12 </foo>
>   <bar> 2 </bar>
>   <state> up </state>
></grommet>
><grommets>
>
>and we send the following command
>
>     <rpc message-id="101"
>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>       <edit-config>
>         <target>
>           <running/>
>         </target>
>         <config>
>           <top xmlns="http://example.com/schema/1.2/config">
>             <grommets>
>               <grommet>
>                 <foo>12</foo>
>                 <state>down</state>
>               </grommet>
>             </grommets>
>           </top>
>         </config>
>       </edit-config>
>     </rpc>
>
>Sharon Chisholm
>Nortel 
>Ottawa, Ontario
>Canada
>
>--
>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: <http://ops.ietf.org/lists/netconf/>
>
>
>  
>


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 15:53: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 PAA20480
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 15:53:34 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIXVr-000AFx-VJ
	for netconf-data@psg.com; Mon, 04 Apr 2005 19:45:31 +0000
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DIXVm-000AFV-Ot
	for netconf@ops.ietf.org; Mon, 04 Apr 2005 19:45:26 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-1.cisco.com with ESMTP; 04 Apr 2005 12:43:51 -0700
X-IronPort-AV: i="3.91,147,1110182400"; 
   d="scan'208"; a="625538065:sNHT63006173904"
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 j34JhlZV002661;
	Mon, 4 Apr 2005 12:43:48 -0700 (PDT)
Received: from ajamwalw2k02 (sjc-vpn5-373.cisco.com [10.21.89.117])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with SMTP id BFK94656;
	Mon, 4 Apr 2005 12:43:46 -0700 (PDT)
Message-ID: <006b01c5394e$9ddf3310$220110ac@amer.cisco.com>
Reply-To: "Arvind Jamwal" <ajamwal@cisco.com>
From: "Arvind Jamwal" <ajamwal@cisco.com>
To: "Arvind Jamwal" <ajamwal@cisco.com>, "Andy Bierman" <ietf@andybierman.com>
Cc: "'Eliot Lear'" <lear@cisco.com>, <sberl@cisco.com>,
        "'netconf'" <netconf@ops.ietf.org>
References: <200503311932.BFI15128@mira-sjc5-c.cisco.com> <424C5DDC.9030007@andybierman.com> <005f01c53695$72a17ca0$210110ac@amer.cisco.com>
Subject: Re: latest beep draft
Date: Mon, 4 Apr 2005 12:43:46 -0700
Organization: Cisco Systems Inc.
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 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
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

Hi Andy,

To make my point clear...

If we were to use just the <session-id>, then the schema for hello message
will have to be:

     <!--
       <hello> element
       -->
     <xs:complexType name="helloType">
       <xs:sequence>
         <xs:element ref="capability"/>
         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
       </xs:sequence>
     </xs:complexType>
     <xs:element name="hello" type="helloType"/>

  With the above schema constraint, the node has no way to guess if
  the session-id was omitted by error or by intention (becasue the peer is a
manager).

  But, with the following schema constraint, the node will always know the
peer's role (manager/agent)
  and can give an error if <session-id> was omitted for the agent role.

     <!--
       <hello> element
       -->
     <xs:complexType name="helloType">
       <xs:sequence>
         <xs:element ref="capability"/>
         <xs:element ref="role" minOccurs="1" maxOccurs="1"/>
         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
       </xs:sequence>
     </xs:complexType>
     <xs:element name="hello" type="helloType"/>

Thoughts?
-Arvind


----- Original Message -----
From: "Arvind Jamwal" <ajamwal@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
<netconf@ops.ietf.org>
Sent: Friday, April 01, 2005 1:33 AM
Subject: Re: latest beep draft


> Sure, <session-id> would do the trick but I hate the idea of having xml
> elements with overloaded meanings.
>
> Also, I was wondering how you will define a common XML schema for the
hello
> message?
> For the agent, <session-id> element is required and for the manager it is
an
> error to include it.
>
> Having a role element will help.
>
> -Arvind
>
> ----- Original Message -----
> From: "Andy Bierman" <ietf@andybierman.com>
> To: <ajamwal@cisco.com>
> Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
> <netconf@ops.ietf.org>
> Sent: Thursday, March 31, 2005 12:30 PM
> Subject: Re: latest beep draft
>
>
> > Arvind Jamwal wrote:
> >
> > >Hi Andy,
> > >
> > >Would it make sense to specify the role as part of the hello message
> rather
> > >than relying on the presense/absense of session-id element?
> > >
> > >
> > Why?
> > Can you think of a reason why the <session-id> can't be used?
> > By design, the agent gives out the session ID.  This isn't something
> > that can change once decided.
> >
> > The WG already decided that it would be a very rare case (e.g.,
> > misconfiguration)
> > in which an agent connects to another agent or mgr to mgr.   And if this
> > ever happens,
> > the worst case scenario is that it uses up 1 TCP control block on an
> > idle connection.
> > That's why the #manager and #agent capabilities were removed from an
> > early draft.
> >
> > Andy
> >
> > >What I am proposing is the following change to the hello message:
> > >
> > >   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >     <capabilities>
> > >       <capability>
> > >         urn:ietf:params:xml:ns:netconf:base:1.0
> > >       </capability>
> > >       ...
> > >     </capabilities>
> > >     <role>agent</role>         <------- new role element
> > >     <session-id>4</session-id>
> > >   </hello>
> > >
> > >Comments?
> > >
> > >-Arvind Jamwal
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> > >Behalf Of Andy Bierman
> > >Sent: Tuesday, March 29, 2005 11:29 AM
> > >To: Eliot Lear
> > >Cc: sberl@cisco.com; 'netconf'
> > >Subject: Re: latest beep draft
> > >
> > >Eliot Lear wrote:
> > >
> > >
> > >
> > >>We talked about this.  A netconf manager is certainly going to know it
> > >>is a netconf manager and a netconf agent is certainly going to know
> > >>it's a netconf agent.  This leaves two cases:
> > >> o where the server is also a client
> > >> o where a client is misconfigured
> > >>
> > >>I think this could be handled with a netconf capability that says
> > >>"iam-manager" or "iam-agent", but as I recall consensus was against
> > >>me.  Now, I could introduce that concept as an option in the
> > >><greeting> in the BEEP protocol mappin if there are no objections.
> > >>That would handle the corner case...
> > >>
> > >>
> > >
> > >I don't want special-case handling for BEEP.
> > >Steve already provided the answer -- only a NETCONF peer acting in the
> agent
> > >role should send the <session-id> element in the capabilities exchange.
> If
> > >neither send it or both send it, then the session should be shut down
> > >immediately.
> > >
> > >Andy
> > >
> > >
> > >
> > >>Eliot
> > >>
> > >>Steven Berl (sberl) wrote:
> > >>
> > >>
> > >>
> > >>>Not sure if it is too late for comments on this doc, but here it is
> > >>>anyway.
> > >>>
> > >>>Section 2.1 last paragraph
> > >>>"it is assumed that each knows its role in the conversation."
> > >>>
> > >>>What happens when this assumption is wrong? How is it detected, and
> > >>>what actions are to be taken?
> > >>>
> > >>>If I am a manager and I receive a <rpc> from someone I thought was an
> > >>>agent, what should I do? Probably close the channel.
> > >>>If 2 agents connect to each other, they can exchange <hello> messages
> > >>>and then sit there forever waiting for the other to send an <rpc> of
> > >>>some sort.
> > >>>I suppose the agents could detect this by noticing that the received
> > >>><hello> has a <session-id> element, and that only other agents send
> > >>>this element.
> > >>>The action again should probably be to close the channel.
> > >>>
> > >>>This situation is specific to BEEP because the SSH mapping specifies
> > >>>that only managers can initiate sessions.
> > >>>-steve
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> > >>>>On Behalf Of Eliot Lear
> > >>>>Sent: Tuesday, March 22, 2005 1:24 AM
> > >>>>To: netconf
> > >>>>Subject: latest beep draft
> > >>>>
> > >>>>I believe I have addressed issues raised in the WG last call. Can
> > >>>>those who had comments (Juergen, Wes) take a quick scan? In
> particular:
> > >>>>
> > >>>> - addressed security issues regarding SASL & TLS
> > >>>> - added examples - are these enough?
> > >>>> - clarified use of <hello> and <greeting>
> > >>>>
> > >>>>The draft is at the following URL and is still relatively short:
> > >>>>
> > >>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt
> > >>>>
> > >>>>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: <http://ops.ietf.org/lists/netconf/>
>
> --
> 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: <http://ops.ietf.org/lists/netconf/>

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 19:17:22 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24035
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 19:17:22 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIajK-000A4I-5l
	for netconf-data@psg.com; Mon, 04 Apr 2005 23:11:38 +0000
Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com)
	by psg.com with smtp (Exim 4.44 (FreeBSD))
	id 1DIajG-000A3n-Re
	for netconf@ops.ietf.org; Mon, 04 Apr 2005 23:11:35 +0000
Received: (qmail 29699 invoked by uid 78); 4 Apr 2005 23:11:30 -0000
Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209)
  by mail.networksolutionsemail.com with SMTP; 4 Apr 2005 23:11:30 -0000
Message-ID: <4251C9A0.1020707@andybierman.com>
Date: Mon, 04 Apr 2005 16:11:28 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arvind Jamwal <ajamwal@cisco.com>
CC: "'Eliot Lear'" <lear@cisco.com>, sberl@cisco.com,
        "'netconf'" <netconf@ops.ietf.org>
Subject: Re: latest beep draft
References: <200503311932.BFI15128@mira-sjc5-c.cisco.com> <424C5DDC.9030007@andybierman.com> <005f01c53695$72a17ca0$210110ac@amer.cisco.com> <006b01c5394e$9ddf3310$220110ac@amer.cisco.com>
In-Reply-To: <006b01c5394e$9ddf3310$220110ac@amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Arvind Jamwal wrote:

>Hi Andy,
>
>To make my point clear...
>
>If we were to use just the <session-id>, then the schema for hello message
>will have to be:
>
>     <!--
>       <hello> element
>       -->
>     <xs:complexType name="helloType">
>       <xs:sequence>
>         <xs:element ref="capability"/>
>         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>       </xs:sequence>
>     </xs:complexType>
>     <xs:element name="hello" type="helloType"/>
>
>  With the above schema constraint, the node has no way to guess if
>  the session-id was omitted by error or by intention (becasue the peer is a
>manager).
>  
>
I don't care that much one way or another.  If the WG wants to add this,
then the WG should speak up.

I don't think this is a very important corner case, since it's based on 
mis-implementation.
We are talking about a fundamental piece of data (session-id).  If an 
agent sends
a hello message that says "I'm an agent" but omits the session-id, then 
the protocol
specification has not been followed and the implementation is broken -- 
it doesn't
matter if the <role> element is there or not.

Andy

>  But, with the following schema constraint, the node will always know the
>peer's role (manager/agent)
>  and can give an error if <session-id> was omitted for the agent role.
>
>     <!--
>       <hello> element
>       -->
>     <xs:complexType name="helloType">
>       <xs:sequence>
>         <xs:element ref="capability"/>
>         <xs:element ref="role" minOccurs="1" maxOccurs="1"/>
>         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>       </xs:sequence>
>     </xs:complexType>
>     <xs:element name="hello" type="helloType"/>
>
>Thoughts?
>-Arvind
>
>
>----- Original Message -----
>From: "Arvind Jamwal" <ajamwal@cisco.com>
>To: "Andy Bierman" <ietf@andybierman.com>
>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
><netconf@ops.ietf.org>
>Sent: Friday, April 01, 2005 1:33 AM
>Subject: Re: latest beep draft
>
>
>  
>
>>Sure, <session-id> would do the trick but I hate the idea of having xml
>>elements with overloaded meanings.
>>
>>Also, I was wondering how you will define a common XML schema for the
>>    
>>
>hello
>  
>
>>message?
>>For the agent, <session-id> element is required and for the manager it is
>>    
>>
>an
>  
>
>>error to include it.
>>
>>Having a role element will help.
>>
>>-Arvind
>>
>>----- Original Message -----
>>From: "Andy Bierman" <ietf@andybierman.com>
>>To: <ajamwal@cisco.com>
>>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
>><netconf@ops.ietf.org>
>>Sent: Thursday, March 31, 2005 12:30 PM
>>Subject: Re: latest beep draft
>>
>>
>>    
>>
>>>Arvind Jamwal wrote:
>>>
>>>      
>>>
>>>>Hi Andy,
>>>>
>>>>Would it make sense to specify the role as part of the hello message
>>>>        
>>>>
>>rather
>>    
>>
>>>>than relying on the presense/absense of session-id element?
>>>>
>>>>
>>>>        
>>>>
>>>Why?
>>>Can you think of a reason why the <session-id> can't be used?
>>>By design, the agent gives out the session ID.  This isn't something
>>>that can change once decided.
>>>
>>>The WG already decided that it would be a very rare case (e.g.,
>>>misconfiguration)
>>>in which an agent connects to another agent or mgr to mgr.   And if this
>>>ever happens,
>>>the worst case scenario is that it uses up 1 TCP control block on an
>>>idle connection.
>>>That's why the #manager and #agent capabilities were removed from an
>>>early draft.
>>>
>>>Andy
>>>
>>>      
>>>
>>>>What I am proposing is the following change to the hello message:
>>>>
>>>>  <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>    <capabilities>
>>>>      <capability>
>>>>        urn:ietf:params:xml:ns:netconf:base:1.0
>>>>      </capability>
>>>>      ...
>>>>    </capabilities>
>>>>    <role>agent</role>         <------- new role element
>>>>    <session-id>4</session-id>
>>>>  </hello>
>>>>
>>>>Comments?
>>>>
>>>>-Arvind Jamwal
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
>>>>Behalf Of Andy Bierman
>>>>Sent: Tuesday, March 29, 2005 11:29 AM
>>>>To: Eliot Lear
>>>>Cc: sberl@cisco.com; 'netconf'
>>>>Subject: Re: latest beep draft
>>>>
>>>>Eliot Lear wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>We talked about this.  A netconf manager is certainly going to know it
>>>>>is a netconf manager and a netconf agent is certainly going to know
>>>>>it's a netconf agent.  This leaves two cases:
>>>>>o where the server is also a client
>>>>>o where a client is misconfigured
>>>>>
>>>>>I think this could be handled with a netconf capability that says
>>>>>"iam-manager" or "iam-agent", but as I recall consensus was against
>>>>>me.  Now, I could introduce that concept as an option in the
>>>>><greeting> in the BEEP protocol mappin if there are no objections.
>>>>>That would handle the corner case...
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I don't want special-case handling for BEEP.
>>>>Steve already provided the answer -- only a NETCONF peer acting in the
>>>>        
>>>>
>>agent
>>    
>>
>>>>role should send the <session-id> element in the capabilities exchange.
>>>>        
>>>>
>>If
>>    
>>
>>>>neither send it or both send it, then the session should be shut down
>>>>immediately.
>>>>
>>>>Andy
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Eliot
>>>>>
>>>>>Steven Berl (sberl) wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Not sure if it is too late for comments on this doc, but here it is
>>>>>>anyway.
>>>>>>
>>>>>>Section 2.1 last paragraph
>>>>>>"it is assumed that each knows its role in the conversation."
>>>>>>
>>>>>>What happens when this assumption is wrong? How is it detected, and
>>>>>>what actions are to be taken?
>>>>>>
>>>>>>If I am a manager and I receive a <rpc> from someone I thought was an
>>>>>>agent, what should I do? Probably close the channel.
>>>>>>If 2 agents connect to each other, they can exchange <hello> messages
>>>>>>and then sit there forever waiting for the other to send an <rpc> of
>>>>>>some sort.
>>>>>>I suppose the agents could detect this by noticing that the received
>>>>>><hello> has a <session-id> element, and that only other agents send
>>>>>>this element.
>>>>>>The action again should probably be to close the channel.
>>>>>>
>>>>>>This situation is specific to BEEP because the SSH mapping specifies
>>>>>>that only managers can initiate sessions.
>>>>>>-steve
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
>>>>>>>On Behalf Of Eliot Lear
>>>>>>>Sent: Tuesday, March 22, 2005 1:24 AM
>>>>>>>To: netconf
>>>>>>>Subject: latest beep draft
>>>>>>>
>>>>>>>I believe I have addressed issues raised in the WG last call. Can
>>>>>>>those who had comments (Juergen, Wes) take a quick scan? In
>>>>>>>              
>>>>>>>
>>particular:
>>    
>>
>>>>>>>- addressed security issues regarding SASL & TLS
>>>>>>>- added examples - are these enough?
>>>>>>>- clarified use of <hello> and <greeting>
>>>>>>>
>>>>>>>The draft is at the following URL and is still relatively short:
>>>>>>>
>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt
>>>>>>>
>>>>>>>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: <http://ops.ietf.org/lists/netconf/>
>>>      
>>>
>>--
>>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: <http://ops.ietf.org/lists/netconf/>
>>    
>>
>
>--
>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: <http://ops.ietf.org/lists/netconf/>
>
>
>  
>


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 19:35:15 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25723
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 19:35:14 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIb1A-000C4c-Bd
	for netconf-data@psg.com; Mon, 04 Apr 2005 23:30:04 +0000
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DIb17-000C3l-02
	for netconf@ops.ietf.org; Mon, 04 Apr 2005 23:30:01 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 04 Apr 2005 16:29:08 -0700
X-IronPort-AV: i="3.91,148,1110182400"; 
   d="scan'208"; a="245439220:sNHT126231404638"
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34NT5Dr021731;
	Mon, 4 Apr 2005 16:29:05 -0700 (PDT)
Received: from ajamwalw2k03 (dhcp-171-71-131-4.cisco.com [171.71.131.4])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BFL25029;
	Mon, 4 Apr 2005 16:29:04 -0700 (PDT)
Message-Id: <200504042329.BFL25029@mira-sjc5-c.cisco.com>
Reply-To: <ajamwal@cisco.com>
From: "Arvind Jamwal" <ajamwal@cisco.com>
To: "'Andy Bierman'" <ietf@andybierman.com>
Cc: "'Eliot Lear'" <lear@cisco.com>, <sberl@cisco.com>,
        "'netconf'" <netconf@ops.ietf.org>
Subject: RE: latest beep draft
Date: Mon, 4 Apr 2005 16:29:03 -0700
Organization: Cisco Systems Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Thread-Index: AcU5bA+LVPPh6nXpT8uBYDqpM1sZbwAAQwVA
In-Reply-To: <4251C9A0.1020707@andybierman.com>
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

 

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Monday, April 04, 2005 4:11 PM
To: Arvind Jamwal
Cc: 'Eliot Lear'; sberl@cisco.com; 'netconf'
Subject: Re: latest beep draft

Arvind Jamwal wrote:

>Hi Andy,
>
>To make my point clear...
>
>If we were to use just the <session-id>, then the schema for hello 
>message will have to be:
>
>     <!--
>       <hello> element
>       -->
>     <xs:complexType name="helloType">
>       <xs:sequence>
>         <xs:element ref="capability"/>
>         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>       </xs:sequence>
>     </xs:complexType>
>     <xs:element name="hello" type="helloType"/>
>
>  With the above schema constraint, the node has no way to guess if
>  the session-id was omitted by error or by intention (becasue the peer 
>is a manager).
>  
>
I don't care that much one way or another.  If the WG wants to add this,
then the WG should speak up.

I don't think this is a very important corner case, since it's based on
mis-implementation.
We are talking about a fundamental piece of data (session-id).  If an agent
sends a hello message that says "I'm an agent" 

How does the hello message say that?

but omits the session-id, then the protocol specification has not been
followed and the implementation is broken -- it doesn't matter if the <role>
element is there or not.

By omitting the session-id, it is on the contrary saying - "I am a manager".
An error condition conveys an opposite message....that is my whole concern.
And there is no way to catch this error or broken implementation of the
peer, except for maybe timing out.


Andy

>  But, with the following schema constraint, the node will always know 
>the peer's role (manager/agent)
>  and can give an error if <session-id> was omitted for the agent role.
>
>     <!--
>       <hello> element
>       -->
>     <xs:complexType name="helloType">
>       <xs:sequence>
>         <xs:element ref="capability"/>
>         <xs:element ref="role" minOccurs="1" maxOccurs="1"/>
>         <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>       </xs:sequence>
>     </xs:complexType>
>     <xs:element name="hello" type="helloType"/>
>
>Thoughts?
>-Arvind
>
>
>----- Original Message -----
>From: "Arvind Jamwal" <ajamwal@cisco.com>
>To: "Andy Bierman" <ietf@andybierman.com>
>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
><netconf@ops.ietf.org>
>Sent: Friday, April 01, 2005 1:33 AM
>Subject: Re: latest beep draft
>
>
>  
>
>>Sure, <session-id> would do the trick but I hate the idea of having 
>>xml elements with overloaded meanings.
>>
>>Also, I was wondering how you will define a common XML schema for the
>>    
>>
>hello
>  
>
>>message?
>>For the agent, <session-id> element is required and for the manager it 
>>is
>>    
>>
>an
>  
>
>>error to include it.
>>
>>Having a role element will help.
>>
>>-Arvind
>>
>>----- Original Message -----
>>From: "Andy Bierman" <ietf@andybierman.com>
>>To: <ajamwal@cisco.com>
>>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
>><netconf@ops.ietf.org>
>>Sent: Thursday, March 31, 2005 12:30 PM
>>Subject: Re: latest beep draft
>>
>>
>>    
>>
>>>Arvind Jamwal wrote:
>>>
>>>      
>>>
>>>>Hi Andy,
>>>>
>>>>Would it make sense to specify the role as part of the hello message
>>>>        
>>>>
>>rather
>>    
>>
>>>>than relying on the presense/absense of session-id element?
>>>>
>>>>
>>>>        
>>>>
>>>Why?
>>>Can you think of a reason why the <session-id> can't be used?
>>>By design, the agent gives out the session ID.  This isn't something 
>>>that can change once decided.
>>>
>>>The WG already decided that it would be a very rare case (e.g.,
>>>misconfiguration)
>>>in which an agent connects to another agent or mgr to mgr.   And if this
>>>ever happens,
>>>the worst case scenario is that it uses up 1 TCP control block on an 
>>>idle connection.
>>>That's why the #manager and #agent capabilities were removed from an 
>>>early draft.
>>>
>>>Andy
>>>
>>>      
>>>
>>>>What I am proposing is the following change to the hello message:
>>>>
>>>>  <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>    <capabilities>
>>>>      <capability>
>>>>        urn:ietf:params:xml:ns:netconf:base:1.0
>>>>      </capability>
>>>>      ...
>>>>    </capabilities>
>>>>    <role>agent</role>         <------- new role element
>>>>    <session-id>4</session-id>
>>>>  </hello>
>>>>
>>>>Comments?
>>>>
>>>>-Arvind Jamwal
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] 
>>>>On Behalf Of Andy Bierman
>>>>Sent: Tuesday, March 29, 2005 11:29 AM
>>>>To: Eliot Lear
>>>>Cc: sberl@cisco.com; 'netconf'
>>>>Subject: Re: latest beep draft
>>>>
>>>>Eliot Lear wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>We talked about this.  A netconf manager is certainly going to know 
>>>>>it is a netconf manager and a netconf agent is certainly going to 
>>>>>know it's a netconf agent.  This leaves two cases:
>>>>>o where the server is also a client o where a client is 
>>>>>misconfigured
>>>>>
>>>>>I think this could be handled with a netconf capability that says 
>>>>>"iam-manager" or "iam-agent", but as I recall consensus was against 
>>>>>me.  Now, I could introduce that concept as an option in the 
>>>>><greeting> in the BEEP protocol mappin if there are no objections.
>>>>>That would handle the corner case...
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I don't want special-case handling for BEEP.
>>>>Steve already provided the answer -- only a NETCONF peer acting in 
>>>>the
>>>>        
>>>>
>>agent
>>    
>>
>>>>role should send the <session-id> element in the capabilities exchange.
>>>>        
>>>>
>>If
>>    
>>
>>>>neither send it or both send it, then the session should be shut 
>>>>down immediately.
>>>>
>>>>Andy
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Eliot
>>>>>
>>>>>Steven Berl (sberl) wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Not sure if it is too late for comments on this doc, but here it 
>>>>>>is anyway.
>>>>>>
>>>>>>Section 2.1 last paragraph
>>>>>>"it is assumed that each knows its role in the conversation."
>>>>>>
>>>>>>What happens when this assumption is wrong? How is it detected, 
>>>>>>and what actions are to be taken?
>>>>>>
>>>>>>If I am a manager and I receive a <rpc> from someone I thought was 
>>>>>>an agent, what should I do? Probably close the channel.
>>>>>>If 2 agents connect to each other, they can exchange <hello> 
>>>>>>messages and then sit there forever waiting for the other to send 
>>>>>>an <rpc> of some sort.
>>>>>>I suppose the agents could detect this by noticing that the 
>>>>>>received <hello> has a <session-id> element, and that only other 
>>>>>>agents send this element.
>>>>>>The action again should probably be to close the channel.
>>>>>>
>>>>>>This situation is specific to BEEP because the SSH mapping 
>>>>>>specifies that only managers can initiate sessions.
>>>>>>-steve
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: owner-netconf@ops.ietf.org 
>>>>>>>[mailto:owner-netconf@ops.ietf.org]
>>>>>>>On Behalf Of Eliot Lear
>>>>>>>Sent: Tuesday, March 22, 2005 1:24 AM
>>>>>>>To: netconf
>>>>>>>Subject: latest beep draft
>>>>>>>
>>>>>>>I believe I have addressed issues raised in the WG last call. Can 
>>>>>>>those who had comments (Juergen, Wes) take a quick scan? In
>>>>>>>              
>>>>>>>
>>particular:
>>    
>>
>>>>>>>- addressed security issues regarding SASL & TLS
>>>>>>>- added examples - are these enough?
>>>>>>>- clarified use of <hello> and <greeting>
>>>>>>>
>>>>>>>The draft is at the following URL and is still relatively short:
>>>>>>>
>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.tx
>>>>>>>t
>>>>>>>
>>>>>>>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: <http://ops.ietf.org/lists/netconf/>
>>>      
>>>
>>--
>>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: <http://ops.ietf.org/lists/netconf/>
>>    
>>
>
>--
>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: <http://ops.ietf.org/lists/netconf/>
>
>
>  
>

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr  4 22:32:53 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08119
	for <netconf-archive@lists.ietf.org>; Mon, 4 Apr 2005 22:32:52 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIdlR-0007Dq-Me
	for netconf-data@psg.com; Tue, 05 Apr 2005 02:26:01 +0000
Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com)
	by psg.com with smtp (Exim 4.44 (FreeBSD))
	id 1DIdlO-0007DW-4z
	for netconf@ops.ietf.org; Tue, 05 Apr 2005 02:25:58 +0000
Received: (qmail 28711 invoked by uid 78); 5 Apr 2005 02:25:57 -0000
Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209)
  by mail.networksolutionsemail.com with SMTP; 5 Apr 2005 02:25:57 -0000
Message-ID: <4251F732.80200@andybierman.com>
Date: Mon, 04 Apr 2005 19:25:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ajamwal@cisco.com
CC: "'Eliot Lear'" <lear@cisco.com>, sberl@cisco.com,
        "'netconf'" <netconf@ops.ietf.org>
Subject: Re: latest beep draft
References: <200504042329.BFL25029@mira-sjc5-c.cisco.com>
In-Reply-To: <200504042329.BFL25029@mira-sjc5-c.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Arvind Jamwal wrote:

> 
>
>-----Original Message-----
>From: Andy Bierman [mailto:ietf@andybierman.com] 
>Sent: Monday, April 04, 2005 4:11 PM
>To: Arvind Jamwal
>Cc: 'Eliot Lear'; sberl@cisco.com; 'netconf'
>Subject: Re: latest beep draft
>
>Arvind Jamwal wrote:
>
>  
>
>>Hi Andy,
>>
>>To make my point clear...
>>
>>If we were to use just the <session-id>, then the schema for hello 
>>message will have to be:
>>
>>    <!--
>>      <hello> element
>>      -->
>>    <xs:complexType name="helloType">
>>      <xs:sequence>
>>        <xs:element ref="capability"/>
>>        <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>>      </xs:sequence>
>>    </xs:complexType>
>>    <xs:element name="hello" type="helloType"/>
>>
>> With the above schema constraint, the node has no way to guess if
>> the session-id was omitted by error or by intention (becasue the peer 
>>is a manager).
>> 
>>
>>    
>>
>I don't care that much one way or another.  If the WG wants to add this,
>then the WG should speak up.
>
>I don't think this is a very important corner case, since it's based on
>mis-implementation.
>We are talking about a fundamental piece of data (session-id).  If an agent
>sends a hello message that says "I'm an agent" 
>
>How does the hello message say that?
>
>but omits the session-id, then the protocol specification has not been
>followed and the implementation is broken -- it doesn't matter if the <role>
>element is there or not.
>
>By omitting the session-id, it is on the contrary saying - "I am a manager".
>An error condition conveys an opposite message....that is my whole concern.
>And there is no way to catch this error or broken implementation of the
>peer, except for maybe timing out.
>  
>
I think you are making my point.
The agent always sends a session-id in its hello message.
The manager never sends a session-id in its hello message.
Anything else is broken.  The addition of a 'role' element has
no impact on the problem. (Simple boolean logic).   In fact, anything you
can possibly add can be mis-implemented in such a way as to not fix this 
minor problem.

A corner-case deadlock could exist where a dual-role entity connects to 
another
dual-role entity and both of them are waiting for the other to send
their hello message to decide if they should respond as an agent or a 
manager.
The 'role' element doesn't help here.  The solution is to force the 
connection
initiator to pick a role and send the appropriate hello.  The SW that is 
initiating
the connection better know why, and it can pick agent or manager.

>
>Andy
>  
>
Andy

>  
>
>> But, with the following schema constraint, the node will always know 
>>the peer's role (manager/agent)
>> and can give an error if <session-id> was omitted for the agent role.
>>
>>    <!--
>>      <hello> element
>>      -->
>>    <xs:complexType name="helloType">
>>      <xs:sequence>
>>        <xs:element ref="capability"/>
>>        <xs:element ref="role" minOccurs="1" maxOccurs="1"/>
>>        <xs:element ref="session-id" minOccurs="0" maxOccurs="1"/>
>>      </xs:sequence>
>>    </xs:complexType>
>>    <xs:element name="hello" type="helloType"/>
>>
>>Thoughts?
>>-Arvind
>>
>>
>>----- Original Message -----
>>From: "Arvind Jamwal" <ajamwal@cisco.com>
>>To: "Andy Bierman" <ietf@andybierman.com>
>>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
>><netconf@ops.ietf.org>
>>Sent: Friday, April 01, 2005 1:33 AM
>>Subject: Re: latest beep draft
>>
>>
>> 
>>
>>    
>>
>>>Sure, <session-id> would do the trick but I hate the idea of having 
>>>xml elements with overloaded meanings.
>>>
>>>Also, I was wondering how you will define a common XML schema for the
>>>   
>>>
>>>      
>>>
>>hello
>> 
>>
>>    
>>
>>>message?
>>>For the agent, <session-id> element is required and for the manager it 
>>>is
>>>   
>>>
>>>      
>>>
>>an
>> 
>>
>>    
>>
>>>error to include it.
>>>
>>>Having a role element will help.
>>>
>>>-Arvind
>>>
>>>----- Original Message -----
>>>From: "Andy Bierman" <ietf@andybierman.com>
>>>To: <ajamwal@cisco.com>
>>>Cc: "'Eliot Lear'" <lear@cisco.com>; <sberl@cisco.com>; "'netconf'"
>>><netconf@ops.ietf.org>
>>>Sent: Thursday, March 31, 2005 12:30 PM
>>>Subject: Re: latest beep draft
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>Arvind Jamwal wrote:
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>Hi Andy,
>>>>>
>>>>>Would it make sense to specify the role as part of the hello message
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>rather
>>>   
>>>
>>>      
>>>
>>>>>than relying on the presense/absense of session-id element?
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>Why?
>>>>Can you think of a reason why the <session-id> can't be used?
>>>>By design, the agent gives out the session ID.  This isn't something 
>>>>that can change once decided.
>>>>
>>>>The WG already decided that it would be a very rare case (e.g.,
>>>>misconfiguration)
>>>>in which an agent connects to another agent or mgr to mgr.   And if this
>>>>ever happens,
>>>>the worst case scenario is that it uses up 1 TCP control block on an 
>>>>idle connection.
>>>>That's why the #manager and #agent capabilities were removed from an 
>>>>early draft.
>>>>
>>>>Andy
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>What I am proposing is the following change to the hello message:
>>>>>
>>>>> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>>   <capabilities>
>>>>>     <capability>
>>>>>       urn:ietf:params:xml:ns:netconf:base:1.0
>>>>>     </capability>
>>>>>     ...
>>>>>   </capabilities>
>>>>>   <role>agent</role>         <------- new role element
>>>>>   <session-id>4</session-id>
>>>>> </hello>
>>>>>
>>>>>Comments?
>>>>>
>>>>>-Arvind Jamwal
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] 
>>>>>On Behalf Of Andy Bierman
>>>>>Sent: Tuesday, March 29, 2005 11:29 AM
>>>>>To: Eliot Lear
>>>>>Cc: sberl@cisco.com; 'netconf'
>>>>>Subject: Re: latest beep draft
>>>>>
>>>>>Eliot Lear wrote:
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>We talked about this.  A netconf manager is certainly going to know 
>>>>>>it is a netconf manager and a netconf agent is certainly going to 
>>>>>>know it's a netconf agent.  This leaves two cases:
>>>>>>o where the server is also a client o where a client is 
>>>>>>misconfigured
>>>>>>
>>>>>>I think this could be handled with a netconf capability that says 
>>>>>>"iam-manager" or "iam-agent", but as I recall consensus was against 
>>>>>>me.  Now, I could introduce that concept as an option in the 
>>>>>><greeting> in the BEEP protocol mappin if there are no objections.
>>>>>>That would handle the corner case...
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>I don't want special-case handling for BEEP.
>>>>>Steve already provided the answer -- only a NETCONF peer acting in 
>>>>>the
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>agent
>>>   
>>>
>>>      
>>>
>>>>>role should send the <session-id> element in the capabilities exchange.
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>If
>>>   
>>>
>>>      
>>>
>>>>>neither send it or both send it, then the session should be shut 
>>>>>down immediately.
>>>>>
>>>>>Andy
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>Eliot
>>>>>>
>>>>>>Steven Berl (sberl) wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Not sure if it is too late for comments on this doc, but here it 
>>>>>>>is anyway.
>>>>>>>
>>>>>>>Section 2.1 last paragraph
>>>>>>>"it is assumed that each knows its role in the conversation."
>>>>>>>
>>>>>>>What happens when this assumption is wrong? How is it detected, 
>>>>>>>and what actions are to be taken?
>>>>>>>
>>>>>>>If I am a manager and I receive a <rpc> from someone I thought was 
>>>>>>>an agent, what should I do? Probably close the channel.
>>>>>>>If 2 agents connect to each other, they can exchange <hello> 
>>>>>>>messages and then sit there forever waiting for the other to send 
>>>>>>>an <rpc> of some sort.
>>>>>>>I suppose the agents could detect this by noticing that the 
>>>>>>>received <hello> has a <session-id> element, and that only other 
>>>>>>>agents send this element.
>>>>>>>The action again should probably be to close the channel.
>>>>>>>
>>>>>>>This situation is specific to BEEP because the SSH mapping 
>>>>>>>specifies that only managers can initiate sessions.
>>>>>>>-steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: owner-netconf@ops.ietf.org 
>>>>>>>>[mailto:owner-netconf@ops.ietf.org]
>>>>>>>>On Behalf Of Eliot Lear
>>>>>>>>Sent: Tuesday, March 22, 2005 1:24 AM
>>>>>>>>To: netconf
>>>>>>>>Subject: latest beep draft
>>>>>>>>
>>>>>>>>I believe I have addressed issues raised in the WG last call. Can 
>>>>>>>>those who had comments (Juergen, Wes) take a quick scan? In
>>>>>>>>             
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>particular:
>>>   
>>>
>>>      
>>>
>>>>>>>>- addressed security issues regarding SASL & TLS
>>>>>>>>- added examples - are these enough?
>>>>>>>>- clarified use of <hello> and <greeting>
>>>>>>>>
>>>>>>>>The draft is at the following URL and is still relatively short:
>>>>>>>>
>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.tx
>>>>>>>>t
>>>>>>>>
>>>>>>>>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: <http://ops.ietf.org/lists/netconf/>
>>>>     
>>>>
>>>>        
>>>>
>>>--
>>>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: <http://ops.ietf.org/lists/netconf/>
>>>   
>>>
>>>      
>>>
>>--
>>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: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> 
>>
>>    
>>
>
>--
>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: <http://ops.ietf.org/lists/netconf/>
>
>
>  
>


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Tue Apr  5 03:12:36 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16946
	for <netconf-archive@lists.ietf.org>; Tue, 5 Apr 2005 03:12:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DIi5x-000GEY-Sm
	for netconf-data@psg.com; Tue, 05 Apr 2005 07:03:29 +0000
Received: from [85.73.163.194] (helo=boskop.local)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DIi5u-000GE7-L3
	for netconf@ops.ietf.org; Tue, 05 Apr 2005 07:03:26 +0000
Received: by boskop.local (Postfix, from userid 501)
	id 55CF9256308; Tue,  5 Apr 2005 09:03:24 +0200 (CEST)
Date: Tue, 5 Apr 2005 09:03:24 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: Arvind Jamwal <ajamwal@cisco.com>, "'Eliot Lear'" <lear@cisco.com>,
        sberl@cisco.com, "'netconf'" <netconf@ops.ietf.org>
Subject: Re: latest beep draft
Message-ID: <20050405070324.GA13493@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	Arvind Jamwal <ajamwal@cisco.com>, 'Eliot Lear' <lear@cisco.com>,
	sberl@cisco.com, 'netconf' <netconf@ops.ietf.org>
References: <200503311932.BFI15128@mira-sjc5-c.cisco.com> <424C5DDC.9030007@andybierman.com> <005f01c53695$72a17ca0$210110ac@amer.cisco.com> <006b01c5394e$9ddf3310$220110ac@amer.cisco.com> <4251C9A0.1020707@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4251C9A0.1020707@andybierman.com>
User-Agent: Mutt/1.5.8i
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

On Mon, Apr 04, 2005 at 04:11:28PM -0700, Andy Bierman wrote:

> I don't care that much one way or another.  If the WG wants to add this,
> then the WG should speak up.

I think it is simply important that the elements of procedure are clearly 
stated somewhere what expected behaviour is. Right now, the ID says:

   A server
   sending the <hello> element MUST include a <session-id> element
   containing the session ID for this NETCONF session.

Perhaps it helps to add a sentence stating that a client who does not
receive a <session-id> and a server receiving a <session-id> must not
continue and close the underlying transport or something like that.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Thu Apr  7 18:05:59 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13204
	for <netconf-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:05:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJf0a-000H6W-K2
	for netconf-data@psg.com; Thu, 07 Apr 2005 21:57:52 +0000
Received: from [66.92.48.198] (helo=mycroft.greatcircle.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DJf0Y-000H6A-K4
	for netconf@ops.ietf.org; Thu, 07 Apr 2005 21:57:50 +0000
Received: from [66.92.48.19] (localhost [127.0.0.1])
	by mycroft.greatcircle.com (Postfix) with ESMTP id 03D9E32C6B0
	for <netconf@ops.ietf.org>; Thu,  7 Apr 2005 14:57:49 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06210269be7b6b3a4580@[66.92.48.19]>
Date: Thu, 7 Apr 2005 14:57:44 -0800
To: netconf@ops.ietf.org
From: Brent Chapman <Brent@GreatCircle.COM>
Subject: Network-Automation discussion mailing list created
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=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.1
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

I've created a Network-Automation mailing list for discussions of 
issues related to automating network configuration and management, 
including (but not limited to) methods, mechanisms, techniques, 
philosophies, policies, and products.

Since 1990 or so, much of the research in the system administration 
field has focused on automation.  It's now well accepted that a 
well-run operation doesn't manage 10,000 servers individually, but 
rather uses tools like cfengine to manage definitions of those 
servers and then create instances of those servers as needed.  In the 
networking world, though, most of us seem to be still manually 
configuring (and reconfiguring) every device.  That's starting to 
change, though, and I've created the Network-Automation mailing list 
as a forum to help advance that change.

See the list's web page for more information, to view archives, or to 
subscribe:

http://www.greatcircle.com/network-automation

I look forward to some interesting discussions there, and I hope 
you'll join us!

-Brent
-- 
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Thu Apr  7 19:09:54 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19218
	for <netconf-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:09:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJg3E-000O40-Hz
	for netconf-data@psg.com; Thu, 07 Apr 2005 23:04:40 +0000
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DJg3D-000O3f-3w
	for netconf@ops.ietf.org; Thu, 07 Apr 2005 23:04:39 +0000
Received: from diotima.switch.ch (localhost [127.0.0.1])
	by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j37N4bLm001015;
	Fri, 8 Apr 2005 01:04:37 +0200 (CEST)
Received: (from leinen@localhost)
	by diotima.switch.ch (8.13.3+Sun/8.13.3/Submit) id j37N4apR001014;
	Fri, 8 Apr 2005 01:04:36 +0200 (CEST)
To: netconf@ops.ietf.org
Subject: [Brent Chapman] Network-Automation discussion mailing list created
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 <simon@limmat.switch.ch>
Date: Fri, 08 Apr 2005 01:04:36 +0200
Message-ID: <aamzsap4sb.fsf@diotima.switch.ch>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
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

--=-=-=

I'm sharing this for your information.  The mailing list hasn't seen
any (non-test) postings yet, so it's perhaps to early to say how
interesting this is, but I like the idea of a forum for users of
network (configuration) automation systems - a week ago, Brent had
asked on this list whether such a forum already existed.  He also runs
a Blog on network automation:

http://www.greatcircle.com/blog/network_automation/

Among other stuff, it contains a note about the NETCONF WG
(http://www.greatcircle.com/blog/2005/03/04/ietf_network_co.html), and
a piece about "reluctance to trust automated network management tools"
(http://www.greatcircle.com/blog/2005/03/07/reluctance_to_t.html) with
some interesting discussion items concerning configuration modeling.
-- 
Simon.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Message-Id: <p06210265be7b6ab225ac@[66.92.48.19]>
Date: Thu, 7 Apr 2005 14:56:44 -0800
To: nanog@merit.edu
From: Brent Chapman <Brent@GreatCircle.COM>
Subject: Network-Automation discussion mailing list created
Sender: owner-nanog@merit.edu
Precedence: bulk
Errors-To: owner-nanog@merit.edu
X-Loop: nanog
MIME-Version: 1.0


I've created a Network-Automation mailing list for discussions of 
issues related to automating network configuration and management, 
including (but not limited to) methods, mechanisms, techniques, 
philosophies, policies, and products.

Since 1990 or so, much of the research in the system administration 
field has focused on automation.  It's now well accepted that a 
well-run operation doesn't manage 10,000 servers individually, but 
rather uses tools like cfengine to manage definitions of those 
servers and then create instances of those servers as needed.  In the 
networking world, though, most of us seem to be still manually 
configuring (and reconfiguring) every device.  That's starting to 
change, though, and I've created the Network-Automation mailing list 
as a forum to help advance that change.

See the list's web page for more information, to view archives, or to 
subscribe:

http://www.greatcircle.com/network-automation

I look forward to some interesting discussions there, and I hope 
you'll join us!

-Brent
-- 
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation


--=-=-=--


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Apr  8 10:42: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 KAA27223
	for <netconf-archive@lists.ietf.org>; Fri, 8 Apr 2005 10:42:16 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJuY8-0001XY-CG
	for netconf-data@psg.com; Fri, 08 Apr 2005 14:33:32 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DJuSI-0000xa-RX
	for netconf@ops.ietf.org; Fri, 08 Apr 2005 14:27:31 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25350;
	Fri, 8 Apr 2005 10:27:27 -0400 (EDT)
Message-Id: <200504081427.KAA25350@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-beep-05.txt
Date: Fri, 08 Apr 2005 10:27:27 -0400
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 Protocol over Blocks Extensible Exchange Protocol (BEEP)
	Author(s)	: E. Lear, K. Crozier
	Filename	: draft-ietf-netconf-beep-05.txt
	Pages		: 14
	Date		: 2005-4-7
	
This document specifies an application protocol mapping for the
NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-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-beep-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-beep-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-4-8105844.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-beep-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-beep-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-4-8105844.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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Apr  8 10:44:01 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27319
	for <netconf-archive@lists.ietf.org>; Fri, 8 Apr 2005 10:43:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJucC-0001tV-PN
	for netconf-data@psg.com; Fri, 08 Apr 2005 14:37:44 +0000
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DJuc0-0001sl-4q
	for netconf@ops.ietf.org; Fri, 08 Apr 2005 14:37:32 +0000
Received: from diotima.switch.ch (localhost [IPv6:::1])
	by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j38EbUrH006445;
	Fri, 8 Apr 2005 16:37:30 +0200 (CEST)
From: Simon Leinen <simon@limmat.switch.ch>
Message-ID: <16982.38698.472123.152740@diotima.switch.ch>
Date: Fri, 8 Apr 2005 16:37:30 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="TmgOHCLnTg"
Content-Transfer-Encoding: 7bit
To: netconf@ops.ietf.org
Subject: IETF62 NETCONF minutes
X-Mailer: VM 7.18 under Emacs 21.3.1
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`
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_00_10,
	HTML_MESSAGE autolearn=no version=3.0.1
Sender: owner-netconf@ops.ietf.org
Precedence: bulk


--TmgOHCLnTg
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

I have just finished the minutes from the last IETF meeting (sorry for
the delay).  They can be found on

  http://www.ops.ietf.org/netconf/62/minutes.html

I'm also attaching them in the original HTML format and converted to
plain text.  If you notice anything strange, please let me know
ASAP... the proceedings submission deadline is in a few hours - so I
have already sent them to the secretariat - but I'll try to get an
update in if necessary.

Regards,
-- 
Simon.

--TmgOHCLnTg
Content-Type: text/html
Content-Description: IETF-62 NETCONF meeting minutes
Content-Disposition: inline;
	filename="minutes.html"
Content-Transfer-Encoding: 7bit

<html>
 <head>
 </head>
 <body>
<h1> NETCONF meeting </h1>

<p> IETF 62, Minneapolis<br>
Tuesday 09.00-11.30 (actually 09.00-10.00)</p>

<p> Chairs: Andy Bierman, Simon Leinen <br>
    Minutes: Simon Leinen <br>
    Jabber scribe: Eliot Lear </p>

<h2> WG Last Call status </h2>

<p> All documents were in Working Group Last Call, lasting until
Friday 18 March (the week after the meeting).  As this was the second
WG Last Call, participants didn't find too many problems with the
drafts in this round.  There have been comments from people trying to
implement the protocol, which can be viewed as a good sign.  The
documents should be ripe for submission to the IESG soon.  Discussion
about individual drafts followed. </p>

<h3> <tt>draft-ietf-netconf-ssh-03.txt</tt> </h3>

<p> Margaret Wasserman, the editor, couldn't be at the meeting because
of other conflicting IETF duties.  The latest revision mainly removed
the option of starting NETCONF from a normal shell session - it must
now be started as a separate <samp>netconf</samp> SSH subsystem. </p>

<p> Wes Hardaker has thoroughly reviewed the draft and posted some
issues to the mailing list.  Margaret will address those issues in a
forthcoming revision. </p>

<p> Simon Leinen had found a small bug in the examples, where the
<samp>C:</samp> (client) and <samp>S:</samp> (server) headers were
inverted.  This should remind participants of the importance of
reviewing the documents for these kinds of problems also. </p>

<h3> <tt>draft-ietf-netconf-beep-03.txt</tt> </h3>

<p> Eliot Lear mentions that J&uuml;rgen Sch&ouml;nw&auml;lder
provided detailed comments on his BEEP mapping draft, and promised a
new BEEP draft based on these.  Required changes include: </p>

<ul>

  <li> Adding some examples </li>
  
  <li> Adding some text on <samp>&lt;hello&gt;</samp>, which was
  missed due to draft skew between the core (-protocol) and -beep
  drafts </li>
  
  <li> Address an issue of J&uuml;rgen's on the SASL/TLS combination -
  after getting J&uuml;rgen to explain these in more detail </li>
  
  <li> Reconsider the "application protocol" terminology, which
  J&uuml;rgen dislikes.  Eliot is looking for suggestions for better
  terms. </li>
  
  <li> Thorough review to make sure the BEEP mapping covers everything
  in the core protocol draft. </li>

</ul>

<h3> Discussion of XML and Schema Definition Issues </h3>

<h4> Schema Strictness Requirements </h4>

<p> Wes asks whether the intent is that an implementor should be able
to use the XSD definitions to do most of the validity checking of
NETCONF requests. </p>

<p> Andy doubts that this is possible, in particular because XSDs
cannot capture the variants related to capabilities. </p>

<h4> XML Directorate Review </h4>

<p> Bert Wijnen, our responsible Area Director, asked (over Jabber)
whether the XML Directorate has been asked to reviewed the documents
for correct XML usage. </p>

<p> Andy states that this has not yet been done, and noted that one of
our authors (Phil Shafer) is on that directorate. </p>

<h3> <tt>draft-ietf-netconf-protocol.txt</tt> </h3>

<p> Rob Enns decided not to show slides about the protocol draft
because they are boring.  Changes from last to current revision: </li>

<ul>

  <li> The many requests for clarifications from the mailing list have
  been addressed. </li>

  <li> All of the closed issues that had come up in the WG Last Call
  have been addressed. </li>

  <li> The change log was simplified because it was getting too
  long. </li>

</ul>

<p> Work is required in the following areas: </p>

<ul>

  <li> Filtering (section 6) - Some people have asked to clarify the
  section that explains how filtering works.  Rob would welcome
  contributions for improved text.  Andy - who had written that
  section - suggests that examples would be particularily useful here,
  and offers Rob his help to make the text more understandable later
  this week. </li>

  <li> Examples in general - Past experience shows that implementors
  often use examples as a main guidance for implementations.
  Therefore, the examples should be given much care, in particular
  their correctness. Rob notes that all the examples in the protocol
  draft have been verified against the RelaxNG version of the NETCONF
  schema. </li>

  <li> Clarify error codes for lock operations - <tt>LOCK_FAILED</tt>
  should be used instead of <tt>IN_USE</tt>. </li>

</ul>

<h3> Secure-Transport Requirement </h3>

<p> John Ng asked about the requirement for secure transports (section
2.2 in the protocol draft), in particular whether it would be possible
to use something like unencrypted telnet in a "secure private network"
environment, or in situations where cryptography cannot be used.  Andy
assumes that security experts would not let a NETCONF proposal pass
without mandatory security.  Bert notes that security is mandatory to
implement, but not mandatory to use. </p>

<h3> Detecting Dead Sessions </h3>

<p> John Ng raises the issue of how an agent notices when a manager
has gone away (so that locks can be released).  Andy says this is
currently indicated by loss of the underlying TCP connection.  John
points out that this fails to distinguish between a manager that has
nothing to say and one that has silently gone away.  Eliot expresses
his hope that someone who is holding a lock wouldn't be idle [but does
that really help here?].  Andy recalls that we had this discussion
before and decided this was a non-problem - hung sessions can be
broken using <samp>&lt;kill-session&gt;</samp>. </p>

<h3> <tt>draft-ietf-netconf-soap-04.txt</tt> </h3>

<p> Ted Goddard, the author, couldn't be at the meeting.  He has
prepared the current revision of the draft in the beginning of
2005 and explained the changes on the list. </p>

<p> Andy notes that it would be interesting to know which lower-layer
mappings are actually supported by NETCONF implementors.
Unfortunately we don't have any data on this. </p>

<h2> "NETCONF 2.0"? </h2>

<p> Since there were no further questions on the current drafts, Andy
suggests to adjourn this part of the meeting to discuss data modeling
issues.  There have been discussions about "NETCONF 2.0" style work,
but it would preferable to have specific drafts as a basis for
discussion, rather than doing this "by committee" in rooms like this.
Andy's suggestion was not followed, however: </p>

<h3> Protocol Extensions such as Notifications </h3>

<p> Eliot asks about the process for defining NETCONF extensions.  A
typical NETCONF extension - for instance, "notifications" - would
require at least two drafts, one that defines the feature and others
defining specific lower-layer mappings.  Andy emphasizes that we
should get over the current deadlock (with respect to notifications)
that different lower layers suggest quite different approaches to an
asynchronous "channel", and at least the SOAP one doesn't seem to
support this at all.  This looks like a tough decision - at one time
we thought about only supporting notifications for specific underlying
protocols (e.g. BEEP), but the WG had decided not to go down that path
because of worries about fragmenting the protocol.  It would be useful
for someone to address this issue in a new draft. </p>

<p> Speaking for a group of NETCONF implementors, J&uuml;rgen Quittek
relates that they feel the lack of notifications to be the most
significant problem.  They consider submitting a draft outlining
possible methods to address notifications.  The open question is
whether to do them within or outside the NETCONF framework; that's
probably the first decision to make. </p>

<p> Sharon Chisholm thinks that we now have a better idea on how
notifications should be done than back when we decided to punt them
for "NETCONF 1.0".  It is important for people to document their
approaches in drafts - ideally before the Paris meeting - so that we
have a basis for discussion, rather than brainstorming here.  A little
discussion ensued between Andy's and Sharon's recollection of why
notifications were postponed.  Andy's view is that the driving factor
was that participants felt they weren't worth the effort, and Sharon
found that the reason was mainly tactical - to get the less
contentious parts out first, although everybody eventually wanted
notifications in NETCONF.  Sharon doesn't think that we have thought
about notifications enough to be able to say that they don't work on
certain transports - she has seen proposals that have very little
transport dependency. </p>

<p> Eliot tries to reformulate his question about the constraints for
extensions and capabilities, again with notifications as the example.
They could be implemented using another channel in both BEEP and SSH,
but the current SSH mapping draft doesn't talk about the ability to
use additional channels.  Another approach would be to to
notifications over a separate TCP connection - they could be encoded
as a large RPC response that could be parsed in an intermediate
("streaming") fashion - this would work over all transports without
modifications to the current mappings. </p>

<p> Remembering previous discussions about notifications, Andy talks
about implementation difficulties with multiple channels, related to
assumptions about locking.  Multiple channels could solve the issue of
mixing normal responses and asynchronous notifications, provided that
there are separate code paths for those at each end.  But at that
point one could ask what this buys us that we cannot already do with
SNMP traps [or notifications]? We didn't start out to replace SNMP
notifications here - let's continue to use those until we figure
NETCONF notifications out. </p>

<h3> General NETCONF Scope Discussion </h3>

<p> Sharon claims that notifications are just a subset of more general
"asynchronous messaging" functionality for applications, many of which
are related to configuration.  Andy is worried about adding to the
standard without clear requirements.  Sharon points to a mailing list
thread about such messages; "configuration change" notifications; and
people looking at asynchronous messages from the monitoring
perspective, as a mechanism for (performance) logging.  To Andy, this
sounds like reinventing IPFIX.  Sending out accounting records is not
a network configuration protocol's job.  Sharon claims there are
applications related to configuration, which will be shown in an
upcoming draft. </p>

<p> Faye Li supports Sharon's point of view.  For configuration, an
audit trail must also be supported.  Operators want to receive a
record for every configuration change. </p>

<p> Dan Romascanu feels like a few years ago, when we were discussing
whether to do configuration or a generic network management protocol.
He disagrees with Sharon's and Faye's point of view.  On the other
hand, he thinks at one point we need a common framework for NETCONF
and SNMP.  Should check whether NETCONF plays nice with any security
solutions that the ISMS WG might come up with. </p>

<p> Andy asks Sharon to issue a draft as a basis for discussion. </p>

<h2> NETMOD </h2>

<p> Passes to Sharon for her presentation on data modeling. </p>

<p> Discussion ended with the suggestion to produce drafts about data
modeling before the Paris meeting, and discuss them there. </p>

<h2> Closing Remarks </h2>

<p> Document authors are expected to produce revised drafts, with the
necessary modifications as discussed here, soon after the I-D queue
opens up after the meeting. </p>

 </body>
</html>

--TmgOHCLnTg
Content-Type: text/plain
Content-Description: IETF-62 NETCONF meeting minutes
Content-Disposition: inline;
	filename="minutes.txt"
Content-Transfer-Encoding: quoted-printable


                                NETCONF meeting

   IETF 62, Minneapolis
   Tuesday 09.00-11.30 (actually 09.00-10.00)

   Chairs: Andy Bierman, Simon Leinen
   Minutes: Simon Leinen
   Jabber scribe: Eliot Lear

WG Last Call status

   All documents were in Working Group Last Call, lasting until Friday =
18
   March (the week after the meeting). As this was the second WG Last
   Call, participants didn't find too many problems with the drafts in
   this round. There have been comments from people trying to implement=

   the protocol, which can be viewed as a good sign. The documents shou=
ld
   be ripe for submission to the IESG soon. Discussion about individual=

   drafts followed.

  draft-ietf-netconf-ssh-03.txt

   Margaret Wasserman, the editor, couldn't be at the meeting because o=
f
   other conflicting IETF duties. The latest revision mainly removed th=
e
   option of starting NETCONF from a normal shell session - it must now=

   be started as a separate netconf SSH subsystem.

   Wes Hardaker has thoroughly reviewed the draft and posted some issue=
s
   to the mailing list. Margaret will address those issues in a
   forthcoming revision.

   Simon Leinen had found a small bug in the examples, where the C:
   (client) and S: (server) headers were inverted. This should remind
   participants of the importance of reviewing the documents for these
   kinds of problems also.

  draft-ietf-netconf-beep-03.txt

   Eliot Lear mentions that J=FCrgen Sch=F6nw=E4lder provided detailed =
comments
   on his BEEP mapping draft, and promised a new BEEP draft based on
   these. Required changes include:
     * Adding some examples
     * Adding some text on <hello>, which was missed due to draft skew
       between the core (-protocol) and -beep drafts
     * Address an issue of J=FCrgen's on the SASL/TLS combination - aft=
er
       getting J=FCrgen to explain these in more detail
     * Reconsider the "application protocol" terminology, which J=FCrge=
n
       dislikes. Eliot is looking for suggestions for better terms.
     * Thorough review to make sure the BEEP mapping covers everything =
in
       the core protocol draft.

  Discussion of XML and Schema Definition Issues

    Schema Strictness Requirements

   Wes asks whether the intent is that an implementor should be able to=

   use the XSD definitions to do most of the validity checking of NETCO=
NF
   requests.

   Andy doubts that this is possible, in particular because XSDs cannot=

   capture the variants related to capabilities.

    XML Directorate Review

   Bert Wijnen, our responsible Area Director, asked (over Jabber)
   whether the XML Directorate has been asked to reviewed the documents=

   for correct XML usage.

   Andy states that this has not yet been done, and noted that one of o=
ur
   authors (Phil Shafer) is on that directorate.

  draft-ietf-netconf-protocol.txt

   Rob Enns decided not to show slides about the protocol draft because=

   they are boring. Changes from last to current revision:
     * The many requests for clarifications from the mailing list have
       been addressed.
     * All of the closed issues that had come up in the WG Last Call ha=
ve
       been addressed.
     * The change log was simplified because it was getting too long.

   Work is required in the following areas:
     * Filtering (section 6) - Some people have asked to clarify the
       section that explains how filtering works. Rob would welcome
       contributions for improved text. Andy - who had written that
       section - suggests that examples would be particularily useful
       here, and offers Rob his help to make the text more understandab=
le
       later this week.
     * Examples in general - Past experience shows that implementors
       often use examples as a main guidance for implementations.
       Therefore, the examples should be given much care, in particular=

       their correctness. Rob notes that all the examples in the protoc=
ol
       draft have been verified against the RelaxNG version of the
       NETCONF schema.
     * Clarify error codes for lock operations - LOCK=5FFAILED should b=
e
       used instead of IN=5FUSE.

  Secure-Transport Requirement

   John Ng asked about the requirement for secure transports (section 2=
.2
   in the protocol draft), in particular whether it would be possible t=
o
   use something like unencrypted telnet in a "secure private network"
   environment, or in situations where cryptography cannot be used. And=
y
   assumes that security experts would not let a NETCONF proposal pass
   without mandatory security. Bert notes that security is mandatory to=

   implement, but not mandatory to use.

  Detecting Dead Sessions

   John Ng raises the issue of how an agent notices when a manager has
   gone away (so that locks can be released). Andy says this is current=
ly
   indicated by loss of the underlying TCP connection. John points out
   that this fails to distinguish between a manager that has nothing to=

   say and one that has silently gone away. Eliot expresses his hope th=
at
   someone who is holding a lock wouldn't be idle [but does that really=

   help here=3F]. Andy recalls that we had this discussion before and
   decided this was a non-problem - hung sessions can be broken using
   <kill-session>.

  draft-ietf-netconf-soap-04.txt

   Ted Goddard, the author, couldn't be at the meeting. He has prepared=

   the current revision of the draft in the beginning of 2005 and
   explained the changes on the list.

   Andy notes that it would be interesting to know which lower-layer
   mappings are actually supported by NETCONF implementors. Unfortunate=
ly
   we don't have any data on this.

"NETCONF 2.0"=3F

   Since there were no further questions on the current drafts, Andy
   suggests to adjourn this part of the meeting to discuss data modelin=
g
   issues. There have been discussions about "NETCONF 2.0" style work,
   but it would preferable to have specific drafts as a basis for
   discussion, rather than doing this "by committee" in rooms like this=
=2E
   Andy's suggestion was not followed, however:

  Protocol Extensions such as Notifications

   Eliot asks about the process for defining NETCONF extensions. A
   typical NETCONF extension - for instance, "notifications" - would
   require at least two drafts, one that defines the feature and others=

   defining specific lower-layer mappings. Andy emphasizes that we shou=
ld
   get over the current deadlock (with respect to notifications) that
   different lower layers suggest quite different approaches to an
   asynchronous "channel", and at least the SOAP one doesn't seem to
   support this at all. This looks like a tough decision - at one time =
we
   thought about only supporting notifications for specific underlying
   protocols (e.g. BEEP), but the WG had decided not to go down that pa=
th
   because of worries about fragmenting the protocol. It would be usefu=
l
   for someone to address this issue in a new draft.

   Speaking for a group of NETCONF implementors, J=FCrgen Quittek relat=
es
   that they feel the lack of notifications to be the most significant
   problem. They consider submitting a draft outlining possible methods=

   to address notifications. The open question is whether to do them
   within or outside the NETCONF framework; that's probably the first
   decision to make.

   Sharon Chisholm thinks that we now have a better idea on how
   notifications should be done than back when we decided to punt them
   for "NETCONF 1.0". It is important for people to document their
   approaches in drafts - ideally before the Paris meeting - so that we=

   have a basis for discussion, rather than brainstorming here. A littl=
e
   discussion ensued between Andy's and Sharon's recollection of why
   notifications were postponed. Andy's view is that the driving factor=

   was that participants felt they weren't worth the effort, and Sharon=

   found that the reason was mainly tactical - to get the less
   contentious parts out first, although everybody eventually wanted
   notifications in NETCONF. Sharon doesn't think that we have thought
   about notifications enough to be able to say that they don't work on=

   certain transports - she has seen proposals that have very little
   transport dependency.

   Eliot tries to reformulate his question about the constraints for
   extensions and capabilities, again with notifications as the example=
=2E
   They could be implemented using another channel in both BEEP and SSH=
,
   but the current SSH mapping draft doesn't talk about the ability to
   use additional channels. Another approach would be to to notificatio=
ns
   over a separate TCP connection - they could be encoded as a large RP=
C
   response that could be parsed in an intermediate ("streaming") fashi=
on
   - this would work over all transports without modifications to the
   current mappings.

   Remembering previous discussions about notifications, Andy talks abo=
ut
   implementation difficulties with multiple channels, related to
   assumptions about locking. Multiple channels could solve the issue o=
f
   mixing normal responses and asynchronous notifications, provided tha=
t
   there are separate code paths for those at each end. But at that poi=
nt
   one could ask what this buys us that we cannot already do with SNMP
   traps [or notifications]=3F We didn't start out to replace SNMP
   notifications here - let's continue to use those until we figure
   NETCONF notifications out.

  General NETCONF Scope Discussion

   Sharon claims that notifications are just a subset of more general
   "asynchronous messaging" functionality for applications, many of whi=
ch
   are related to configuration. Andy is worried about adding to the
   standard without clear requirements. Sharon points to a mailing list=

   thread about such messages; "configuration change" notifications; an=
d
   people looking at asynchronous messages from the monitoring
   perspective, as a mechanism for (performance) logging. To Andy, this=

   sounds like reinventing IPFIX. Sending out accounting records is not=
 a
   network configuration protocol's job. Sharon claims there are
   applications related to configuration, which will be shown in an
   upcoming draft.

   Faye Li supports Sharon's point of view. For configuration, an audit=

   trail must also be supported. Operators want to receive a record for=

   every configuration change.

   Dan Romascanu feels like a few years ago, when we were discussing
   whether to do configuration or a generic network management protocol=
=2E
   He disagrees with Sharon's and Faye's point of view. On the other
   hand, he thinks at one point we need a common framework for NETCONF
   and SNMP. Should check whether NETCONF plays nice with any security
   solutions that the ISMS WG might come up with.

   Andy asks Sharon to issue a draft as a basis for discussion.

NETMOD

   Passes to Sharon for her presentation on data modeling.

   Discussion ended with the suggestion to produce drafts about data
   modeling before the Paris meeting, and discuss them there.

Closing Remarks

   Document authors are expected to produce revised drafts, with the
   necessary modifications as discussed here, soon after the I-D queue
   opens up after the meeting.

--TmgOHCLnTg--


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Apr  8 10:55: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 KAA29376
	for <netconf-archive@lists.ietf.org>; Fri, 8 Apr 2005 10:55:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJunQ-0002xs-GR
	for netconf-data@psg.com; Fri, 08 Apr 2005 14:49:20 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DJunO-0002xY-8n
	for netconf@ops.ietf.org; Fri, 08 Apr 2005 14:49:18 +0000
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-4.cisco.com with ESMTP; 08 Apr 2005 07:49:17 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j38En63S027867
	for <netconf@ops.ietf.org>; Fri, 8 Apr 2005 07:49:06 -0700 (PDT)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4298.cisco.com [10.61.80.201])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j38EeokJ031553
	for <netconf@ops.ietf.org>; Fri, 8 Apr 2005 07:40:51 -0700
Message-ID: <425699E0.6030803@cisco.com>
Date: Fri, 08 Apr 2005 16:49:04 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-netconf-beep-05.txt
References: <200504081427.KAA25350@ietf.org>
In-Reply-To: <200504081427.KAA25350@ietf.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1112971252.192941"; x:"432200"; a:"rsa-sha1"; b:"nofws:3854";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"Yvk5q0Sx3pCLefkaNIv+dVZL6FqZwkWZhn+d5fw/Tg7tp7dVz0GXUJTwKaPKIb7kSt8tg+Da"
	"ubrEUbFMTHRIZpwA5gFqF3YOD2LyIREGGjkMNWNgMbMmd3d6Bg63CFl1PnvZsiH609YpzyBToT6"
	"F6s/3kYD4drVvMgsS/SlGptI=";
	c:"Date: Fri, 08 Apr 2005 16:49:04 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: I-D ACTION:draft-ietf-netconf-beep-05.txt"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
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

The update below contains changes specific to the use of SASL when used 
either with or without TLS.  See "Security Considerations".  Thanks very 
much to Marshall Rose for assisting me.

Eliot

Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Configuration Working Group of the IETF.
> 
> 	Title		: Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)
> 	Author(s)	: E. Lear, K. Crozier
> 	Filename	: draft-ietf-netconf-beep-05.txt
> 	Pages		: 14
> 	Date		: 2005-4-7
> 	
> This document specifies an application protocol mapping for the
> NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-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-beep-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-beep-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.
> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited 
> by this policy. The attachment has been removed from this message and 
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or 
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus 
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: j38EYJEf022146
> 
> If the matter is urgent, you may follow up by calling one of the below 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Apr  8 12:24: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 MAA09440
	for <netconf-archive@lists.ietf.org>; Fri, 8 Apr 2005 12:24:15 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DJw8L-000DHz-02
	for netconf-data@psg.com; Fri, 08 Apr 2005 16:15:01 +0000
Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com)
	by psg.com with smtp (Exim 4.44 (FreeBSD))
	id 1DJw8J-000DHf-L3
	for netconf@ops.ietf.org; Fri, 08 Apr 2005 16:14:59 +0000
Received: (qmail 28626 invoked by uid 78); 8 Apr 2005 16:13:24 -0000
Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209)
  by mail.networksolutionsemail.com with SMTP; 8 Apr 2005 16:13:24 -0000
Message-ID: <4256ADA3.4030204@andybierman.com>
Date: Fri, 08 Apr 2005 09:13:23 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf <netconf@ops.ietf.org>
Subject: document status checkpoint
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Hi,

I'd like to make another push to finish up our documents.
Hello document authors! -- we need updates for everything
except the BEEP draft...

1) NETCONF Protocol

   Rob is waiting for the subtree filtering section to be finalized.
   I posted an update to this section that received no comments, and
   raised 2 issues that received no comments. 

  * I025: Filter by namespace only (retrieve entire data model without
        knowing the top-level element(s))
    Proposed Status: Closed, no changes
    This one I think we should drop.  It's just another feature, and 
we're done
    adding features.

  * I026: subtree filter top-level elements should not be considered in the
    same sibling set.
    Proposed Status: Closed, no changes

    I'm not sure I reverse-engineered the algorithms from the examples 100%
    correctly here.  A content-match node at the top level is problematic,
    as it assumes associations between data models which may not 
actually exist.
    I don't want this paragraph to have big unintended consequences later.
    Except for some esoteric corner-cases of interest to 
conformance-test writers,
    I haven't found any real problems with treating the top level nodes as
    a sibling set.

  Proposed action: Rob will add the latest section 6 update, in addition to
  all the fixes he has been collecting, and publish prot-06 ASAP.  This 
update
  will have a 2 week WGLC because there are several edits.

2) NETCONF over BEEP

Eliot just posted the beep-05 update. (Thanks!)
I don't think there are any open issues in this document.
The changes Eliot made do not seem controversial, so I propose
that we do not need another WGLC.  If there are no objections,
we will consider this document done.

3) NETCONF over SOAP

This document (soap-04) needs to be updated to fix the references to
SOAP over BEEP,  to use the new rfc3288-bis document.  This update uses
SOAP 1.2 instead of  SOAP 1.1.  Unless any other issues are raised
(or other changes made to the update), another WGLC should not be needed
for the soap-05 update. 

4) NETCONF over SSH

I'm not sure what the complete list of edits entails, but the ssh-03 draft
needs some minor corrections.  Unless any other issues are raised
(or other changes made to the update), another WGLC should not be needed
for the ssh-04 update.


--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Sat Apr  9 12:15:36 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17964
	for <netconf-archive@lists.ietf.org>; Sat, 9 Apr 2005 12:15:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DKINM-000GY8-7D
	for netconf-data@psg.com; Sat, 09 Apr 2005 16:00:00 +0000
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DKINB-000GXF-6U
	for netconf@ops.ietf.org; Sat, 09 Apr 2005 15:59:49 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 09 Apr 2005 08:59:49 -0700
X-IronPort-AV: i="3.92,90,1112598000"; 
   d="scan'208"; a="248004440:sNHT27848500"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j39FxegE012815;
	Sat, 9 Apr 2005 08:59:41 -0700 (PDT)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp122.cisco.com [10.61.64.122])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j39FpQW1006668;
	Sat, 9 Apr 2005 08:51:26 -0700
Message-ID: <4257FBEE.90200@cisco.com>
Date: Sat, 09 Apr 2005 17:59:42 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: netconf <netconf@ops.ietf.org>
Subject: Re: document status checkpoint
References: <4256ADA3.4030204@andybierman.com>
In-Reply-To: <4256ADA3.4030204@andybierman.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113061887.589303"; x:"432200"; a:"rsa-sha1"; b:"nofws:130";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"O7vQhG8imBVd57gZx3euw6ZkajFP5oxW37prfhURg3u1R9v9aYXCMsbdxH4OrrdziCqI2xlU"
	"6HiLlqbp3ToECJ7/LZmd5mcKlRS9UJOphipTrdpS0OQT33qaqGhzRTe/KPKlRe0FQd4WHNeB3Nu"
	"ER0bI/sRi1YNs3hudnw8fOmY=";
	c:"Date: Sat, 09 Apr 2005 17:59:42 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: document status checkpoint"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
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

Hi Andy,

At this point I consider the BEEP draft done.  We can hand it to the 
IESG as soon as the Netconf draft is ready.  I agree with your proposed 
actions.

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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr 11 15:56:40 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14692
	for <netconf-archive@lists.ietf.org>; Mon, 11 Apr 2005 15:56:39 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DL4rq-000CLJ-BE
	for netconf-data@psg.com; Mon, 11 Apr 2005 19:46:42 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DL4oV-000C3I-V3
	for netconf@ops.ietf.org; Mon, 11 Apr 2005 19:43:16 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13550;
	Mon, 11 Apr 2005 15:43:13 -0400 (EDT)
Message-Id: <200504111943.PAA13550@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-04.txt
Date: Mon, 11 Apr 2005 15:43:13 -0400
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-04.txt
	Pages		: 10
	Date		: 2005-4-11
	
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-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-ssh-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-ssh-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-4-11161405.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-ssh-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-ssh-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-4-11161405.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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Apr 11 16:02:27 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15766
	for <netconf-archive@lists.ietf.org>; Mon, 11 Apr 2005 16:02:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD))
	id 1DL52I-000Dnw-Ay
	for netconf-data@psg.com; Mon, 11 Apr 2005 19:57:30 +0000
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.44 (FreeBSD))
	id 1DL52G-000Dmq-30
	for netconf@ops.ietf.org; Mon, 11 Apr 2005 19:57:28 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-1.cisco.com with ESMTP; 11 Apr 2005 12:57:28 -0700
X-IronPort-AV: i="3.92,94,1112598000"; 
   d="scan'208"; a="627808208:sNHT32155532"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3BJvM7T010656
	for <netconf@ops.ietf.org>; Mon, 11 Apr 2005 12:57:23 -0700 (PDT)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4194.cisco.com [10.61.80.97])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3BJmvo9020529
	for <netconf@ops.ietf.org>; Mon, 11 Apr 2005 12:48:57 -0700
Message-ID: <425AD6A2.7020903@cisco.com>
Date: Mon, 11 Apr 2005 21:57:22 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-netconf-ssh-04.txt
References: <200504111943.PAA13550@ietf.org>
In-Reply-To: <200504111943.PAA13550@ietf.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113248938.755083"; x:"432200"; a:"rsa-sha1"; b:"nofws:3727";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"O9+W/Jw3p/fP5xdE/QBWTmkS4AZO5gQrwpFpjJNbA6phmc17wMrIhjaPnkWWvFfmphRHjahi"
	"q8R25aTSwvw5FVPbBMrR+1W5liB2LO8c4GrSpTSLQRgfBtOFCAu76Tc5GvYh3BUjHVWzF3lD0qz"
	"qw/QRFi9kDPXuP1fLgUas3eM=";
	c:"Date: Mon, 11 Apr 2005 21:57:22 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: I-D ACTION:draft-ietf-netconf-ssh-04.txt"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
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

This doc looks good to me.

Eliot

Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Configuration Working Group of the IETF.
> 
> 	Title		: Using the NETCONF Configuration Protocol over Secure Shell (SSH)
> 	Author(s)	: M. Wasserman, T. Goddard
> 	Filename	: draft-ietf-netconf-ssh-04.txt
> 	Pages		: 10
> 	Date		: 2005-4-11
> 	
> 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-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-ssh-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-ssh-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.
> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited 
> by this policy. The attachment has been removed from this message and 
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or 
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus 
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: j3BJl4hH003976
> 
> If the matter is urgent, you may follow up by calling one of the below 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

--
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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Tue Apr 26 09:25: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 JAA07336
	for <netconf-archive@lists.ietf.org>; Tue, 26 Apr 2005 09:25:14 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD))
	id 1DQPsO-000NnB-9w
	for netconf-data@psg.com; Tue, 26 Apr 2005 13:13:20 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.50 (FreeBSD))
	id 1DQACc-00011r-K6
	for netconf@ops.ietf.org; Mon, 25 Apr 2005 20:29:11 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19790;
	Mon, 25 Apr 2005 16:29:00 -0400 (EDT)
Message-Id: <200504252029.QAA19790@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-05.txt
Date: Mon, 25 Apr 2005 16:29:00 -0400
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) 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.2
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-05.txt
	Pages		: 21
	Date		: 2005-4-25
	
The Network Configuration 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 the Simple Object Access Protocol (SOAP).  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 SOAP over HTTP and SOAP over
   BEEP bindings for NETCONF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-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-soap-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-soap-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-4-25155209.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-soap-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-soap-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-4-25155209.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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Wed Apr 27 12:32: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 MAA00644
	for <netconf-archive@lists.ietf.org>; Wed, 27 Apr 2005 12:32:56 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD))
	id 1DQpEw-000FGR-IE
	for netconf-data@psg.com; Wed, 27 Apr 2005 16:18:18 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.50 (FreeBSD))
	id 1DQmzK-000Mto-GX
	for netconf@ops.ietf.org; Wed, 27 Apr 2005 13:54:02 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12192;
	Wed, 27 Apr 2005 09:53:59 -0400 (EDT)
Message-Id: <200504271353.JAA12192@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-06.txt
Date: Wed, 27 Apr 2005 09:53:59 -0400
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) 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.2
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-06.txt
	Pages		: 96
	Date		: 2005-4-26
	
The NETCONF configuration protocol defined in this document provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices.  It uses an Extensible Markup Language (XML) based
   data encoding for the configuration data as well as the protocol
   messages.  The NETCONF protocol operations are realized on top of a
   simple Remote Procedure Call (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-06.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-06.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-06.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-4-27102803.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-prot-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-prot-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-4-27102803.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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Thu Apr 28 08:49:27 2005
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11055
	for <netconf-archive@lists.ietf.org>; Thu, 28 Apr 2005 08:49:26 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD))
	id 1DR8Gl-000GFE-2H
	for netconf-data@psg.com; Thu, 28 Apr 2005 12:37:27 +0000
Received: from [193.180.251.53] (helo=eagle.ericsson.se)
	by psg.com with esmtp (Exim 4.50 (FreeBSD))
	id 1DR8Gf-000GEb-DX
	for netconf@ops.ietf.org; Thu, 28 Apr 2005 12:37:21 +0000
Received: from esealmw126.eemea.ericsson.se ([153.88.254.123])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3SCbKO6000079
	for <netconf@ops.ietf.org>; Thu, 28 Apr 2005 14:37:20 +0200
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 28 Apr 2005 14:37:20 +0200
Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 28 Apr 2005 14:37:20 +0200
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: configuration vs operational requests
Date: Thu, 28 Apr 2005 14:37:19 +0200
Message-ID: <94B96B3383630441B365F76490340348A1F02A@esealmw103.eemea.ericsson.se>
Thread-Topic: configuration vs operational requests
Thread-index: AcVL7wRHzkwxDzdtRnG+Xj2UWVHUXg==
From: "Daniel Mcgillivray \(LN/EAB\)" <daniel.mcgillivray@ericsson.com>
To: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 28 Apr 2005 12:37:20.0021 (UTC) FILETIME=[04D43450:01C54BEF]
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.2
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi,

I am familiar with the Junoscript protocol as used by Juniper on its =
routers. It is clear that Netconf has many the same concepts as =
Junoscript (or vice versa?).

My question is, whether there exists a similar development of a protocol =
for so called operational requests towards network elements? Are there =
plans to extend Netconf into this area, although it is not directly =
configuration related. SNMP of course is an obvious answer, but I would =
like to know if there are others alternatives which go hand in hand with =
Netconf.

The reason being, that many network elements require certain actions =
before and/or after committing a new configuration, and then it is =
rather awkward to have to switch protocol for this.

I hope you can give me some hints here.

Kind regards,
Daniel

Daniel McGillivray MSc

Ericsson AB
Mail: daniel.mcgillivray@ericsson.com
Web: www.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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Thu Apr 28 11:48: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 LAA27976
	for <netconf-archive@lists.ietf.org>; Thu, 28 Apr 2005 11:48:46 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD))
	id 1DRB92-000HtO-87
	for netconf-data@psg.com; Thu, 28 Apr 2005 15:41:40 +0000
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.50 (FreeBSD))
	id 1DRB90-000HtA-HU
	for netconf@ops.ietf.org; Thu, 28 Apr 2005 15:41:38 +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 j3SFfc910426
	for <netconf@ops.ietf.org>; Thu, 28 Apr 2005 08:41:38 -0700 (PDT)
	(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 j3SFfWe15709
	for <netconf@ops.ietf.org>; Thu, 28 Apr 2005 08:41:32 -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 j3SFfWHe064840
	for <netconf@ops.ietf.org>; Thu, 28 Apr 2005 11:41:32 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200504281541.j3SFfWHe064840@idle.juniper.net>
jo: "Daniel Mcgillivray \(LN/EAB\)" <daniel.mcgillivray@ericsson.com>
cc: netconf@ops.ietf.org
Subject: Re: configuration vs operational requests 
In-Reply-To: Your message of "Thu, 28 Apr 2005 14:37:19 +0200."
             <94B96B3383630441B365F76490340348A1F02A@esealmw103.eemea.ericsson.se> 
Date: Thu, 28 Apr 2005 11:41:32 -0400
From: Phil Shafer <phil@juniper.net>
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS 
	autolearn=ham version=3.0.2
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

"Daniel Mcgillivray \(LN/EAB\)" writes:
>I am familiar with the Junoscript protocol as used by Juniper on its routers. It is clear that
> Netconf has many the same concepts as Junoscript (or vice versa?).

Yes, netconf builds on the experience we gained with Junoscript.

>My question is, whether there exists a similar development of a protocol for so called operati
>onal requests towards network elements? Are there plans to extend Netconf into this area, alth
>ough it is not directly configuration related. SNMP of course is an obvious answer, but I woul
>d like to know if there are others alternatives which go hand in hand with Netconf.

Netconf is primarily concerned with configuration, but the capability
mechanism allows the creation of additional RPCs, including operational
requests.  Defining such RPCs wasn't the initial target of the working
group, but will likely come up as the current drafts are put to bed.

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: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Thu Apr 28 14:40: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 OAA11910
	for <netconf-archive@lists.ietf.org>; Thu, 28 Apr 2005 14:40:28 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD))
	id 1DRDnp-000IOe-Ue
	for netconf-data@psg.com; Thu, 28 Apr 2005 18:31:57 +0000
Received: from [207.17.137.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.50 (FreeBSD))
	id 1DRDno-000IOK-A5
	for netconf@ops.ietf.org; Thu, 28 Apr 2005 18:31:56 +0000
Received: from unknown (HELO beta.jnpr.net) (172.24.18.109)
  by kremlin.juniper.net with ESMTP; 28 Apr 2005 11:31:56 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.92,136,1112598000"; 
   d="scan'208"; a="292142106:sNHT27885108"
Received: from gluon.jnpr.net ([172.24.15.23]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 28 Apr 2005 11:31:55 -0700
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: configuration vs operational requests 
Date: Thu, 28 Apr 2005 11:31:55 -0700
Message-ID: <EC0401F13E645E4DA7072EA6E5944F760263BBAA@gluon.jnpr.net>
Thread-Topic: configuration vs operational requests 
Thread-Index: AcVMCQcdTP7RwlWiTs6SiSyRVUL9pQAF3pnw
From: "Faye Ly" <fayely@juniper.net>
To: "Phil Shafer" <phil@juniper.net>
Cc: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 28 Apr 2005 18:31:55.0764 (UTC) FILETIME=[8E28F340:01C54C20]
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.2
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Daniel,

What kind of operational request?  Can you please provide an example?
Thanks.

-faye

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Phil Shafer
Sent: Thursday, April 28, 2005 8:42 AM
Cc: netconf@ops.ietf.org
Subject: Re: configuration vs operational requests=20

"Daniel Mcgillivray \(LN/EAB\)" writes:
>I am familiar with the Junoscript protocol as used by Juniper on its
routers. It is clear that
> Netconf has many the same concepts as Junoscript (or vice versa?).

Yes, netconf builds on the experience we gained with Junoscript.

>My question is, whether there exists a similar development of a
protocol for so called operati
>onal requests towards network elements? Are there plans to extend
Netconf into this area, alth
>ough it is not directly configuration related. SNMP of course is an
obvious answer, but I woul
>d like to know if there are others alternatives which go hand in hand
with Netconf.

Netconf is primarily concerned with configuration, but the capability
mechanism allows the creation of additional RPCs, including operational
requests.  Defining such RPCs wasn't the initial target of the working
group, but will likely come up as the current drafts are put to bed.

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: <http://ops.ietf.org/lists/netconf/>

--
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: <http://ops.ietf.org/lists/netconf/>