From owner-netconf@ops.ietf.org  Fri Oct  1 04:15:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04747
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 04:15:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDIOL-000An2-Qb
	for netconf-data@psg.com; Fri, 01 Oct 2004 08:03:49 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDIOB-000Alu-AY
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 08:03:39 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 01 Oct 2004 01:07:36 -0700
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9183aEE017299;
	Fri, 1 Oct 2004 01:03:37 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA08098; Fri, 1 Oct 2004 01:03:36 -0700 (PDT)
Message-ID: <415D0F56.4040206@cisco.com>
Date: Fri, 01 Oct 2004 10:03:34 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf <netconf@ops.ietf.org>,
        Margaret Wasserman <margaret@thingmagic.com>
Subject: on <close-session>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

A few of us discussed this yesterday.  Please comment on the following idea:

Leave <close-session> in the base document for when the manager wants to 
close a session.

The method for an agent closing a session shall be specified in the 
mapping specification.

Other tidbits:

  - a manager MUST NOT send <RPC>s after a <close-session>
  - an agent MUST cease processing <RPC>s if it determines that it has
    lost communications with the manager, and release all state
    associated with the session, including locks.

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  Fri Oct  1 08:07:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22192
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 08:07:37 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDM1C-000EIc-AW
	for netconf-data@psg.com; Fri, 01 Oct 2004 11:56:10 +0000
Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDM0y-000EGX-Um
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 11:55:57 +0000
Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220])
          by comcast.net (sccrmhc13) with SMTP
          id <2004100111555601600c0d4de>; Fri, 1 Oct 2004 11:55:56 +0000
Reply-To: <dbharrington@comcast.net>
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>, "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'" <margaret@thingmagic.com>
Subject: RE: on <close-session>
Date: Fri, 1 Oct 2004 07:55:53 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <415D0F56.4040206@cisco.com>
Thread-Index: AcSnjkxEGGiz8QG2TSGUcLP88dc1OwAHBe7g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Message-Id: <E1CDM1C-000EIc-AW@psg.com>
Content-Transfer-Encoding: 7bit

Hi Eliot,

What is the reasoning behind the following rule?
 - an agent MUST cease processing <RPC>s if it determines that it has
    lost communications with the manager, and release all state
    associated with the session, including locks.

I view MUST as a requirement for interoperable on-the-wire behavior.
Is this really a MUST, or a SHOULD, or a MAY, and why? 

It seems to me that you end up with potentially inconsistent state
either way, and either resultant state might preclude establishing a
new communicatioins session.

If it has started processing an RPC, MUST it abort that operation, or
can it wait until the next RPC to cease processing? 
If it has buffered RPCs, it apparently must discard the buffered RPCs.
Where is the point at which interoperability would be impacted if ti
continued processing its buffered RPCs?

dbh

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On Behalf Of Eliot Lear
Sent: Friday, October 01, 2004 4:04 AM
To: netconf; Margaret Wasserman
Subject: on <close-session>

A few of us discussed this yesterday.  Please comment on the following
idea:

Leave <close-session> in the base document for when the manager wants
to close a session.

The method for an agent closing a session shall be specified in the
mapping specification.

Other tidbits:

  - a manager MUST NOT send <RPC>s after a <close-session>
  - an agent MUST cease processing <RPC>s if it determines that it has
    lost communications with the manager, and release all state
    associated with the session, including locks.

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 Oct  1 08:31:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23947
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 08:31:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDMS2-000I6i-At
	for netconf-data@psg.com; Fri, 01 Oct 2004 12:23:54 +0000
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDMRr-000I3s-P0
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 12:23:43 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 01 Oct 2004 05:37:39 +0000
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i91CNbEE028634;
	Fri, 1 Oct 2004 05:23:38 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA06707; Fri, 1 Oct 2004 05:23:36 -0700 (PDT)
Message-ID: <415D4C47.1050401@cisco.com>
Date: Fri, 01 Oct 2004 14:23:35 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dbharrington@comcast.net
CC: "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'" <margaret@thingmagic.com>
Subject: Re: on <close-session>
References: <200410011158.i91Bvq39021132@sj-inbound-1.cisco.com>
In-Reply-To: <200410011158.i91Bvq39021132@sj-inbound-1.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



David B Harrington wrote:
> Hi Eliot,
> 
> What is the reasoning behind the following rule?
>  - an agent MUST cease processing <RPC>s if it determines that it has
>     lost communications with the manager, and release all state
>     associated with the session, including locks.
> 
> I view MUST as a requirement for interoperable on-the-wire behavior.
> Is this really a MUST, or a SHOULD, or a MAY, and why?

The theory goes that the reason you had the additional RPCs in the first 
place was that you are pipelining, and pipelining is an optimization so 
that you don't have to wait for a response.  However, there is no way to 
report an error once the communication channel is gone, so why continue 
processing?  At worst then you've lost a single RPC response.  I would 
argue that it is an interoperability argument in as much as you've lost 
the ability to report state to the other end.  Does that fail the test 
of MUST?

I'm not religious about it, so I could be convinced the other way.  In 
fact here's an argument for the other way- suppose one RPC is 
intentionally disruptive and the next is meant to heal.  The catch in 
doing it this way is that you have no guarantee of the 2nd RPC getting 
to the device before it go boom on the 1st RPC.

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  Fri Oct  1 08:34:23 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24210
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 08:34:23 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDMWA-000IdX-82
	for netconf-data@psg.com; Fri, 01 Oct 2004 12:28:10 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDMVz-000Icm-JL
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 12:27:59 +0000
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-4.cisco.com with ESMTP; 01 Oct 2004 05:28:58 -0700
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i91CRuqg014760;
	Fri, 1 Oct 2004 05:27:57 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA10202; Fri, 1 Oct 2004 05:27:55 -0700 (PDT)
Message-ID: <415D4D4A.4010206@cisco.com>
Date: Fri, 01 Oct 2004 14:27:54 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: dbharrington@comcast.net, "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'" <margaret@thingmagic.com>
Subject: Re: on <close-session>
References: <200410011158.i91Bvq39021132@sj-inbound-1.cisco.com> <415D4C47.1050401@cisco.com>
In-Reply-To: <415D4C47.1050401@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just to add one point to respond to Dave...

Yes, I do think you complete the existing RPC in order to remain as 
consistent as possible, given the possibility that the RPC itself could 
contain a temporarily disruptive change that is corrected in the same RPC.

Eliot

Eliot Lear wrote:
> 
> 
> David B Harrington wrote:
> 
>> Hi Eliot,
>>
>> What is the reasoning behind the following rule?
>>  - an agent MUST cease processing <RPC>s if it determines that it has
>>     lost communications with the manager, and release all state
>>     associated with the session, including locks.
>>
>> I view MUST as a requirement for interoperable on-the-wire behavior.
>> Is this really a MUST, or a SHOULD, or a MAY, and why?
> 
> 
> The theory goes that the reason you had the additional RPCs in the first 
> place was that you are pipelining, and pipelining is an optimization so 
> that you don't have to wait for a response.  However, there is no way to 
> report an error once the communication channel is gone, so why continue 
> processing?  At worst then you've lost a single RPC response.  I would 
> argue that it is an interoperability argument in as much as you've lost 
> the ability to report state to the other end.  Does that fail the test 
> of MUST?
> 
> I'm not religious about it, so I could be convinced the other way.  In 
> fact here's an argument for the other way- suppose one RPC is 
> intentionally disruptive and the next is meant to heal.  The catch in 
> doing it this way is that you have no guarantee of the 2nd RPC getting 
> to the device before it go boom on the 1st RPC.
> 
> 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 Oct  1 09:47:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29837
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 09:47:56 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDNe2-0002l7-Fb
	for netconf-data@psg.com; Fri, 01 Oct 2004 13:40:22 +0000
Received: from [203.101.113.39] (helo=wip-ec-wd.wipro.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDNdo-0002jn-Sm
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 13:40:11 +0000
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id D6C0A205C8
	for <netconf@ops.ietf.org>; Fri,  1 Oct 2004 19:06:58 +0530 (IST)
Received: from blr-ec-bh2.wipro.com (unknown [10.200.50.92])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id AA700205C6
	for <netconf@ops.ietf.org>; Fri,  1 Oct 2004 19:06:58 +0530 (IST)
Received: from blr-itp-msg.wipro.com ([10.185.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 1 Oct 2004 19:10:02 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: on <close-session>
Date: Fri, 1 Oct 2004 19:10:01 +0530
Message-ID: <30A4A576EB47C64AB2694E1F17DBE117EA7BFE@blr-itp-msg.wipro.com>
Thread-Topic: on <close-session>
Thread-Index: AcSnjr14bTVo85ocQ3Oa1eW7mVFLMQAJfg6Q
From: <jayaprakash.kulkarni@wipro.com>
To: <lear@cisco.com>, <netconf@ops.ietf.org>, <margaret@thingmagic.com>
X-OriginalArrivalTime: 01 Oct 2004 13:40:02.0391 (UTC) FILETIME=[270A8E70:01C4A7BC]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Eliot Lear wrote:

>  - an agent MUST cease processing <RPC>s if it determines that it has
>    lost communications with the manager, and release all state
>    associated with the session, including locks.

Is this para concerned with a normal termination using close-session
command?

If yes, is it a expected behaviour that manager will terminate a session
immediately on sending a close-session OR should it wait until it
recieves a <ok> reply from the manager?

IMO, manager should not terminate a session immediately at the end of a
close-session command and should wait until it recieves a <ok> reply.

For example: If the user wants to run the following script on a daily
basis:
<get-config>
<edit-config>
<commit>
<close-session>

All the commands should be pipelined, so the close-session would get
executed only at the end of the commit operation.

Regards
Jayaprakash



--
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 Oct  1 09:50:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00113
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 09:50:26 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDNhZ-0003N1-87
	for netconf-data@psg.com; Fri, 01 Oct 2004 13:44:01 +0000
Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDNhO-0003JS-8k
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 13:43:50 +0000
Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220])
          by comcast.net (sccrmhc11) with SMTP
          id <2004100113434901100k80m5e>; Fri, 1 Oct 2004 13:43:49 +0000
Reply-To: <dbharrington@comcast.net>
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>
Cc: "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'" <margaret@thingmagic.com>
Subject: RE: on <close-session>
Date: Fri, 1 Oct 2004 09:43:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <415D4C47.1050401@cisco.com>
Thread-Index: AcSnsYB9ssTcU7+KTo6CHh4e/4R1dAAAn3ag
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Message-Id: <E1CDNhZ-0003N1-87@psg.com>
Content-Transfer-Encoding: 7bit

Hi Eliot,

I haven't been following netconf closely so I may have missed some
changes, and may make some dated assumptions. Feel free to point out
that my assumptions are based on an outdated understanding of netconf
design.

Let me say that I'm probing around the edge cases because I want to
understand whether this rule is really required for interoperability.
I don't really have an opinion about this rule. As a MIB Doctor, there
are a few things I watch for: we should avoid using MUST/SHOULD
language where it isn't warranted, and we want to avoid developing
crappy little rules (tm) that are unnecessary constraints on
implementors. 

This rule has three requirements - cease processing, release locks,
and release other session state. I'll focus on the "cease processing"
requirement for now.

"cease processing" and interoperabiity:
Once we lose the communications channel, the manager loses the ability
to receive responses of any kind from that session, error or success.
Whether the agent ceases processing is immaterial, right? So I
question whether "MUST cease processing RPCs" impacts on-the wire
interoperability; the on-the-wire behavior isn't impacted as far as
the manager is concerned. 

"cease processing" and the manager -
A pipelining manager, with knowledge of an agent that buffers RPCs,
MAY deliberately send RPCs to get buffered, and then close down the
comm channel because it doesn't care what the reposnses are. I don't
think this is a great design choice, but I cannot foresee all the
factors that might lead to such a choice, and we shouldn't have CLRs
that constrain application design unnecessarily. 

"cease processing" and the agent -
If an agent sends responses after it has determined the comm channel
is lost, it is knowingly wasting bandwidth. Does this mean it should
not process the RPCs it has buffered, or merely that it shouldn't send
a response? If the pipelining manager doesn't care about the
responses, closing the channel might be a thoughtful optimization. If
the use case of a manager that doesn't care about responses is real,
maybe we should just add an optional flag to each RPC that says "don't
bother responding". How real is this use case? Should we write a CLR
that says this use case is illegal? The current proposed rule seems to
be that CLR.

Does an implementor have the resonsibility to check whether the
response channel still exists before it starts to process any buffered
RPC? This rule seems to require that. Why is it a MUST, rather than a
MAY or a SHOULD?

Other interoperability concerns - 
It may impact interoperability if the manager cannot regain control
using a new session because the lock exists, or the other session
state exists, or the other processing is still ongoing. Are there real
cases where this could be a problem, that are not already addressed by
netconf? 

SNMP was designed to be able to work in an unstable network,
specifically to stay operating well enough in a war environment to
deliver commands, even if it cannot maintain session. Think terrorist
attack. If a manager can send RPCs to a device to configure a security
mechanism, but the agent buffers the RPC, and the terrorist then
disrupts the communications, then the security RPC that has been
successsfully delivered has to be re-delivered, possibly after
determining through get-state that it didn't take effect the first
time. Does requiring the discard of successfully-received RPCs make
netconf less robust when under attack?

David Harrington
dbharrington@comcast.net

-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: Friday, October 01, 2004 8:24 AM
To: dbharrington@comcast.net
Cc: 'netconf'; 'Margaret Wasserman'
Subject: Re: on <close-session>



David B Harrington wrote:
> Hi Eliot,
> 
> What is the reasoning behind the following rule?
>  - an agent MUST cease processing <RPC>s if it determines that it
has
>     lost communications with the manager, and release all state
>     associated with the session, including locks.
> 
> I view MUST as a requirement for interoperable on-the-wire behavior.
> Is this really a MUST, or a SHOULD, or a MAY, and why?

The theory goes that the reason you had the additional RPCs in the
first place was that you are pipelining, and pipelining is an
optimization so that you don't have to wait for a response.  However,
there is no way to report an error once the communication channel is
gone, so why continue processing?  At worst then you've lost a single
RPC response.  I would argue that it is an interoperability argument
in as much as you've lost the ability to report state to the other
end.  Does that fail the test of MUST?

I'm not religious about it, so I could be convinced the other way.  In
fact here's an argument for the other way- suppose one RPC is
intentionally disruptive and the next is meant to heal.  The catch in
doing it this way is that you have no guarantee of the 2nd RPC getting
to the device before it go boom on the 1st RPC.

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  Fri Oct  1 09:57:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00742
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 09:57:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDNp5-0004mx-T2
	for netconf-data@psg.com; Fri, 01 Oct 2004 13:51:47 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDNov-0004lz-7l
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 13:51:37 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 01 Oct 2004 06:55:37 -0700
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i91DpVwp014448;
	Fri, 1 Oct 2004 06:51:32 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA27202; Fri, 1 Oct 2004 06:51:33 -0700 (PDT)
Message-ID: <415D60E3.4080509@cisco.com>
Date: Fri, 01 Oct 2004 15:51:31 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jayaprakash.kulkarni@wipro.com
CC: netconf@ops.ietf.org, margaret@thingmagic.com
Subject: Re: on <close-session>
References: <30A4A576EB47C64AB2694E1F17DBE117EA7BFE@blr-itp-msg.wipro.com>
In-Reply-To: <30A4A576EB47C64AB2694E1F17DBE117EA7BFE@blr-itp-msg.wipro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

There are four cases to discuss:

  - manager initiates normal close
  In this case, nobody should close the underlying communication path
  until the agent has responded to all outstanding <RPC>s.
  - agent initiates normal close
  In this case, the agent SHOULD NOT initiate a close until it has
  processed all outstanding RPCs.
  - manager realizes it's lost the communication channel
  Error condition.  Stop sending until you've dealt with the error ;-)
  - agent realizes it's lost the connection
  Complete any RPC that is currently being executed and then stop
  so that the manager can deal with the error...

Additional comments below:


jayaprakash.kulkarni@wipro.com wrote:
> Eliot Lear wrote:
> 
> 
>> - an agent MUST cease processing <RPC>s if it determines that it has
>>   lost communications with the manager, and release all state
>>   associated with the session, including locks.
> 
> 
> Is this para concerned with a normal termination using close-session
> command?

NO.

> 
> If yes, is it a expected behaviour that manager will terminate a session
> immediately on sending a close-session OR should it wait until it
> recieves a <ok> reply from the manager?
> 
> IMO, manager should not terminate a session immediately at the end of a
> close-session command and should wait until it recieves a <ok> reply.

Right.  transport should remain intact under normal circumstances until 
<OK> is received.  Then transport mapping dictates close procedures.

> 
> All the commands should be pipelined, so the close-session would get
> executed only at the end of the commit operation.

Yah.

Eliot
ps: I'm not sure what it means to see a confidentiality notice on a 
public mailing list...

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Oct  1 10:00:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00937
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 10:00:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDNpR-0004p9-L2
	for netconf-data@psg.com; Fri, 01 Oct 2004 13:52:09 +0000
Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDNpG-0004ns-1s
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 13:51:58 +0000
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i91DplB25546;
	Fri, 1 Oct 2004 09:51:47 -0400 (EDT)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TS1CTKG4>; Fri, 1 Oct 2004 09:51:47 -0400
Message-ID: <D38D073716F2D411BEE400508BCF62960C8C418C@zcard04k.ca.nortel.com>
From: "Glenn Waters" <gww@nortelnetworks.com>
To: dbharrington@comcast.net, "'Eliot Lear'" <lear@cisco.com>
Cc: "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'"
	 <margaret@thingmagic.com>
Subject: RE: on <close-session>
Date: Fri, 1 Oct 2004 09:51:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4A7BD.C9A926E0"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4A7BD.C9A926E0
Content-Type: text/plain

Gosh, I haven't had a MUST, SHOULD, MAY discussion for quite a while :)

For reasons other than what Dave discusses I believe you want to make this
one a SHOULD. Reason being is that MUST is usually being done to ensure
compliancy -- unfortunately different implementations will have varying
mechanisms for determining when a connection has gone way and hence there
will be no consistent implementation of this particular feature -- which
means that there is no way to determine compliant implementations -- which
means that MUST is not "enforceable".

Regards, /gww  

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> Sent: Friday, October 01, 2004 09:44
> To: 'Eliot Lear'
> Cc: 'netconf'; 'Margaret Wasserman'
> Subject: RE: on <close-session>
> 
> Hi Eliot,
> 
> I haven't been following netconf closely so I may have missed some
> changes, and may make some dated assumptions. Feel free to point out
> that my assumptions are based on an outdated understanding of netconf
> design.
> 
> Let me say that I'm probing around the edge cases because I want to
> understand whether this rule is really required for interoperability.
> I don't really have an opinion about this rule. As a MIB Doctor, there
> are a few things I watch for: we should avoid using MUST/SHOULD
> language where it isn't warranted, and we want to avoid developing
> crappy little rules (tm) that are unnecessary constraints on
> implementors.
> 
> This rule has three requirements - cease processing, release locks,
> and release other session state. I'll focus on the "cease processing"
> requirement for now.
> 
> "cease processing" and interoperabiity:
> Once we lose the communications channel, the manager loses the ability
> to receive responses of any kind from that session, error or success.
> Whether the agent ceases processing is immaterial, right? So I
> question whether "MUST cease processing RPCs" impacts on-the wire
> interoperability; the on-the-wire behavior isn't impacted as far as
> the manager is concerned.
> 
> "cease processing" and the manager -
> A pipelining manager, with knowledge of an agent that buffers RPCs,
> MAY deliberately send RPCs to get buffered, and then close down the
> comm channel because it doesn't care what the reposnses are. I don't
> think this is a great design choice, but I cannot foresee all the
> factors that might lead to such a choice, and we shouldn't have CLRs
> that constrain application design unnecessarily.
> 
> "cease processing" and the agent -
> If an agent sends responses after it has determined the comm channel
> is lost, it is knowingly wasting bandwidth. Does this mean it should
> not process the RPCs it has buffered, or merely that it shouldn't send
> a response? If the pipelining manager doesn't care about the
> responses, closing the channel might be a thoughtful optimization. If
> the use case of a manager that doesn't care about responses is real,
> maybe we should just add an optional flag to each RPC that says "don't
> bother responding". How real is this use case? Should we write a CLR
> that says this use case is illegal? The current proposed rule seems to
> be that CLR.
> 
> Does an implementor have the resonsibility to check whether the
> response channel still exists before it starts to process any buffered
> RPC? This rule seems to require that. Why is it a MUST, rather than a
> MAY or a SHOULD?
> 
> Other interoperability concerns -
> It may impact interoperability if the manager cannot regain control
> using a new session because the lock exists, or the other session
> state exists, or the other processing is still ongoing. Are there real
> cases where this could be a problem, that are not already addressed by
> netconf?
> 
> SNMP was designed to be able to work in an unstable network,
> specifically to stay operating well enough in a war environment to
> deliver commands, even if it cannot maintain session. Think terrorist
> attack. If a manager can send RPCs to a device to configure a security
> mechanism, but the agent buffers the RPC, and the terrorist then
> disrupts the communications, then the security RPC that has been
> successsfully delivered has to be re-delivered, possibly after
> determining through get-state that it didn't take effect the first
> time. Does requiring the discard of successfully-received RPCs make
> netconf less robust when under attack?
> 
> David Harrington
> dbharrington@comcast.net
> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Friday, October 01, 2004 8:24 AM
> To: dbharrington@comcast.net
> Cc: 'netconf'; 'Margaret Wasserman'
> Subject: Re: on <close-session>
> 
> 
> 
> David B Harrington wrote:
> > Hi Eliot,
> >
> > What is the reasoning behind the following rule?
> >  - an agent MUST cease processing <RPC>s if it determines that it
> has
> >     lost communications with the manager, and release all state
> >     associated with the session, including locks.
> >
> > I view MUST as a requirement for interoperable on-the-wire behavior.
> > Is this really a MUST, or a SHOULD, or a MAY, and why?
> 
> The theory goes that the reason you had the additional RPCs in the
> first place was that you are pipelining, and pipelining is an
> optimization so that you don't have to wait for a response.  However,
> there is no way to report an error once the communication channel is
> gone, so why continue processing?  At worst then you've lost a single
> RPC response.  I would argue that it is an interoperability argument
> in as much as you've lost the ability to report state to the other
> end.  Does that fail the test of MUST?
> 
> I'm not religious about it, so I could be convinced the other way.  In
> fact here's an argument for the other way- suppose one RPC is
> intentionally disruptive and the next is meant to heal.  The catch in
> doing it this way is that you have no guarantee of the 2nd RPC getting
> to the device before it go boom on the 1st RPC.
> 
> 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/>


------_=_NextPart_001_01C4A7BD.C9A926E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: on &lt;close-session&gt;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Gosh, I haven't had a MUST, SHOULD, MAY discussion =
for quite a while :)</FONT>
</P>

<P><FONT SIZE=3D2>For reasons other than what Dave discusses I believe =
you want to make this one a SHOULD. Reason being is that MUST is =
usually being done to ensure compliancy -- unfortunately different =
implementations will have varying mechanisms for determining when a =
connection has gone way and hence there will be no consistent =
implementation of this particular feature -- which means that there is =
no way to determine compliant implementations -- which means that MUST =
is not &quot;enforceable&quot;.</FONT></P>

<P><FONT SIZE=3D2>Regards, /gww&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: owner-netconf@ops.ietf.org [<A =
HREF=3D"mailto:owner-netconf@ops.ietf.org">mailto:owner-netconf@ops.ietf=
.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, October 01, 2004 09:44</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Eliot Lear'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'netconf'; 'Margaret Wasserman'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: on &lt;close-session&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Eliot,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I haven't been following netconf closely so I =
may have missed some</FONT>
<BR><FONT SIZE=3D2>&gt; changes, and may make some dated assumptions. =
Feel free to point out</FONT>
<BR><FONT SIZE=3D2>&gt; that my assumptions are based on an outdated =
understanding of netconf</FONT>
<BR><FONT SIZE=3D2>&gt; design.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Let me say that I'm probing around the edge =
cases because I want to</FONT>
<BR><FONT SIZE=3D2>&gt; understand whether this rule is really required =
for interoperability.</FONT>
<BR><FONT SIZE=3D2>&gt; I don't really have an opinion about this rule. =
As a MIB Doctor, there</FONT>
<BR><FONT SIZE=3D2>&gt; are a few things I watch for: we should avoid =
using MUST/SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt; language where it isn't warranted, and we want =
to avoid developing</FONT>
<BR><FONT SIZE=3D2>&gt; crappy little rules (tm) that are unnecessary =
constraints on</FONT>
<BR><FONT SIZE=3D2>&gt; implementors.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This rule has three requirements - cease =
processing, release locks,</FONT>
<BR><FONT SIZE=3D2>&gt; and release other session state. I'll focus on =
the &quot;cease processing&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; requirement for now.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;cease processing&quot; and =
interoperabiity:</FONT>
<BR><FONT SIZE=3D2>&gt; Once we lose the communications channel, the =
manager loses the ability</FONT>
<BR><FONT SIZE=3D2>&gt; to receive responses of any kind from that =
session, error or success.</FONT>
<BR><FONT SIZE=3D2>&gt; Whether the agent ceases processing is =
immaterial, right? So I</FONT>
<BR><FONT SIZE=3D2>&gt; question whether &quot;MUST cease processing =
RPCs&quot; impacts on-the wire</FONT>
<BR><FONT SIZE=3D2>&gt; interoperability; the on-the-wire behavior =
isn't impacted as far as</FONT>
<BR><FONT SIZE=3D2>&gt; the manager is concerned.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;cease processing&quot; and the manager =
-</FONT>
<BR><FONT SIZE=3D2>&gt; A pipelining manager, with knowledge of an =
agent that buffers RPCs,</FONT>
<BR><FONT SIZE=3D2>&gt; MAY deliberately send RPCs to get buffered, and =
then close down the</FONT>
<BR><FONT SIZE=3D2>&gt; comm channel because it doesn't care what the =
reposnses are. I don't</FONT>
<BR><FONT SIZE=3D2>&gt; think this is a great design choice, but I =
cannot foresee all the</FONT>
<BR><FONT SIZE=3D2>&gt; factors that might lead to such a choice, and =
we shouldn't have CLRs</FONT>
<BR><FONT SIZE=3D2>&gt; that constrain application design =
unnecessarily.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;cease processing&quot; and the agent =
-</FONT>
<BR><FONT SIZE=3D2>&gt; If an agent sends responses after it has =
determined the comm channel</FONT>
<BR><FONT SIZE=3D2>&gt; is lost, it is knowingly wasting bandwidth. =
Does this mean it should</FONT>
<BR><FONT SIZE=3D2>&gt; not process the RPCs it has buffered, or merely =
that it shouldn't send</FONT>
<BR><FONT SIZE=3D2>&gt; a response? If the pipelining manager doesn't =
care about the</FONT>
<BR><FONT SIZE=3D2>&gt; responses, closing the channel might be a =
thoughtful optimization. If</FONT>
<BR><FONT SIZE=3D2>&gt; the use case of a manager that doesn't care =
about responses is real,</FONT>
<BR><FONT SIZE=3D2>&gt; maybe we should just add an optional flag to =
each RPC that says &quot;don't</FONT>
<BR><FONT SIZE=3D2>&gt; bother responding&quot;. How real is this use =
case? Should we write a CLR</FONT>
<BR><FONT SIZE=3D2>&gt; that says this use case is illegal? The current =
proposed rule seems to</FONT>
<BR><FONT SIZE=3D2>&gt; be that CLR.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Does an implementor have the resonsibility to =
check whether the</FONT>
<BR><FONT SIZE=3D2>&gt; response channel still exists before it starts =
to process any buffered</FONT>
<BR><FONT SIZE=3D2>&gt; RPC? This rule seems to require that. Why is it =
a MUST, rather than a</FONT>
<BR><FONT SIZE=3D2>&gt; MAY or a SHOULD?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Other interoperability concerns -</FONT>
<BR><FONT SIZE=3D2>&gt; It may impact interoperability if the manager =
cannot regain control</FONT>
<BR><FONT SIZE=3D2>&gt; using a new session because the lock exists, or =
the other session</FONT>
<BR><FONT SIZE=3D2>&gt; state exists, or the other processing is still =
ongoing. Are there real</FONT>
<BR><FONT SIZE=3D2>&gt; cases where this could be a problem, that are =
not already addressed by</FONT>
<BR><FONT SIZE=3D2>&gt; netconf?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SNMP was designed to be able to work in an =
unstable network,</FONT>
<BR><FONT SIZE=3D2>&gt; specifically to stay operating well enough in a =
war environment to</FONT>
<BR><FONT SIZE=3D2>&gt; deliver commands, even if it cannot maintain =
session. Think terrorist</FONT>
<BR><FONT SIZE=3D2>&gt; attack. If a manager can send RPCs to a device =
to configure a security</FONT>
<BR><FONT SIZE=3D2>&gt; mechanism, but the agent buffers the RPC, and =
the terrorist then</FONT>
<BR><FONT SIZE=3D2>&gt; disrupts the communications, then the security =
RPC that has been</FONT>
<BR><FONT SIZE=3D2>&gt; successsfully delivered has to be re-delivered, =
possibly after</FONT>
<BR><FONT SIZE=3D2>&gt; determining through get-state that it didn't =
take effect the first</FONT>
<BR><FONT SIZE=3D2>&gt; time. Does requiring the discard of =
successfully-received RPCs make</FONT>
<BR><FONT SIZE=3D2>&gt; netconf less robust when under attack?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Harrington</FONT>
<BR><FONT SIZE=3D2>&gt; dbharrington@comcast.net</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eliot Lear [<A =
HREF=3D"mailto:lear@cisco.com">mailto:lear@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, October 01, 2004 8:24 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: dbharrington@comcast.net</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'netconf'; 'Margaret Wasserman'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: on &lt;close-session&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David B Harrington wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi Eliot,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What is the reasoning behind the following =
rule?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; - an agent MUST cease processing =
&lt;RPC&gt;s if it determines that it</FONT>
<BR><FONT SIZE=3D2>&gt; has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; lost =
communications with the manager, and release all state</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; associated with =
the session, including locks.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I view MUST as a requirement for =
interoperable on-the-wire behavior.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is this really a MUST, or a SHOULD, or a =
MAY, and why?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The theory goes that the reason you had the =
additional RPCs in the</FONT>
<BR><FONT SIZE=3D2>&gt; first place was that you are pipelining, and =
pipelining is an</FONT>
<BR><FONT SIZE=3D2>&gt; optimization so that you don't have to wait for =
a response.&nbsp; However,</FONT>
<BR><FONT SIZE=3D2>&gt; there is no way to report an error once the =
communication channel is</FONT>
<BR><FONT SIZE=3D2>&gt; gone, so why continue processing?&nbsp; At =
worst then you've lost a single</FONT>
<BR><FONT SIZE=3D2>&gt; RPC response.&nbsp; I would argue that it is an =
interoperability argument</FONT>
<BR><FONT SIZE=3D2>&gt; in as much as you've lost the ability to report =
state to the other</FONT>
<BR><FONT SIZE=3D2>&gt; end.&nbsp; Does that fail the test of =
MUST?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm not religious about it, so I could be =
convinced the other way.&nbsp; In</FONT>
<BR><FONT SIZE=3D2>&gt; fact here's an argument for the other way- =
suppose one RPC is</FONT>
<BR><FONT SIZE=3D2>&gt; intentionally disruptive and the next is meant =
to heal.&nbsp; The catch in</FONT>
<BR><FONT SIZE=3D2>&gt; doing it this way is that you have no guarantee =
of the 2nd RPC getting</FONT>
<BR><FONT SIZE=3D2>&gt; to the device before it go boom on the 1st =
RPC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Eliot</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; to unsubscribe send a message to =
netconf-request@ops.ietf.org with</FONT>
<BR><FONT SIZE=3D2>&gt; the word 'unsubscribe' in a single line as the =
message text body.</FONT>
<BR><FONT SIZE=3D2>&gt; archive: &lt;<A =
HREF=3D"http://ops.ietf.org/lists/netconf/" =
TARGET=3D"_blank">http://ops.ietf.org/lists/netconf/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4A7BD.C9A926E0--

--
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 Oct  1 10:06:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01766
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 10:06:45 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDNx1-0006Hu-Dn
	for netconf-data@psg.com; Fri, 01 Oct 2004 13:59:59 +0000
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDNwq-0006Gn-KJ
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 13:59:48 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-1.cisco.com with ESMTP; 01 Oct 2004 07:06:36 -0700
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i91Dxhwp020335;
	Fri, 1 Oct 2004 06:59:43 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA05791; Fri, 1 Oct 2004 06:59:45 -0700 (PDT)
Message-ID: <415D62CF.8030907@cisco.com>
Date: Fri, 01 Oct 2004 15:59:43 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dbharrington@comcast.net
CC: "'netconf'" <netconf@ops.ietf.org>
Subject: Re: on <close-session>
References: <E1CDNhZ-0003N1-87@psg.com>
In-Reply-To: <E1CDNhZ-0003N1-87@psg.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,

I guess my one question is this: I can't realistically imagine a case 
where the device config is to be changed and the manager would not want 
to receive confirmation of the change.  But Glenn is correct that  it's 
unenforceable, and the logic flows as follows:

So I as the agent send back an <OK> for a previous <RPC> and it gets 
buffered somewhere in the TCP stack about to time out.  I'm not blocking 
on it, however, and so I continue to process the next <RPC> and even 
THAT completes before I get hit with a timeout...

If you don't behave this way you would be defeating the purpose of 
pipelining.  As I said we could go either way on this.  What do people 
think?  SHOULD or nothing?  It came up because there is no text.

Eliot


David B Harrington wrote:
> Hi Eliot,
> 
> I haven't been following netconf closely so I may have missed some
> changes, and may make some dated assumptions. Feel free to point out
> that my assumptions are based on an outdated understanding of netconf
> design.
> 
> Let me say that I'm probing around the edge cases because I want to
> understand whether this rule is really required for interoperability.
> I don't really have an opinion about this rule. As a MIB Doctor, there
> are a few things I watch for: we should avoid using MUST/SHOULD
> language where it isn't warranted, and we want to avoid developing
> crappy little rules (tm) that are unnecessary constraints on
> implementors. 
> 
> This rule has three requirements - cease processing, release locks,
> and release other session state. I'll focus on the "cease processing"
> requirement for now.
> 
> "cease processing" and interoperabiity:
> Once we lose the communications channel, the manager loses the ability
> to receive responses of any kind from that session, error or success.
> Whether the agent ceases processing is immaterial, right? So I
> question whether "MUST cease processing RPCs" impacts on-the wire
> interoperability; the on-the-wire behavior isn't impacted as far as
> the manager is concerned. 
> 
> "cease processing" and the manager -
> A pipelining manager, with knowledge of an agent that buffers RPCs,
> MAY deliberately send RPCs to get buffered, and then close down the
> comm channel because it doesn't care what the reposnses are. I don't
> think this is a great design choice, but I cannot foresee all the
> factors that might lead to such a choice, and we shouldn't have CLRs
> that constrain application design unnecessarily. 
> 
> "cease processing" and the agent -
> If an agent sends responses after it has determined the comm channel
> is lost, it is knowingly wasting bandwidth. Does this mean it should
> not process the RPCs it has buffered, or merely that it shouldn't send
> a response? If the pipelining manager doesn't care about the
> responses, closing the channel might be a thoughtful optimization. If
> the use case of a manager that doesn't care about responses is real,
> maybe we should just add an optional flag to each RPC that says "don't
> bother responding". How real is this use case? Should we write a CLR
> that says this use case is illegal? The current proposed rule seems to
> be that CLR.
> 
> Does an implementor have the resonsibility to check whether the
> response channel still exists before it starts to process any buffered
> RPC? This rule seems to require that. Why is it a MUST, rather than a
> MAY or a SHOULD?
> 
> Other interoperability concerns - 
> It may impact interoperability if the manager cannot regain control
> using a new session because the lock exists, or the other session
> state exists, or the other processing is still ongoing. Are there real
> cases where this could be a problem, that are not already addressed by
> netconf? 
> 
> SNMP was designed to be able to work in an unstable network,
> specifically to stay operating well enough in a war environment to
> deliver commands, even if it cannot maintain session. Think terrorist
> attack. If a manager can send RPCs to a device to configure a security
> mechanism, but the agent buffers the RPC, and the terrorist then
> disrupts the communications, then the security RPC that has been
> successsfully delivered has to be re-delivered, possibly after
> determining through get-state that it didn't take effect the first
> time. Does requiring the discard of successfully-received RPCs make
> netconf less robust when under attack?
> 
> David Harrington
> dbharrington@comcast.net
> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Friday, October 01, 2004 8:24 AM
> To: dbharrington@comcast.net
> Cc: 'netconf'; 'Margaret Wasserman'
> Subject: Re: on <close-session>
> 
> 
> 
> David B Harrington wrote:
> 
>>Hi Eliot,
>>
>>What is the reasoning behind the following rule?
>> - an agent MUST cease processing <RPC>s if it determines that it
> 
> has
> 
>>    lost communications with the manager, and release all state
>>    associated with the session, including locks.
>>
>>I view MUST as a requirement for interoperable on-the-wire behavior.
>>Is this really a MUST, or a SHOULD, or a MAY, and why?
> 
> 
> The theory goes that the reason you had the additional RPCs in the
> first place was that you are pipelining, and pipelining is an
> optimization so that you don't have to wait for a response.  However,
> there is no way to report an error once the communication channel is
> gone, so why continue processing?  At worst then you've lost a single
> RPC response.  I would argue that it is an interoperability argument
> in as much as you've lost the ability to report state to the other
> end.  Does that fail the test of MUST?
> 
> I'm not religious about it, so I could be convinced the other way.  In
> fact here's an argument for the other way- suppose one RPC is
> intentionally disruptive and the next is meant to heal.  The catch in
> doing it this way is that you have no guarantee of the 2nd RPC getting
> to the device before it go boom on the 1st RPC.
> 
> 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 Oct  1 10:35:42 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05413
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 10:35:42 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDONd-000AGy-UW
	for netconf-data@psg.com; Fri, 01 Oct 2004 14:27:29 +0000
Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDONT-000ACW-5l
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 14:27:19 +0000
Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220])
          by comcast.net (sccrmhc13) with SMTP
          id <2004100114271801600c6bfte>; Fri, 1 Oct 2004 14:27:18 +0000
Reply-To: <dbharrington@comcast.net>
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>
Cc: "'netconf'" <netconf@ops.ietf.org>
Subject: RE: on <close-session>
Date: Fri, 1 Oct 2004 10:27:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <415D62CF.8030907@cisco.com>
Thread-Index: AcSnvum4iaDbxxg4QnuGi/EVU3zy7wAAapKQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Message-Id: <E1CDONd-000AGy-UW@psg.com>
Content-Transfer-Encoding: 7bit

From RFC2119:
SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

What implications would there be from not implementing to discard RPCs
upon detection of a lost connection?

One implication is the waste of bandwidth. If the use case of a
manager not waiting for a response is not expected, then to be a good
Internet citizen, one SHOULD cease processing.

David Harrington
dbharrington@comcast.net



-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: Friday, October 01, 2004 10:00 AM
To: dbharrington@comcast.net
Cc: 'netconf'
Subject: Re: on <close-session>

Hi Dave,

I guess my one question is this: I can't realistically imagine a case
where the device config is to be changed and the manager would not
want to receive confirmation of the change.  But Glenn is correct that
it's unenforceable, and the logic flows as follows:

So I as the agent send back an <OK> for a previous <RPC> and it gets
buffered somewhere in the TCP stack about to time out.  I'm not
blocking on it, however, and so I continue to process the next <RPC>
and even THAT completes before I get hit with a timeout...

If you don't behave this way you would be defeating the purpose of
pipelining.  As I said we could go either way on this.  What do people
think?  SHOULD or nothing?  It came up because there is no text.

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  Fri Oct  1 10:41:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05832
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 10:41:55 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDOUM-000BMh-FJ
	for netconf-data@psg.com; Fri, 01 Oct 2004 14:34:26 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDOUB-000BL5-RP
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 14:34:15 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-4.cisco.com with ESMTP; 01 Oct 2004 07:35:15 -0700
X-BrightmailFiltered: true
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 i91EYBwp015442;
	Fri, 1 Oct 2004 07:34:11 -0700 (PDT)
Received: from abierman-xp.cisco.com (sjc-vpn1-701.cisco.com [10.21.98.189])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id AZP13904;
	Fri, 1 Oct 2004 07:34:11 -0700 (PDT)
Message-Id: <4.3.2.7.2.20041001070848.02580f08@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 01 Oct 2004 07:30:16 -0700
To: <dbharrington@comcast.net>
From: Andy Bierman <abierman@cisco.com>
Subject: RE: on <close-session>
Cc: "'Eliot Lear'" <lear@cisco.com>, "'netconf'" <netconf@ops.ietf.org>,
        "'Margaret Wasserman'" <margaret@thingmagic.com>
In-Reply-To: <E1CDM1C-000EIc-AW@psg.com>
References: <415D0F56.4040206@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

At 04:55 AM 10/1/2004, David B Harrington wrote:
>Hi Eliot,
>
>What is the reasoning behind the following rule?
> - an agent MUST cease processing <RPC>s if it determines that it has
>    lost communications with the manager, and release all state
>    associated with the session, including locks.

I'm not sure either...but let me try to restate the problem
with <close-session>:

Start with an queue of RPC requests on the agent (R1 .. Rn).
Let's say Ri is a <close-session> command.
Desired outcome:
  - R1 .. Ri-1 operations are completed and the corresponding
    <rpc-reply> messages are received by the manager
  - Ri executed: session/connection closed 
  - Ri+1 .. Rn operations are never processed

The document text should clarify this behavior, and
also the behavior in the related case of a lost connection.


>I view MUST as a requirement for interoperable on-the-wire behavior.
>Is this really a MUST, or a SHOULD, or a MAY, and why? 
>
>It seems to me that you end up with potentially inconsistent state
>either way, and either resultant state might preclude establishing a
>new communicatioins session.

good point


>If it has started processing an RPC, MUST it abort that operation, or
>can it wait until the next RPC to cease processing? 

good question -- I would say SHOULD, but there aren't any
specific requirements to detect connection loss during
the RPC processing, so how useful is this rule to abort the RPC?

>If it has buffered RPCs, it apparently must discard the buffered RPCs.
>Where is the point at which interoperability would be impacted if ti
>continued processing its buffered RPCs?

It is a manager error to send RPCs after a <close-session>.
If the agent has an NV error logging facility, it may choose
to log the error after closing the session.


>dbh

Andy


>-----Original Message-----
>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
>On Behalf Of Eliot Lear
>Sent: Friday, October 01, 2004 4:04 AM
>To: netconf; Margaret Wasserman
>Subject: on <close-session>
>
>A few of us discussed this yesterday.  Please comment on the following
>idea:
>
>Leave <close-session> in the base document for when the manager wants
>to close a session.
>
>The method for an agent closing a session shall be specified in the
>mapping specification.
>
>Other tidbits:
>
>  - a manager MUST NOT send <RPC>s after a <close-session>
>  - an agent MUST cease processing <RPC>s if it determines that it has
>    lost communications with the manager, and release all state
>    associated with the session, including locks.
>
>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  Fri Oct  1 12:17:27 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19098
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 12:17:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDPyv-0002fH-WA
	for netconf-data@psg.com; Fri, 01 Oct 2004 16:10:05 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDPyl-0002bv-7S
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 16:09:55 +0000
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-4.cisco.com with ESMTP; 01 Oct 2004 09:10:55 -0700
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i91G9qqg019937;
	Fri, 1 Oct 2004 09:09:53 -0700 (PDT)
Received: from [144.254.23.176] (dhcp-data-vlan10-23-176.cisco.com [144.254.23.176]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA24431; Fri, 1 Oct 2004 09:09:51 -0700 (PDT)
Message-ID: <415D814E.20400@cisco.com>
Date: Fri, 01 Oct 2004 18:09:50 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040930)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dbharrington@comcast.net
CC: "'netconf'" <netconf@ops.ietf.org>
Subject: Re: on <close-session>
References: <E1CDONd-000AGy-UW@psg.com>
In-Reply-To: <E1CDONd-000AGy-UW@psg.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'm not sure if this is an argument for SHOULD or what, but here's one 
additional thought..

If the agent loses touch with the manager it could be for one or two 
reasons.  Either the manager intended to drop the connection or it 
didn't.  The key here is that the agent can't tell which is the case, 
and so even *if* the manager wanted to see status it couldn't.

Under the "be conservative" principle we should assume that the manager 
wanted status, and so that argues for stopping when you realize there's 
a problem.

How's that for long and circuitous?

Eliot


David B Harrington wrote:
>>From RFC2119:
> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> What implications would there be from not implementing to discard RPCs
> upon detection of a lost connection?
> 
> One implication is the waste of bandwidth. If the use case of a
> manager not waiting for a response is not expected, then to be a good
> Internet citizen, one SHOULD cease processing.
> 
> David Harrington
> dbharrington@comcast.net
> 
> 
> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Friday, October 01, 2004 10:00 AM
> To: dbharrington@comcast.net
> Cc: 'netconf'
> Subject: Re: on <close-session>
> 
> Hi Dave,
> 
> I guess my one question is this: I can't realistically imagine a case
> where the device config is to be changed and the manager would not
> want to receive confirmation of the change.  But Glenn is correct that
> it's unenforceable, and the logic flows as follows:
> 
> So I as the agent send back an <OK> for a previous <RPC> and it gets
> buffered somewhere in the TCP stack about to time out.  I'm not
> blocking on it, however, and so I continue to process the next <RPC>
> and even THAT completes before I get hit with a timeout...
> 
> If you don't behave this way you would be defeating the purpose of
> pipelining.  As I said we could go either way on this.  What do people
> think?  SHOULD or nothing?  It came up because there is no text.
> 
> 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 Oct  1 15:37:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10379
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 15:37:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDT6v-0005yL-8z
	for netconf-data@psg.com; Fri, 01 Oct 2004 19:30:33 +0000
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDT6k-0005ti-6P
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 19:30:22 +0000
Received: from diotima.switch.ch (localhost [127.0.0.1])
	by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id i91JSG6r022454
	(version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 1 Oct 2004 21:28:16 +0200 (CEST)
Received: (from leinen@localhost)
	by diotima.switch.ch (8.12.11/8.12.11/Submit) id i91JSFAW022453;
	Fri, 1 Oct 2004 21:28:15 +0200 (CEST)
To: Eliot Lear <lear@cisco.com>
Cc: dbharrington@comcast.net, "'netconf'" <netconf@ops.ietf.org>
Subject: Re: on <close-session>
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>
In-Reply-To: <415D814E.20400@cisco.com> (Eliot Lear's message of "Fri, 01
 Oct 2004 18:09:50 +0200")
References: <E1CDONd-000AGy-UW@psg.com> <415D814E.20400@cisco.com>
Date: Fri, 01 Oct 2004 21:28:15 +0200
Message-ID: <aau0tejl0w.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: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Eliot Lear writes:
> I'm not sure if this is an argument for SHOULD or what, but here's
> one additional thought..

> If the agent loses touch with the manager it could be for one or two
> reasons.  Either the manager intended to drop the connection or it
> didn't.  The key here is that the agent can't tell which is the
> case, and so even *if* the manager wanted to see status it couldn't.

> Under the "be conservative" principle we should assume that the
> manager wanted status, and so that argues for stopping when you
> realize there's a problem.

But maybe what the manager really WANTED was for the agent to perform
the request, and the manager merely WISHED to be informed about the
status.  In that case it would be better for the agent to continue
serving requests even though it cannot send back any status.

My gut feeling is that as a manager, I would normally prefer my
commands being executed even when I cannot receive status because the
channel breaks during the session.

Of course this is less true when the requests are really only about
getting information, i.e. "show" commands.  But for requests with side
effects, typically the side effects are more important to me than the
status response.
-- 
Simon.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Fri Oct  1 15:42:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10635
	for <netconf-archive@lists.ietf.org>; Fri, 1 Oct 2004 15:42:38 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CDTE9-0006ye-9y
	for netconf-data@psg.com; Fri, 01 Oct 2004 19:38:01 +0000
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CDTDq-0006vI-GB
	for netconf@ops.ietf.org; Fri, 01 Oct 2004 19:37:42 +0000
Received: from diotima.switch.ch (localhost [127.0.0.1])
	by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id i91JbdHK023088
	(version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 1 Oct 2004 21:37:39 +0200 (CEST)
Received: (from leinen@localhost)
	by diotima.switch.ch (8.12.11/8.12.11/Submit) id i91Jbd2l023087;
	Fri, 1 Oct 2004 21:37:39 +0200 (CEST)
To: <dbharrington@comcast.net>
Cc: "'Eliot Lear'" <lear@cisco.com>, "'netconf'" <netconf@ops.ietf.org>
Subject: Re: on <close-session>
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>
In-Reply-To: <E1CDONd-000AGy-UW@psg.com> (David B. Harrington's message of
 "Fri, 1 Oct 2004 10:27:16 -0400")
References: <E1CDONd-000AGy-UW@psg.com>
Date: Fri, 01 Oct 2004 21:37:38 +0200
Message-ID: <aapt42jkl9.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: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

David B Harrington writes:
> From RFC2119:
> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

> What implications would there be from not implementing to discard RPCs
> upon detection of a lost connection?

> One implication is the waste of bandwidth. If the use case of a
> manager not waiting for a response is not expected, then to be a
> good Internet citizen, one SHOULD cease processing.

Actually, since all our mappings use TCP at the lowest level, there
wouldn't even be loss of bandwidth, because the agent's TCP would
refuse to send TCP segments when it has detected that the connection
is broken.
-- 
Simon.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Oct 18 03:32:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23356
	for <netconf-archive@lists.ietf.org>; Mon, 18 Oct 2004 03:32:29 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJRoz-0006rm-1b
	for netconf-data@psg.com; Mon, 18 Oct 2004 07:20:45 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJRoy-0006rW-4G
	for netconf@ops.ietf.org; Mon, 18 Oct 2004 07:20:44 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 18 Oct 2004 00:27:59 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9I7KdOE013637;
	Mon, 18 Oct 2004 00:20:42 -0700 (PDT)
Received: from [144.254.23.127] (dhcp-data-vlan10-23-127.cisco.com [144.254.23.127])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9I7MlbA017676;
	Mon, 18 Oct 2004 00:22:48 -0700
Message-ID: <41736EC6.5050002@cisco.com>
Date: Mon, 18 Oct 2004 09:20:38 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041017)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rob Enns <rpe@juniper.net>, netconf <netconf@ops.ietf.org>
Subject: discussions with Wes and results..
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1098084169.486968"; x:"432200"; a:"rsa-sha1"; b:"nofws:4017";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw"
	"eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU"
	"tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"jH2xryMGH+tSEmihIJ86oFWYHUL0mJNEtBjqs1UggHWTw7o1JK2oKLwAHDVs4"
	"UnPKQzWIMC1FPKwy5Q2Nq+SnT1kTO2W+zVe5JeYs3+bzqNYYLpsoFHthSpHL4"
	"SCnPS8D8JXP2JA5XYmfqkuamFFDkj5/x9szZWpZ0jNBNHVagY=";
	c:"Date: Mon, 18 Oct 2004 09:20:38 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: discussions with Wes and results.."
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Rob,

Attached are some diffs of the changes that I'd like to see in the draft 
to address Wes' security concerns and one other omission.

Thanks,

Eliot


*** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
--- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
***************
*** 521,530 ****

      The authentication process should result in an entity whose
      permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.  For
!    example, if the native user interface restricts users from changing
!    the network interface configuration, the user should not be able to
!    change this configuration data using NETCONF.



--- 521,529 ----

      The authentication process should result in an entity whose
      permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.
!
!



***************
*** 2634,2639 ****
--- 2633,2657 ----

   8. Security Considerations

+    This standard does not specify an authorization scheme, as it was
+    viewed that such a scheme should be tied to a meta-data model or a
+    data model.  Implementators SHOULD also provide a well thought out
+    authorization scheme with NETCONF.
+
+    Authorization of individual users via the netconf agent may or may
+    not map 1:1 to other interfaces.  There are factors.  First, the
+    data models may be incompatable.  Second, it may be desirable to
+    authorize based on mechanisms such as netconf, telnet, ssh, etc.
+
+    In addition, operations on configurations may have unintended
+    consequences if those operations are also not guarded by the global
+    lock on the files or objects being operated upon.  For instance, a
+    partially complete access list could be committed from a candidate
+    configuration unbnownest to the owner of the lock of the candidate
+    configuration, leading to either an insecure or inaccessible device
+    if the lock on the candidate configuration does not also apply to
+    the <copy-config> operation when applied to it.
+
      Configuration information is by its very nature sensitive.  Its
      transmission in the clear and without integrity checking leaves
      devices open to classic so-called "person in the middle" attacks.
***************
*** 2679,2687 ****
      kill another netconf session programmatically from within netconf if
      one knows the session identifier of the offending session.  The other
      possible way to break a lock is to provide an function within the
!    craft interface.
!
!

   Enns, Editor           Expires December 18, 2004               [Page 48]
   ^L
--- 2697,2706 ----
      kill another netconf session programmatically from within netconf if
      one knows the session identifier of the offending session.  The other
      possible way to break a lock is to provide an function within the
!    craft interface.  These two mechanisms suffer from a race condition
!    that may be ameliorated by removing the offending user from an AAA
!    server.  However, such a solution is not useful in all deployment
!    scenarios, such as those where SSH public/private key pairs are used.

   Enns, Editor           Expires December 18, 2004               [Page 48]
   ^L
***************
*** 2766,2772 ****

         Margaret Wasserman, ThingMagic

!



--- 2785,2797 ----

         Margaret Wasserman, ThingMagic

!    The authors would like to awknowledge the members of the NETCONF
!    working group.  In particular, we would like to thank Wes Hardaker
!    for his persistance and patience in assisting us with security
!    considerations.  We would also like to thank Randy Presuhn, Sharon
!    Chisolm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing
!    Chen, Simon Leinen, Keith Allen and Dave Harrington for all of
!    their valuable advice.


--
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 Oct 18 09:03:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13565
	for <netconf-archive@lists.ietf.org>; Mon, 18 Oct 2004 09:03:39 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJWwQ-000GxU-AC
	for netconf-data@psg.com; Mon, 18 Oct 2004 12:48:46 +0000
Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJWwJ-000Gx4-1M
	for netconf@ops.ietf.org; Mon, 18 Oct 2004 12:48:39 +0000
Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220])
          by comcast.net (sccrmhc11) with SMTP
          id <200410181248380110076rkie>; Mon, 18 Oct 2004 12:48:38 +0000
Reply-To: <dbharrington@comcast.net>
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>, "'Rob Enns'" <rpe@juniper.net>,
        "'netconf'" <netconf@ops.ietf.org>
Subject: RE: discussions with Wes and results..
Date: Mon, 18 Oct 2004 08:48:38 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcS05GorFxewVdFWRxeAnwql4IMh2AAJ6gsw
In-Reply-To: <41736EC6.5050002@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Message-Id: <E1CJWwQ-000GxU-AC@psg.com>
Content-Transfer-Encoding: 7bit

Hi,

A few comments on your proposed changes, inline.

dbh

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On Behalf Of Eliot Lear
Sent: Monday, October 18, 2004 3:21 AM
To: Rob Enns; netconf
Subject: discussions with Wes and results..

Rob,

Attached are some diffs of the changes that I'd like to see in the
draft to address Wes' security concerns and one other omission.

Thanks,

Eliot


*** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
--- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
***************
*** 521,530 ****

      The authentication process should result in an entity whose
      permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.  For
!    example, if the native user interface restricts users from
changing
!    the network interface configuration, the user should not be able
to
!    change this configuration data using NETCONF.


Dbh> two points: 1) here yoy refer to the "native user interface" and
elsewhere you refer to the "craft interface". Are these the same? If
so, consistency would be good. I prefer natiuve user interface to
craft interface, because I don't know what craft is involved, and if
you have to be a craftsman to use it, it's probably not very
user-friendly. 2) How one coordinates NETCONF and the native user
interface is implementation-dependent.

--- 521,529 ----

      The authentication process should result in an entity whose
      permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.
!
!



***************
*** 2634,2639 ****
--- 2633,2657 ----

   8. Security Considerations

+    This standard does not specify an authorization scheme, as it was
+    viewed that such a scheme should be tied to a meta-data model or
a
+    data model.  Implementators SHOULD also provide a well thought
out
+    authorization scheme with NETCONF.

Dbh> I would eliminate the "it was viewed that" as being unnecessary.

+
+    Authorization of individual users via the netconf agent may or
may
+    not map 1:1 to other interfaces.  There are factors.  First, the
+    data models may be incompatable.  Second, it may be desirable to
+    authorize based on mechanisms such as netconf, telnet, ssh, etc.

Dbh> I would eliminate "There are factors." as being unnecessary. 

Dbh> I'm not sure I know what point you are making in the second
factor. Are you saying that these other schemes don't support
user-specific authorization, or are you saying that other NM
interfaces may use these approaches and the NETCONF scheme may be
incompatible with them? If the latter, wouldn't it be good to suggest
using compatible schemes, and wouldn't that already be covered in the
first point? So I'm not sure just what the second point is. Maybe you
should simply make the point that an administrator should try to
deploy networking devices in which the multiple NM interfaces utilize
the same or compatible security mechanisms. (It would be nice, of
course, if the IETF made such a thing possible by defining standards
that utilized the same or compatible securtiy mechanisms).

+
+    In addition, operations on configurations may have unintended
+    consequences if those operations are also not guarded by the
global
+    lock on the files or objects being operated upon.  For instance,
a
+    partially complete access list could be committed from a
candidate
+    configuration unbnownest to the owner of the lock of the
candidate
+    configuration, leading to either an insecure or inaccessible
device
+    if the lock on the candidate configuration does not also apply to
+    the <copy-config> operation when applied to it.
+
      Configuration information is by its very nature sensitive.  Its
      transmission in the clear and without integrity checking leaves
      devices open to classic so-called "person in the middle"
attacks.
***************
*** 2679,2687 ****
      kill another netconf session programmatically from within
netconf if
      one knows the session identifier of the offending session.  The
other
      possible way to break a lock is to provide an function within
the
!    craft interface.
!
!

   Enns, Editor           Expires December 18, 2004
[Page 48]
   ^L
--- 2697,2706 ----
      kill another netconf session programmatically from within
netconf if
      one knows the session identifier of the offending session.  The
other
      possible way to break a lock is to provide an function within
the
!    craft interface.  These two mechanisms suffer from a race
condition
!    that may be ameliorated by removing the offending user from an
AAA
!    server.  However, such a solution is not useful in all deployment
!    scenarios, such as those where SSH public/private key pairs are
used.

Dbh> ameliorated, huh? Does this have something to do with getting
lost at sea? Let me go get my dictionary ... ;-)

Dbh> I don't see how removing the offending user from the AAA server
does anything at all to ameliorate the situation. First, why is it
assumed that either NM interface utilizes a AAA server? Second, if a
AAA server is utilized, removing a user simply means the user's
authentication and authorization is no longer centrally managed, I
guess, and is likely to generate calls to the helpdesk when the user
is no longer allowed network access, or permitted to do other things
controlled using the AAA server. I don't see why that is an
improvement. If anything, I would think one could ameliorate the race
condition caused by inconsistent authorization by having both NM
interfaces use the same or compatible security schemes for their NM
interfaces, and utilizing a centralized AAA server to better
coordinate the authorizations. Therefore, I think you could ameliorate
the race condition by **adding** users to a AAA server. So this
paragraph needs some work.


   Enns, Editor           Expires December 18, 2004
[Page 48]
   ^L
***************
*** 2766,2772 ****

         Margaret Wasserman, ThingMagic

!



--- 2785,2797 ----

         Margaret Wasserman, ThingMagic

!    The authors would like to awknowledge the members of the NETCONF
!    working group.  In particular, we would like to thank Wes
Hardaker
!    for his persistance and patience in assisting us with security
!    considerations.  We would also like to thank Randy Presuhn,
Sharon
!    Chisolm, Juergen Schoenwalder, Glenn Waters, David Perkins,
Weijing
!    Chen, Simon Leinen, Keith Allen and Dave Harrington for all of
!    their valuable advice.


--
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 Oct 18 09:13:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14436
	for <netconf-archive@lists.ietf.org>; Mon, 18 Oct 2004 09:13:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJXAm-000J9C-PA
	for netconf-data@psg.com; Mon, 18 Oct 2004 13:03:36 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJXAf-000J7w-Kd
	for netconf@ops.ietf.org; Mon, 18 Oct 2004 13:03:29 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 18 Oct 2004 06:10:47 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9ID3QOE023870;
	Mon, 18 Oct 2004 06:03:27 -0700 (PDT)
Received: from [144.254.23.127] (dhcp-data-vlan10-23-127.cisco.com [144.254.23.127])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9ID5XBQ018495;
	Mon, 18 Oct 2004 06:05:34 -0700
Message-ID: <4173BF1C.3090206@cisco.com>
Date: Mon, 18 Oct 2004 15:03:24 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041018)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dbharrington@comcast.net
CC: "'Rob Enns'" <rpe@juniper.net>, "'netconf'" <netconf@ops.ietf.org>
Subject: Re: discussions with Wes and results..
References: <3fhi7r$7h444@sj-inbound-a.cisco.com>
In-Reply-To: <3fhi7r$7h444@sj-inbound-a.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1098104735.745113"; x:"432200"; a:"rsa-sha1"; b:"nofws:5939";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw"
	"eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU"
	"tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"De4d8mkJG6AcW2xRd5W6Tegkej96cQpZF/MT7UrcQ+kJhX+BGHiQPycMMyoe1"
	"5K27SqjeOkylPBCDMscMdHVnojW7D7Wvcf1oxh/TX5U0+mT/234lBe3U5+z3Y"
	"fzvz1WopUVty8LHK7aCN37WYgrESuaAqiSJGwwKAkfSLwxQqg=";
	c:"Date: Mon, 18 Oct 2004 15:03:24 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: discussions with Wes and results.."
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,

Thanks for your comments.  Please see my response inline.

David B Harrington wrote:
> Hi,
> 
> A few comments on your proposed changes, inline.
> 
> dbh
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> On Behalf Of Eliot Lear
> Sent: Monday, October 18, 2004 3:21 AM
> To: Rob Enns; netconf
> Subject: discussions with Wes and results..
> 
> Rob,
> 
> Attached are some diffs of the changes that I'd like to see in the
> draft to address Wes' security concerns and one other omission.
> 
> Thanks,
> 
> Eliot
> 
> 
> *** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
> --- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
> ***************
> *** 521,530 ****
> 
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.  For
> !    example, if the native user interface restricts users from
> changing
> !    the network interface configuration, the user should not be able
> to
> !    change this configuration data using NETCONF.
> 
> 
> Dbh> two points: 1) here yoy refer to the "native user interface" and
> elsewhere you refer to the "craft interface". Are these the same? If
> so, consistency would be good. I prefer natiuve user interface to
> craft interface, because I don't know what craft is involved, and if
> you have to be a craftsman to use it, it's probably not very
> user-friendly. 2) How one coordinates NETCONF and the native user
> interface is implementation-dependent.

<1> You're right and it doesn't matter here.
<2> It doesn't matter here.

Why?  You looked at the wrong side of the diff ;-)  Please see changed 
text below:
> 
> --- 521,529 ----
> 
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.
> !
> !
> 
> 
> 
> ***************
> *** 2634,2639 ****
> --- 2633,2657 ----
> 
>    8. Security Considerations
> 
> +    This standard does not specify an authorization scheme, as it was
> +    viewed that such a scheme should be tied to a meta-data model or
> a
> +    data model.  Implementators SHOULD also provide a well thought
> out
> +    authorization scheme with NETCONF.
> 
> Dbh> I would eliminate the "it was viewed that" as being unnecessary.

Fair enough.

> 
> +
> +    Authorization of individual users via the netconf agent may or
> may
> +    not map 1:1 to other interfaces.  There are factors.  First, the
> +    data models may be incompatable.  Second, it may be desirable to
> +    authorize based on mechanisms such as netconf, telnet, ssh, etc.
> 
> Dbh> I would eliminate "There are factors." as being unnecessary. 

Em.  This was *supposed* to be a count of factors.
> 
> Dbh> I'm not sure I know what point you are making in the second
> factor. Are you saying that these other schemes don't support
> user-specific authorization, or are you saying that other NM
> interfaces may use these approaches and the NETCONF scheme may be
> incompatible with them?

Egads.  Some wordsmithing seems necessary.  The point was that one 
should be able to authorize based on underlying transport.  For 
instance, one may trust netconf/BEEP over netconf/SSH (or visa versa)
--
>       kill another netconf session programmatically from within
> netconf if
>       one knows the session identifier of the offending session.  The
> other
>       possible way to break a lock is to provide an function within
> the
> !    craft interface.  These two mechanisms suffer from a race
> condition
> !    that may be ameliorated by removing the offending user from an
> AAA
> !    server.  However, such a solution is not useful in all deployment
> !    scenarios, such as those where SSH public/private key pairs are
> used.
> 
> Dbh> ameliorated, huh? Does this have something to do with getting
> lost at sea? Let me go get my dictionary ... ;-)

;-)

> 
> Dbh> I don't see how removing the offending user from the AAA server
> does anything at all to ameliorate the situation. First, why is it
> assumed that either NM interface utilizes a AAA server?

It shouldn't be.  My point is that use of a AAA server and the locking 
of that user's account can provide a limited form of protection against 
a guy who's doing a DOS attack (or for that matter a runaway script) by 
locking your config.

  Second, if a
> AAA server is utilized, removing a user simply means the user's
> authentication and authorization is no longer centrally managed, I
> guess, and is likely to generate calls to the helpdesk when the user
> is no longer allowed network access, or permitted to do other things
> controlled using the AAA server. I don't see why that is an
> improvement.

Remember, this is a mitigation against an attack.  Furthermore, as far 
as NETCONF is concerned, this is not something your local end user is 
going to run unless your local end user happesn to be a network 
administrator.

> If anything, I would think one could ameliorate the race>
> condition caused by inconsistent authorization by having both NM
> interfaces use the same or compatible security schemes for their NM
> interfaces, and utilizing a centralized AAA server to better
> coordinate the authorizations. Therefore, I think you could ameliorate
> the race condition by **adding** users to a AAA server. So this
> paragraph needs some work.

Let me agree with the last sentence since it seems we didn't state the 
problem clearly enough for you to discern what it was ;-).  But we still 
need words to this effect in order to cover our bases in security 
considerations.

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 Oct 18 09:23:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15132
	for <netconf-archive@lists.ietf.org>; Mon, 18 Oct 2004 09:23:33 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJXNU-000L1V-ET
	for netconf-data@psg.com; Mon, 18 Oct 2004 13:16:44 +0000
Received: from [32.97.110.130] (helo=e32.co.us.ibm.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJXNP-000L14-Sq; Mon, 18 Oct 2004 13:16:40 +0000
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9IDGdEx647064;
	Mon, 18 Oct 2004 09:16:39 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9IDGcqL141724;
	Mon, 18 Oct 2004 07:16:38 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IDGben007137;
	Mon, 18 Oct 2004 07:16:38 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144])
	by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IDGbAh007130;
	Mon, 18 Oct 2004 07:16:37 -0600
In-Reply-To: <E1CJWwQ-000GxU-AC@psg.com>
To: <dbharrington@comcast.net>
Cc: "'Eliot Lear'" <lear@cisco.com>, "'netconf'" <netconf@ops.ietf.org>,
        owner-netconf@ops.ietf.org, "'Rob Enns'" <rpe@juniper.net>
MIME-Version: 1.0
Subject: RE: discussions with Wes and results..
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
From: Robert Moore <remoore@us.ibm.com>
Message-ID: <OFCC44CD07.30C882B7-ON85256F31.00488460-85256F31.00493550@us.ibm.com>
Date: Mon, 18 Oct 2004 09:16:36 -0400
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M2_07222004 Beta 2|July
 22, 2004) at 10/18/2004 07:16:37,
	Serialize complete at 10/18/2004 07:16:37
Content-Type: multipart/alternative; boundary="=_alternative 0049344885256F31_="
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE 
	autolearn=ham version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0049344885256F31_=
Content-Type: text/plain; charset="US-ASCII"

Dave,

Admittedly, I've been following these discussions from a *great* distance. 
 But I read Eliot's second factor in a third way.  See <rem>/</rem> below.

Regards,
Bob

Bob Moore
Advanced Design and Technology
IBM Software Group System House
+1-919-254-4436
remoore@us.ibm.com


owner-netconf@ops.ietf.org wrote on 10/18/2004 08:48:38 AM:

> Hi,
> 
> A few comments on your proposed changes, inline.
> 
> dbh
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> On Behalf Of Eliot Lear
> Sent: Monday, October 18, 2004 3:21 AM
> To: Rob Enns; netconf
> Subject: discussions with Wes and results..
> 
> Rob,
> 
> Attached are some diffs of the changes that I'd like to see in the
> draft to address Wes' security concerns and one other omission.
> 
> Thanks,
> 
> Eliot
> 
> 
> *** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
> --- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
> ***************
> *** 521,530 ****
> 
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.  For
> !    example, if the native user interface restricts users from
> changing
> !    the network interface configuration, the user should not be able
> to
> !    change this configuration data using NETCONF.
> 
> 
> Dbh> two points: 1) here yoy refer to the "native user interface" and
> elsewhere you refer to the "craft interface". Are these the same? If
> so, consistency would be good. I prefer natiuve user interface to
> craft interface, because I don't know what craft is involved, and if
> you have to be a craftsman to use it, it's probably not very
> user-friendly. 2) How one coordinates NETCONF and the native user
> interface is implementation-dependent.
> 
> --- 521,529 ----
> 
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.
> !
> !
> 
> 
> 
> ***************
> *** 2634,2639 ****
> --- 2633,2657 ----
> 
>    8. Security Considerations
> 
> +    This standard does not specify an authorization scheme, as it was
> +    viewed that such a scheme should be tied to a meta-data model or
> a
> +    data model.  Implementators SHOULD also provide a well thought
> out
> +    authorization scheme with NETCONF.
> 
> Dbh> I would eliminate the "it was viewed that" as being unnecessary.
> 
> +
> +    Authorization of individual users via the netconf agent may or
> may
> +    not map 1:1 to other interfaces.  There are factors.  First, the
> +    data models may be incompatable.  Second, it may be desirable to
> +    authorize based on mechanisms such as netconf, telnet, ssh, etc.
> 
> Dbh> I would eliminate "There are factors." as being unnecessary. 
> 
> Dbh> I'm not sure I know what point you are making in the second
> factor. Are you saying that these other schemes don't support
> user-specific authorization, or are you saying that other NM
> interfaces may use these approaches and the NETCONF scheme may be
> incompatible with them? If the latter, wouldn't it be good to suggest
> using compatible schemes, and wouldn't that already be covered in the
> first point? So I'm not sure just what the second point is. Maybe you
> should simply make the point that an administrator should try to
> deploy networking devices in which the multiple NM interfaces utilize
> the same or compatible security mechanisms. (It would be nice, of
> course, if the IETF made such a thing possible by defining standards
> that utilized the same or compatible securtiy mechanisms).
<rem>
I think the second factor is talking about something different from both 
of these: the idea that for a given user U and a given configuration 
object C, U will be authorized to performs different operations on C 
depending on which of the listed mechanisms was used.  At the very least,
that's a possible reading of "...authorized based on mechanisms...."
</rem>
> 
> +
> +    In addition, operations on configurations may have unintended
> +    consequences if those operations are also not guarded by the
> global
> +    lock on the files or objects being operated upon.  For instance,
> a
> +    partially complete access list could be committed from a
> candidate
> +    configuration unbnownest to the owner of the lock of the
> candidate
> +    configuration, leading to either an insecure or inaccessible
> device
> +    if the lock on the candidate configuration does not also apply to
> +    the <copy-config> operation when applied to it.
> +
>       Configuration information is by its very nature sensitive.  Its
>       transmission in the clear and without integrity checking leaves
>       devices open to classic so-called "person in the middle"
> attacks.
> ***************
> *** 2679,2687 ****
>       kill another netconf session programmatically from within
> netconf if
>       one knows the session identifier of the offending session.  The
> other
>       possible way to break a lock is to provide an function within
> the
> !    craft interface.
> !
> !
> 
>    Enns, Editor           Expires December 18, 2004
> [Page 48]
>    ^L
> --- 2697,2706 ----
>       kill another netconf session programmatically from within
> netconf if
>       one knows the session identifier of the offending session.  The
> other
>       possible way to break a lock is to provide an function within
> the
> !    craft interface.  These two mechanisms suffer from a race
> condition
> !    that may be ameliorated by removing the offending user from an
> AAA
> !    server.  However, such a solution is not useful in all deployment
> !    scenarios, such as those where SSH public/private key pairs are
> used.
> 
> Dbh> ameliorated, huh? Does this have something to do with getting
> lost at sea? Let me go get my dictionary ... ;-)
> 
> Dbh> I don't see how removing the offending user from the AAA server
> does anything at all to ameliorate the situation. First, why is it
> assumed that either NM interface utilizes a AAA server? Second, if a
> AAA server is utilized, removing a user simply means the user's
> authentication and authorization is no longer centrally managed, I
> guess, and is likely to generate calls to the helpdesk when the user
> is no longer allowed network access, or permitted to do other things
> controlled using the AAA server. I don't see why that is an
> improvement. If anything, I would think one could ameliorate the race
> condition caused by inconsistent authorization by having both NM
> interfaces use the same or compatible security schemes for their NM
> interfaces, and utilizing a centralized AAA server to better
> coordinate the authorizations. Therefore, I think you could ameliorate
> the race condition by **adding** users to a AAA server. So this
> paragraph needs some work.
> 
> 
>    Enns, Editor           Expires December 18, 2004
> [Page 48]
>    ^L
> ***************
> *** 2766,2772 ****
> 
>          Margaret Wasserman, ThingMagic
> 
> !
> 
> 
> 
> --- 2785,2797 ----
> 
>          Margaret Wasserman, ThingMagic
> 
> !    The authors would like to awknowledge the members of the NETCONF
> !    working group.  In particular, we would like to thank Wes
> Hardaker
> !    for his persistance and patience in assisting us with security
> !    considerations.  We would also like to thank Randy Presuhn,
> Sharon
> !    Chisolm, Juergen Schoenwalder, Glenn Waters, David Perkins,
> Weijing
> !    Chen, Simon Leinen, Keith Allen and Dave Harrington for all of
> !    their valuable advice.
> 
> 
> --
> 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/>

--=_alternative 0049344885256F31_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Dave,</font>
<br>
<br><font size=2 face="sans-serif">Admittedly, I've been following these
discussions from a *great* distance. &nbsp;But I read Eliot's second factor
in a third way. &nbsp;See &lt;rem&gt;/&lt;/rem&gt; below.</font>
<br><font size=2 face="sans-serif"><br>
Regards,<br>
Bob<br>
<br>
Bob Moore<br>
Advanced Design and Technology<br>
IBM Software Group System House<br>
+1-919-254-4436<br>
remoore@us.ibm.com<br>
</font>
<br>
<br><font size=2><tt>owner-netconf@ops.ietf.org wrote on 10/18/2004 08:48:38
AM:<br>
<br>
&gt; Hi,<br>
&gt; <br>
&gt; A few comments on your proposed changes, inline.<br>
&gt; <br>
&gt; dbh<br>
&gt; <br>
&gt; -----Original Message-----<br>
&gt; From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]<br>
&gt; On Behalf Of Eliot Lear<br>
&gt; Sent: Monday, October 18, 2004 3:21 AM<br>
&gt; To: Rob Enns; netconf<br>
&gt; Subject: discussions with Wes and results..<br>
&gt; <br>
&gt; Rob,<br>
&gt; <br>
&gt; Attached are some diffs of the changes that I'd like to see in the<br>
&gt; draft to address Wes' security concerns and one other omission.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; <br>
&gt; Eliot<br>
&gt; <br>
&gt; <br>
&gt; *** draft-ietf-netconf-prot-03.txt &nbsp; &nbsp; &nbsp;Thu Oct &nbsp;7
17:07:33 2004<br>
&gt; --- draft-ietf-netconf-prot-03e.txt &nbsp; &nbsp; Thu Oct &nbsp;7
18:01:27 2004<br>
&gt; ***************<br>
&gt; *** 521,530 ****<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; The authentication process should result in an
entity whose<br>
&gt; &nbsp; &nbsp; &nbsp; permissions and capabilities are known to the
device. &nbsp;These<br>
&gt; ! &nbsp; &nbsp;permissions must be enforced during the NETCONF session.
&nbsp;For<br>
&gt; ! &nbsp; &nbsp;example, if the native user interface restricts users
from<br>
&gt; changing<br>
&gt; ! &nbsp; &nbsp;the network interface configuration, the user should
not be able<br>
&gt; to<br>
&gt; ! &nbsp; &nbsp;change this configuration data using NETCONF.<br>
&gt; <br>
&gt; <br>
&gt; Dbh&gt; two points: 1) here yoy refer to the &quot;native user interface&quot;
and<br>
&gt; elsewhere you refer to the &quot;craft interface&quot;. Are these
the same? If<br>
&gt; so, consistency would be good. I prefer natiuve user interface to<br>
&gt; craft interface, because I don't know what craft is involved, and
if<br>
&gt; you have to be a craftsman to use it, it's probably not very<br>
&gt; user-friendly. 2) How one coordinates NETCONF and the native user<br>
&gt; interface is implementation-dependent.<br>
&gt; <br>
&gt; --- 521,529 ----<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; The authentication process should result in an
entity whose<br>
&gt; &nbsp; &nbsp; &nbsp; permissions and capabilities are known to the
device. &nbsp;These<br>
&gt; ! &nbsp; &nbsp;permissions must be enforced during the NETCONF session.<br>
&gt; !<br>
&gt; !<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; ***************<br>
&gt; *** 2634,2639 ****<br>
&gt; --- 2633,2657 ----<br>
&gt; <br>
&gt; &nbsp; &nbsp;8. Security Considerations<br>
&gt; <br>
&gt; + &nbsp; &nbsp;This standard does not specify an authorization scheme,
as it was<br>
&gt; + &nbsp; &nbsp;viewed that such a scheme should be tied to a meta-data
model or<br>
&gt; a<br>
&gt; + &nbsp; &nbsp;data model. &nbsp;Implementators SHOULD also provide
a well thought<br>
&gt; out<br>
&gt; + &nbsp; &nbsp;authorization scheme with NETCONF.<br>
&gt; <br>
&gt; Dbh&gt; I would eliminate the &quot;it was viewed that&quot; as being
unnecessary.<br>
&gt; <br>
&gt; +<br>
&gt; + &nbsp; &nbsp;Authorization of individual users via the netconf agent
may or<br>
&gt; may<br>
&gt; + &nbsp; &nbsp;not map 1:1 to other interfaces. &nbsp;There are factors.
&nbsp;First, the<br>
&gt; + &nbsp; &nbsp;data models may be incompatable. &nbsp;Second, it may
be desirable to<br>
&gt; + &nbsp; &nbsp;authorize based on mechanisms such as netconf, telnet,
ssh, etc.<br>
&gt; <br>
&gt; Dbh&gt; I would eliminate &quot;There are factors.&quot; as being
unnecessary. <br>
&gt; <br>
&gt; Dbh&gt; I'm not sure I know what point you are making in the second<br>
&gt; factor. Are you saying that these other schemes don't support<br>
&gt; user-specific authorization, or are you saying that other NM<br>
&gt; interfaces may use these approaches and the NETCONF scheme may be<br>
&gt; incompatible with them? If the latter, wouldn't it be good to suggest<br>
&gt; using compatible schemes, and wouldn't that already be covered in
the<br>
&gt; first point? So I'm not sure just what the second point is. Maybe
you<br>
&gt; should simply make the point that an administrator should try to<br>
&gt; deploy networking devices in which the multiple NM interfaces utilize<br>
&gt; the same or compatible security mechanisms. (It would be nice, of<br>
&gt; course, if the IETF made such a thing possible by defining standards<br>
&gt; that utilized the same or compatible securtiy mechanisms).</tt></font>
<br><font size=2><tt>&lt;rem&gt;</tt></font>
<br><font size=2><tt>I think the second factor is talking about something
different from both </tt></font>
<br><font size=2><tt>of these: the idea that for a given user U and a given
configuration </tt></font>
<br><font size=2><tt>object C, U will be authorized to performs different
operations on C </tt></font>
<br><font size=2><tt>depending on which of the listed mechanisms was used.
&nbsp;At the very least,</tt></font>
<br><font size=2><tt>that's a possible reading of &quot;...authorized based
on mechanisms....&quot;</tt></font>
<br><font size=2><tt>&lt;/rem&gt;<br>
&gt; <br>
&gt; +<br>
&gt; + &nbsp; &nbsp;In addition, operations on configurations may have
unintended<br>
&gt; + &nbsp; &nbsp;consequences if those operations are also not guarded
by the<br>
&gt; global<br>
&gt; + &nbsp; &nbsp;lock on the files or objects being operated upon. &nbsp;For
instance,<br>
&gt; a<br>
&gt; + &nbsp; &nbsp;partially complete access list could be committed from
a<br>
&gt; candidate<br>
&gt; + &nbsp; &nbsp;configuration unbnownest to the owner of the lock of
the<br>
&gt; candidate<br>
&gt; + &nbsp; &nbsp;configuration, leading to either an insecure or inaccessible<br>
&gt; device<br>
&gt; + &nbsp; &nbsp;if the lock on the candidate configuration does not
also apply to<br>
&gt; + &nbsp; &nbsp;the &lt;copy-config&gt; operation when applied to it.<br>
&gt; +<br>
&gt; &nbsp; &nbsp; &nbsp; Configuration information is by its very nature
sensitive. &nbsp;Its<br>
&gt; &nbsp; &nbsp; &nbsp; transmission in the clear and without integrity
checking leaves<br>
&gt; &nbsp; &nbsp; &nbsp; devices open to classic so-called &quot;person
in the middle&quot;<br>
&gt; attacks.<br>
&gt; ***************<br>
&gt; *** 2679,2687 ****<br>
&gt; &nbsp; &nbsp; &nbsp; kill another netconf session programmatically
from within<br>
&gt; netconf if<br>
&gt; &nbsp; &nbsp; &nbsp; one knows the session identifier of the offending
session. &nbsp;The<br>
&gt; other<br>
&gt; &nbsp; &nbsp; &nbsp; possible way to break a lock is to provide an
function within<br>
&gt; the<br>
&gt; ! &nbsp; &nbsp;craft interface.<br>
&gt; !<br>
&gt; !<br>
&gt; <br>
&gt; &nbsp; &nbsp;Enns, Editor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Expires
December 18, 2004<br>
&gt; [Page 48]<br>
&gt; &nbsp; &nbsp;^L<br>
&gt; --- 2697,2706 ----<br>
&gt; &nbsp; &nbsp; &nbsp; kill another netconf session programmatically
from within<br>
&gt; netconf if<br>
&gt; &nbsp; &nbsp; &nbsp; one knows the session identifier of the offending
session. &nbsp;The<br>
&gt; other<br>
&gt; &nbsp; &nbsp; &nbsp; possible way to break a lock is to provide an
function within<br>
&gt; the<br>
&gt; ! &nbsp; &nbsp;craft interface. &nbsp;These two mechanisms suffer
from a race<br>
&gt; condition<br>
&gt; ! &nbsp; &nbsp;that may be ameliorated by removing the offending user
from an<br>
&gt; AAA<br>
&gt; ! &nbsp; &nbsp;server. &nbsp;However, such a solution is not useful
in all deployment<br>
&gt; ! &nbsp; &nbsp;scenarios, such as those where SSH public/private key
pairs are<br>
&gt; used.<br>
&gt; <br>
&gt; Dbh&gt; ameliorated, huh? Does this have something to do with getting<br>
&gt; lost at sea? Let me go get my dictionary ... ;-)<br>
&gt; <br>
&gt; Dbh&gt; I don't see how removing the offending user from the AAA server<br>
&gt; does anything at all to ameliorate the situation. First, why is it<br>
&gt; assumed that either NM interface utilizes a AAA server? Second, if
a<br>
&gt; AAA server is utilized, removing a user simply means the user's<br>
&gt; authentication and authorization is no longer centrally managed, I<br>
&gt; guess, and is likely to generate calls to the helpdesk when the user<br>
&gt; is no longer allowed network access, or permitted to do other things<br>
&gt; controlled using the AAA server. I don't see why that is an<br>
&gt; improvement. If anything, I would think one could ameliorate the race<br>
&gt; condition caused by inconsistent authorization by having both NM<br>
&gt; interfaces use the same or compatible security schemes for their NM<br>
&gt; interfaces, and utilizing a centralized AAA server to better<br>
&gt; coordinate the authorizations. Therefore, I think you could ameliorate<br>
&gt; the race condition by **adding** users to a AAA server. So this<br>
&gt; paragraph needs some work.<br>
&gt; <br>
&gt; <br>
&gt; &nbsp; &nbsp;Enns, Editor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Expires
December 18, 2004<br>
&gt; [Page 48]<br>
&gt; &nbsp; &nbsp;^L<br>
&gt; ***************<br>
&gt; *** 2766,2772 ****<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Margaret Wasserman, ThingMagic<br>
&gt; <br>
&gt; !<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --- 2785,2797 ----<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Margaret Wasserman, ThingMagic<br>
&gt; <br>
&gt; ! &nbsp; &nbsp;The authors would like to awknowledge the members of
the NETCONF<br>
&gt; ! &nbsp; &nbsp;working group. &nbsp;In particular, we would like to
thank Wes<br>
&gt; Hardaker<br>
&gt; ! &nbsp; &nbsp;for his persistance and patience in assisting us with
security<br>
&gt; ! &nbsp; &nbsp;considerations. &nbsp;We would also like to thank Randy
Presuhn,<br>
&gt; Sharon<br>
&gt; ! &nbsp; &nbsp;Chisolm, Juergen Schoenwalder, Glenn Waters, David
Perkins,<br>
&gt; Weijing<br>
&gt; ! &nbsp; &nbsp;Chen, Simon Leinen, Keith Allen and Dave Harrington
for all of<br>
&gt; ! &nbsp; &nbsp;their valuable advice.<br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; to unsubscribe send a message to netconf-request@ops.ietf.org with
the<br>
&gt; word 'unsubscribe' in a single line as the message text body.<br>
&gt; archive: &lt;http://ops.ietf.org/lists/netconf/&gt;<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; to unsubscribe send a message to netconf-request@ops.ietf.org with<br>
&gt; the word 'unsubscribe' in a single line as the message text body.<br>
&gt; archive: &lt;http://ops.ietf.org/lists/netconf/&gt;<br>
</tt></font>
--=_alternative 0049344885256F31_=--

--
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 Oct 18 14:09:21 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07878
	for <netconf-archive@lists.ietf.org>; Mon, 18 Oct 2004 14:09:20 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJbkd-0008wU-8o
	for netconf-data@psg.com; Mon, 18 Oct 2004 17:56:55 +0000
Received: from [207.17.137.105] (helo=juniper.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJbkc-0008wE-AH
	for netconf@ops.ietf.org; Mon, 18 Oct 2004 17:56:54 +0000
Received: from ([172.24.245.25])
	by jaffa.juniper.net with ESMTP ;
	Mon, 18 Oct 2004 10:56:15 -0700
Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 18 Oct 2004 10:56:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: discussions with Wes and results..
Date: Mon, 18 Oct 2004 10:56:14 -0700
Message-ID: <062B922B6EC55149B5A267ECE78E5D44070E220A@photon.jnpr.net>
Thread-Topic: discussions with Wes and results..
Thread-Index: AcS04vv2F98OgCuSSQ+jmiEEYrkXxwAWKOUQ
From: "Rob Enns" <rpe@juniper.net>
To: "Eliot Lear" <lear@cisco.com>, "netconf" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 18 Oct 2004 17:56:15.0472 (UTC) FILETIME=[C3224F00:01C4B53B]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Thanks Eliot, I'll integrate the changes (and include further
revisions as necessary based on the followup discussion).=20

Rob

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]=20
> Sent: Monday, October 18, 2004 12:21 AM
> To: Rob Enns; netconf
> Subject: discussions with Wes and results..
>=20
> Rob,
>=20
> Attached are some diffs of the changes that I'd like to see=20
> in the draft=20
> to address Wes' security concerns and one other omission.
>=20
> Thanks,
>=20
> Eliot
>=20
>=20
> *** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
> --- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
> ***************
> *** 521,530 ****
>=20
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.  For
> !    example, if the native user interface restricts users=20
> from changing
> !    the network interface configuration, the user should not=20
> be able to
> !    change this configuration data using NETCONF.
>=20
>=20
>=20
> --- 521,529 ----
>=20
>       The authentication process should result in an entity whose
>       permissions and capabilities are known to the device.  These
> !    permissions must be enforced during the NETCONF session.
> !
> !
>=20
>=20
>=20
> ***************
> *** 2634,2639 ****
> --- 2633,2657 ----
>=20
>    8. Security Considerations
>=20
> +    This standard does not specify an authorization scheme, as it was
> +    viewed that such a scheme should be tied to a meta-data=20
> model or a
> +    data model.  Implementators SHOULD also provide a well=20
> thought out
> +    authorization scheme with NETCONF.
> +
> +    Authorization of individual users via the netconf agent=20
> may or may
> +    not map 1:1 to other interfaces.  There are factors.  First, the
> +    data models may be incompatable.  Second, it may be desirable to
> +    authorize based on mechanisms such as netconf, telnet, ssh, etc.
> +
> +    In addition, operations on configurations may have unintended
> +    consequences if those operations are also not guarded by=20
> the global
> +    lock on the files or objects being operated upon.  For=20
> instance, a
> +    partially complete access list could be committed from a=20
> candidate
> +    configuration unbnownest to the owner of the lock of the=20
> candidate
> +    configuration, leading to either an insecure or=20
> inaccessible device
> +    if the lock on the candidate configuration does not also apply to
> +    the <copy-config> operation when applied to it.
> +
>       Configuration information is by its very nature sensitive.  Its
>       transmission in the clear and without integrity checking leaves
>       devices open to classic so-called "person in the=20
> middle" attacks.
> ***************
> *** 2679,2687 ****
>       kill another netconf session programmatically from=20
> within netconf if
>       one knows the session identifier of the offending=20
> session.  The other
>       possible way to break a lock is to provide an function=20
> within the
> !    craft interface.
> !
> !
>=20
>    Enns, Editor           Expires December 18, 2004          =20
>     [Page 48]
>    ^L
> --- 2697,2706 ----
>       kill another netconf session programmatically from=20
> within netconf if
>       one knows the session identifier of the offending=20
> session.  The other
>       possible way to break a lock is to provide an function=20
> within the
> !    craft interface.  These two mechanisms suffer from a=20
> race condition
> !    that may be ameliorated by removing the offending user=20
> from an AAA
> !    server.  However, such a solution is not useful in all deployment
> !    scenarios, such as those where SSH public/private key=20
> pairs are used.
>=20
>    Enns, Editor           Expires December 18, 2004          =20
>     [Page 48]
>    ^L
> ***************
> *** 2766,2772 ****
>=20
>          Margaret Wasserman, ThingMagic
>=20
> !
>=20
>=20
>=20
> --- 2785,2797 ----
>=20
>          Margaret Wasserman, ThingMagic
>=20
> !    The authors would like to awknowledge the members of the NETCONF
> !    working group.  In particular, we would like to thank=20
> Wes Hardaker
> !    for his persistance and patience in assisting us with security
> !    considerations.  We would also like to thank Randy=20
> Presuhn, Sharon
> !    Chisolm, Juergen Schoenwalder, Glenn Waters, David=20
> Perkins, Weijing
> !    Chen, Simon Leinen, Keith Allen and Dave Harrington for all of
> !    their valuable advice.
>=20
>=20
>=20

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Tue Oct 19 08:20:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16567
	for <netconf-archive@lists.ietf.org>; Tue, 19 Oct 2004 08:20:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CJsmT-0005NJ-4t
	for netconf-data@psg.com; Tue, 19 Oct 2004 12:07:57 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CJsUl-00036M-9v
	for netconf@ops.ietf.org; Tue, 19 Oct 2004 11:49:39 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14569;
	Tue, 19 Oct 2004 07:49:36 -0400 (EDT)
Message-Id: <200410191149.HAA14569@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-02.txt
Date: Tue, 19 Oct 2004 07:49:36 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64
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-02.txt
	Pages		: 13
	Date		: 2004-10-18
	
This document describes a simple 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-02.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-02.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-02.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:	<2004-10-18173207.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2004-10-18173207.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 Oct 21 04:33:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21420
	for <netconf-archive@lists.ietf.org>; Thu, 21 Oct 2004 04:33:37 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CKYF7-0004H7-GL
	for netconf-data@psg.com; Thu, 21 Oct 2004 08:24:17 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CKHm2-0003d3-TH
	for netconf@ops.ietf.org; Wed, 20 Oct 2004 14:49: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 KAA11410;
	Wed, 20 Oct 2004 10:49:07 -0400 (EDT)
Message-Id: <200410201449.KAA11410@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-02.txt
Date: Wed, 20 Oct 2004 10:49:07 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64
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-02.txt
	Pages		: 14
	Date		: 2004-10-19
	
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-02.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-02.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-02.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:	<2004-10-20105432.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2004-10-20105432.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 Oct 22 07:52:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25861
	for <netconf-archive@lists.ietf.org>; Fri, 22 Oct 2004 07:52:07 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CKxn2-000BaW-B9
	for netconf-data@psg.com; Fri, 22 Oct 2004 11:41:00 +0000
Received: from [202.119.230.11] (helo=njupt.edu.cn)
	by psg.com with smtp (Exim 4.41 (FreeBSD))
	id 1CKxn0-000BaD-Fm
	for netconf@ops.ietf.org; Fri, 22 Oct 2004 11:40:59 +0000
Received: (eyou send program); Fri, 22 Oct 2004 20:20:13 +0800
Message-ID: <298447613.06101@njupt.edu.cn>
Received: from 10.10.136.120 by 202.119.230.11 with HTTP; Fri, 22 Oct 2004 20:20:13 +0800
X-WebMAIL-MUA: [10.10.136.120]
From: "=?gb2312?B?zfW6sQ==?=" <y030737@njupt.edu.cn>
To: netconf@ops.ietf.org
Date: Fri, 22 Oct 2004 20:20:13 +0800
Reply-To: "=?gb2312?B?zfW6sQ==?=" <y030737@njupt.edu.cn>
X-Priority: 3
Subject: any difference between startup and running?
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Level: *
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,FROM_ENDS_IN_NUMS,
	MSGID_FROM_MTA_HEADER,PRIORITY_NO_NAME autolearn=no version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

dear all:

  I just read the draft-03, and I am confused by some description.

the draft said the running configure is the default target of many operation,

but later it mentioned the "startup" configure.

  I want to ask what is the difference between startup and running?

does the startup meaning the confuguration of a device when it is just begin to

running , in another word , the configuration before it send <hello>

element to others. 

  if it is , why we need a startup configuration? we can get the same information

through <get-config> , if we want to save the configuration when the device work

normally, we can save the configuration to candidate.



--
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 Oct 22 11:36:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14510
	for <netconf-archive@lists.ietf.org>; Fri, 22 Oct 2004 11:36:17 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CL1KJ-000PdK-MG
	for netconf-data@psg.com; Fri, 22 Oct 2004 15:27:35 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CL1KI-000Pd3-UZ
	for netconf@ops.ietf.org; Fri, 22 Oct 2004 15:27:34 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 22 Oct 2004 08:35:41 -0700
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 i9MFRV6s022727;
	Fri, 22 Oct 2004 08:27:31 -0700 (PDT)
Received: from abierman-xp.cisco.com (sjc-vpn4-780.cisco.com [10.21.83.11])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAH55493;
	Fri, 22 Oct 2004 08:27:30 -0700 (PDT)
Message-Id: <4.3.2.7.2.20041022082118.00cdb388@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 22 Oct 2004 08:27:29 -0700
To: "=?gb2312?B?zfW6sQ==?=" <y030737@njupt.edu.cn>
From: Andy Bierman <abierman@cisco.com>
Subject: Re: any difference between startup and running?
Cc: netconf@ops.ietf.org
In-Reply-To: <298447613.06101@njupt.edu.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

At 05:20 AM 10/22/2004, =?gb2312?B?zfW6sQ==?= wrote:
>dear all:

<running> is the active configuration
<startup> is the config that will be used on the next reboot

Some devices keep the <running> and <startup> config in synch
automatically.

Other devices do not automatically update the <startup> when
the <running> config is changed.  These devices will advertise 
the #startup capability to indicate that the <startup> config 
must be explicitly updated (e.g., copy-config from <running> 
to <startup>).

Andy



>  I just read the draft-03, and I am confused by some description.
>
>the draft said the running configure is the default target of many operation,
>
>but later it mentioned the "startup" configure.
>
>  I want to ask what is the difference between startup and running?
>
>does the startup meaning the confuguration of a device when it is just begin to
>
>running , in another word , the configuration before it send <hello>
>
>element to others. 
>
>  if it is , why we need a startup configuration? we can get the same information
>
>through <get-config> , if we want to save the configuration when the device work
>
>normally, we can save the configuration to candidate.
>
>
>
>--
>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 Oct 25 10:06:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27352
	for <netconf-archive@lists.ietf.org>; Mon, 25 Oct 2004 10:06:48 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CM5M9-000I69-MU
	for netconf-data@psg.com; Mon, 25 Oct 2004 13:57:53 +0000
Received: from [192.11.222.163] (helo=ihemail2.lucent.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CM5M5-000I5H-Qx
	for netconf@ops.ietf.org; Mon, 25 Oct 2004 13:57:49 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9PDvkBK016807
	for <netconf@ops.ietf.org>; Mon, 25 Oct 2004 08:57:47 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <4M322TWH>; Mon, 25 Oct 2004 15:57:46 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79DE7@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: FW: OASIS DCML Network technical committee
Date: Mon, 25 Oct 2004 15:57:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

FYI

-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
Sent: Monday, October 25, 2004 10:27
To: Bert Wijnen
Cc: David Kessens; Mike Baskey
Subject: OASIS DCML Network technical committee


Bert,

Here's another complication in the network management area that
I and my colleagues want to be sure you and David are aware of.

OASIS "adopted" the Data Center Markup Language (DCML) some time
ago, and the related Technical Committees are now started. One
of them is the DCML Network TC:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dcml-network

"The purpose of the OASIS DCML Network TC is to design a data model and
XML-based format for the exchange of information about networking
elements in a data center. The OASIS DCML Network TC builds on and
supports the DCML Framework specification produced by the OASIS DCML
Framework TC while focusing on the specifics of network equipment and
technology....

"In spite of the fuzzy definition of "network component," the following
are specifically in scope.

     * Connectivity and cabling
     * Layer 2 MAC bridging and switching
     * Layer 2 VLANs
     * Layer 3 switching and routing
     * Firewalls
     * Intrusion detection systems
     * IPSec Virtual Private Networks (VPNs)..."

The potential overlap and redundancy with Netconf is obvious. I have
not looked at this work in detail, so I can't say whether there is
actual overlap, but it seems to me this needs to be checked.

Regards
      Brian

--
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 Oct 25 11:09:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02909
	for <netconf-archive@lists.ietf.org>; Mon, 25 Oct 2004 11:09:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CM6MY-0002E4-Cn
	for netconf-data@psg.com; Mon, 25 Oct 2004 15:02:22 +0000
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CM6MH-0002Aq-Dx
	for netconf@ops.ietf.org; Mon, 25 Oct 2004 15:02:05 +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 i9PF22999064;
	Mon, 25 Oct 2004 08:02:02 -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 i9PF1ve24891;
	Mon, 25 Oct 2004 08:01:57 -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 i9PF1uBE017803;
	Mon, 25 Oct 2004 11:01:56 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200410251501.i9PF1uBE017803@idle.juniper.net>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: FW: OASIS DCML Network technical committee 
In-Reply-To: Your message of "Mon, 25 Oct 2004 15:57:40 +0200."
             <7D5D48D2CAA3D84C813F5B154F43B15503C79DE7@nl0006exch001u.nl.lucent.com> 
Date: Mon, 25 Oct 2004 11:01:56 -0400
From: Phil Shafer <phil@juniper.net>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

>From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
>not looked at this work in detail, so I can't say whether there is
>actual overlap, but it seems to me this needs to be checked.

This appears to be just bootstrapping.  The "Call For Participation"
was dated 10/29 and the mailing list and comments archives are
empty, as is the calendar.  The first meeting's 11/15 but there are
no details available.  The only participant listed in Inkra Networks,
though there are nine oasis members listed in the proposal, who
will assumably be involved.

Is anyone familiar with oasis?  Will the first meeting set up the
deliverables?  Is it more organizational?  How long before the
membership gels sufficient to begin forward progress?  How long
does an oasis tc typically exist?  Is anyone out there intending
on joining this TC?  Is anyone on existing oasis TCs?  What's your
experience been?

Each of the bullets listed as in scope seems like a fairly serious
chunk of work, but perhaps they are only doing framework issues or
are intending to reference existing standards (MIBs, etc).

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Mon Oct 25 11:28:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04444
	for <netconf-archive@lists.ietf.org>; Mon, 25 Oct 2004 11:28:12 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CM6fZ-0005bJ-RE
	for netconf-data@psg.com; Mon, 25 Oct 2004 15:22:01 +0000
Received: from [157.159.10.45] (helo=smtp2.int-evry.fr)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CM6fY-0005b6-UP
	for netconf@ops.ietf.org; Mon, 25 Oct 2004 15:22:01 +0000
Received: from [157.159.100.235] (MCI-050eb301d36.int-evry.fr [157.159.100.235])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 395332FD3A
	for <netconf@ops.ietf.org>; Mon, 25 Oct 2004 17:22:55 +0200 (CEST)
Message-ID: <417D19BC.5050408@int-evry.fr>
Date: Mon, 25 Oct 2004 17:20:28 +0200
From: noe <nejat_onay.erkose@int-evry.fr>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: RPC-->>XML-RPC ??
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel,
	SpamAssassin (score=-4.718, requis 4.5, autolearn=spam,
	ALL_TRUSTED -3.30, AWL -0.13, BAYES_00 -2.60, RATWR10_MESSID 0.65,
	SUBJ_ALL_CAPS 0.67)
X-MailScanner-From: nejat_onay.erkose@int-evry.fr
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello ,

  It has been a month that i have been trying to learn about NetConf and 
Beep and i am still trying to figure things out. And i have a question 
concerning the RPC layer. Is it possible to embed XML-RPC  in this 
layer? Or  smthg lighter will be used?
  Thanks.

--
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 Oct 29 04:05:28 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05449
	for <netconf-archive@lists.ietf.org>; Fri, 29 Oct 2004 04:05:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CNRZN-000Pwt-FY
	for netconf-data@psg.com; Fri, 29 Oct 2004 07:53:09 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CNGNa-000NeD-0H
	for netconf@ops.ietf.org; Thu, 28 Oct 2004 19:56:14 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28725;
	Thu, 28 Oct 2004 15:56:11 -0400 (EDT)
Message-Id: <200410281956.PAA28725@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-04.txt
Date: Thu, 28 Oct 2004 15:56:11 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64
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-04.txt
	Pages		: 82
	Date		: 2004-10-28
	
The NETCONF configuration protocol defined in this document provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices.  It uses an XML-based data encoding for the
   configuration data as well as the protocol messages.  The NETCONF
   protocol operations are realized on top of a simple RPC layer.

   Please send comments to netconf@ops.ietf.org.  To subscribe, use
   netconf-request@ops.ietf.org.

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

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

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

Content-Type: text/plain
Content-ID:	<2004-10-28155200.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 Oct 29 14:09:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20722
	for <netconf-archive@lists.ietf.org>; Fri, 29 Oct 2004 14:09:48 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CNazP-0003m0-Lz
	for netconf-data@psg.com; Fri, 29 Oct 2004 17:56:39 +0000
Received: from [129.188.136.8] (helo=motgate8.mot.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CNazO-0003la-Jr
	for netconf@ops.ietf.org; Fri, 29 Oct 2004 17:56:38 +0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9THw1nQ012416
	for <netconf@ops.ietf.org>; Fri, 29 Oct 2004 10:58:01 -0700 (MST)
Received: from motorola.com ([173.23.235.140])
	by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i9THtOJv021413
	for <netconf@ops.ietf.org>; Fri, 29 Oct 2004 12:55:25 -0500
Message-ID: <41828454.C8230321@motorola.com>
Date: Fri, 29 Oct 2004 12:56:36 -0500
From: Sandeep Adwankar <sandeep.adwankar@motorola.com>
Organization: Motorola Labs
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-netconf-prot-04.txt
References: <200410281956.PAA28725@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Not a big thing, but my schema validator complains about this

<!--
  -- <rpc> element
-->
The string "--" is not permitted within comments.

thanks,
Sandeep


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           : NETCONF Configuration Protocol
>         Author(s)       : R. Enns
>         Filename        : draft-ietf-netconf-prot-04.txt
>         Pages           : 82
>         Date            : 2004-10-28
>
> The NETCONF configuration protocol defined in this document provides
>    mechanisms to install, manipulate, and delete the configuration of
>    network devices.  It uses an XML-based data encoding for the
>    configuration data as well as the protocol messages.  The NETCONF
>    protocol operations are realized on top of a simple RPC layer.
>
>    Please send comments to netconf@ops.ietf.org.  To subscribe, use
>    netconf-request@ops.ietf.org.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-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-prot-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-prot-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-Type: text/plain
> Content-ID:     <2004-10-28155200.I-D@ietf.org>


--
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 Oct 29 14:32:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22111
	for <netconf-archive@lists.ietf.org>; Fri, 29 Oct 2004 14:32:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CNbQS-0007lu-Jh
	for netconf-data@psg.com; Fri, 29 Oct 2004 18:24:36 +0000
Received: from [65.221.135.10] (helo=mail-gw.carrieraccess.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CNbQ7-0007j0-95
	for netconf@ops.ietf.org; Fri, 29 Oct 2004 18:24:15 +0000
Received: from dmz-mail-gw.carrieraccess.com [172.1.1.254] by mail-gw.carrieraccess.com - SurfControl E-mail Filter (4.7); Fri, 29 Oct 2004 12:24:13 -0600
Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19)
	id <VR9G4JDS>; Fri, 29 Oct 2004 12:24:12 -0600
Message-ID: <52AB1243526C77459939EBB7976B622F1E03CE@newman.carrieraccess.com>
From: "Hedstrom, Brian" <BHedstrom@carrieraccess.com>
To: "'netconf@ops.ietf.org'" <netconf@ops.ietf.org>
Date: Fri, 29 Oct 2004 12:24:03 -0600
Subject: Testing and Diagnostics
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--=_NextPart_ST_12_24_13_Friday_October_29_2004_2276"
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_BOUND_NEXTPART autolearn=no version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

----=_NextPart_ST_12_24_13_Friday_October_29_2004_2276
Content-Type: text/plain;
	charset="iso-8859-1"

I realize that the NETCONF protocol is addressing the network configuration
and provisioning peice of network management.  It also seems to cover the
Performance Management side by specifying messages to retreive state data
which can include PM statistics.  In addition, it can also cover Inventory
Management by a similar state data retreival.
Obvisouly, it does not provide any fault management capabilities due to the
lack of autonomous message support (although SOAP/Web Services can solve
this).
But, has there been any discussion about Diagnostics and Testing?  Is this a
distictly different area than Configuration Management?  The model would
need to support:
1. Creating a standby configuration that will support the required testing
and take interfaces out of service, etc.
2. Activate/Commit this configuration while backing up the running config
3. Allowing a manager to initiate a test or series of tests (this can be
treated like a config change).
4. After the tests have completed (need a way to signify this since we
shouldn't necessarily rely on Trap notifications), need the ability for the
manager to retreive the testing results.
4a. May need the ability to cancel/abort any running tests
5. Replace the testing configuration with the backup running configuration.
 
Thanks,

Brian Hedstrom 
CarrierAccess 
NetworkValet EMS Product Development 
303.218.5429 - Office 
303.218.5629 - Fax 
bhedstrom@carrieraccess.com 

 

----=_NextPart_ST_12_24_13_Friday_October_29_2004_2276
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1476" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>I realize that the 
NETCONF protocol is addressing the network configuration and provisioning peice 
of network management.&nbsp; It also seems to cover the Performance Management 
side by specifying messages to retreive state data which can include PM 
statistics.&nbsp; In addition, it can also cover Inventory Management by a 
similar state data retreival.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>Obvisouly, it does 
not provide any fault management capabilities due to the lack of autonomous 
message support (although SOAP/Web Services can solve this).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>But, has there been 
any discussion about Diagnostics and Testing?&nbsp; Is this a distictly 
different area than Configuration Management?&nbsp; The model would need to 
support:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>1. Creating a 
standby configuration that will support the required testing and take interfaces 
out of service, etc.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>2. Activate/Commit 
this configuration while backing up the running config</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>3. Allowing a 
manager to initiate a test or series of tests (this can be treated like a config 
change).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>4. After the tests 
have completed (need a way to signify this since we shouldn't necessarily rely 
on Trap notifications), need the ability for the manager to retreive the testing 
results.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>4a. May need the 
ability to cancel/abort any running tests</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=725291318-29102004>5. Replace the 
testing configuration with the backup running configuration.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=725291318-29102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=725291318-29102004>Thanks,</SPAN></FONT></DIV>
<P><B><FONT face=Arial>Brian Hedstrom</FONT></B> <BR><FONT face=Arial 
size=1>Carrier</FONT><B><I><FONT face=Arial 
size=1>Access</FONT></I></B><I></I><FONT face=Arial size=1> </FONT><BR><FONT 
face=Arial size=1>NetworkValet EMS Product Development</FONT> <BR><FONT 
face=Arial size=1>303.218.5429 - Office</FONT> <BR><FONT face=Arial 
size=1>303.218.5629 - Fax</FONT> <BR><FONT face=Arial 
size=1>bhedstrom@carrieraccess.com</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

----=_NextPart_ST_12_24_13_Friday_October_29_2004_2276--


--
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 Oct 29 15:00:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24258
	for <netconf-archive@lists.ietf.org>; Fri, 29 Oct 2004 15:00:22 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1CNbpz-0009zw-7u
	for netconf-data@psg.com; Fri, 29 Oct 2004 18:50:59 +0000
Received: from [207.17.137.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1CNbpy-0009z8-Cy
	for netconf@ops.ietf.org; Fri, 29 Oct 2004 18:50:58 +0000
Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25)
  by kremlin.juniper.net with ESMTP; 29 Oct 2004 11:50:58 -0700
X-BrightmailFiltered: true
X-Ironport-AV: i="3.86,110,1096873200"; 
   d="scan'208"; a="30872954:sNHT22593782"
Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 29 Oct 2004 11:50:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: I-D ACTION:draft-ietf-netconf-prot-04.txt
Date: Fri, 29 Oct 2004 11:50:56 -0700
Message-ID: <062B922B6EC55149B5A267ECE78E5D44070E28B0@photon.jnpr.net>
Thread-Topic: I-D ACTION:draft-ietf-netconf-prot-04.txt
Thread-Index: AcS94OIy1wi2bTDBSoaxOLzdMnomzgAB01OQ
From: "Rob Enns" <rpe@juniper.net>
To: "Sandeep Adwankar" <sandeep.adwankar@motorola.com>, <netconf@ops.ietf.org>
X-OriginalArrivalTime: 29 Oct 2004 18:50:57.0593 (UTC) FILETIME=[39F97A90:01C4BDE8]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Thanks Sandeep...=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sandeep Adwankar
> Sent: Friday, October 29, 2004 10:57 AM
> To: netconf@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-netconf-prot-04.txt
>=20
> Not a big thing, but my schema validator complains about this
>=20
> <!--
>   -- <rpc> element
> -->
> The string "--" is not permitted within comments.
>=20
> thanks,
> Sandeep
>=20
>=20
> Internet-Drafts@ietf.org wrote:
>=20
> > A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> > This draft is a work item of the Network Configuration=20
> Working Group of the IETF.
> >
> >         Title           : NETCONF Configuration Protocol
> >         Author(s)       : R. Enns
> >         Filename        : draft-ietf-netconf-prot-04.txt
> >         Pages           : 82
> >         Date            : 2004-10-28
> >
> > The NETCONF configuration protocol defined in this document provides
> >    mechanisms to install, manipulate, and delete the=20
> configuration of
> >    network devices.  It uses an XML-based data encoding for the
> >    configuration data as well as the protocol messages.  The NETCONF
> >    protocol operations are realized on top of a simple RPC layer.
> >
> >    Please send comments to netconf@ops.ietf.org.  To subscribe, use
> >    netconf-request@ops.ietf.org.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-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=20
> the body of the message.
> > You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login=20
> 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-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-prot-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=20
> the "FILE"
> >         command.  To decode the response(s), you will need=20
> "munpack" or
> >         a MIME-compliant mail reader.  Different=20
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which=20
> have been split
> >         up into multiple messages), so check your local=20
> 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.
> >
> >  =20
> --------------------------------------------------------------
> ----------
> > Content-Type: text/plain
> > Content-ID:     <2004-10-28155200.I-D@ietf.org>
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=20
>=20

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Sun Oct 31 12:33:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15735
	for <netconf-archive@lists.ietf.org>; Sun, 31 Oct 2004 12:33:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COJSK-0004p7-5R
	for netconf-data@psg.com; Sun, 31 Oct 2004 17:25:28 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COJSB-0004oK-DU
	for netconf@ops.ietf.org; Sun, 31 Oct 2004 17:25:19 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 31 Oct 2004 09:35:12 -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 i9VHOrnC011181
	for <netconf@ops.ietf.org>; Sun, 31 Oct 2004 09:24:54 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn5-1096.cisco.com [10.21.92.72])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAO97473;
	Sun, 31 Oct 2004 09:25:15 -0800 (PST)
Message-Id: <4.3.2.7.2.20041031090744.02368f08@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 31 Oct 2004 09:25:15 -0700
To: netconf@ops.ietf.org
From: Andy Bierman <abierman@cisco.com>
Subject: Begin WG Last Call: draft-ietf-netconf-beep-02
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Hi,

The NETCONF WG has completed work on the document "Using the NETCONF 
Protocol over Blocks Extensible Exchange Protocol (BEEP)".
The WG proposes that the Internet draft 'draft-ietf-netconf-beep-02.txt'
is the completed version of this document.  This document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-02.txt

Abstract:
   This document specifies an application protocol mapping for the
   NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).

The WG members are strongly urged to review this document as 
soon as possible, and express any concerns, or identify any errors,
in an email to the NETCONF WG mailing list.

Unless there are strong objections, published on the NETCONF WG mailing
list by November 28, 2004, this document will be forwarded to the OPS 
Area Directors for standards track consideration by the IESG.

Please send all comments to the WG mailing list at netconf@ops.ietf.org.

Andy and Simon


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Sun Oct 31 12:33:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15761
	for <netconf-archive@lists.ietf.org>; Sun, 31 Oct 2004 12:33:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COJSV-0004u2-GL
	for netconf-data@psg.com; Sun, 31 Oct 2004 17:25:39 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COJSU-0004tK-Hi
	for netconf@ops.ietf.org; Sun, 31 Oct 2004 17:25:38 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 31 Oct 2004 09:35:31 -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 i9VHPCnC011220
	for <netconf@ops.ietf.org>; Sun, 31 Oct 2004 09:25:13 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn5-1096.cisco.com [10.21.92.72])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAO97479;
	Sun, 31 Oct 2004 09:25:35 -0800 (PST)
Message-Id: <4.3.2.7.2.20041031091816.01dc9d78@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 31 Oct 2004 09:25:35 -0700
To: netconf@ops.ietf.org
From: Andy Bierman <abierman@cisco.com>
Subject: Begin WG Last Call: draft-ietf-netconf-ssh-02
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Hi,

The NETCONF WG has completed work on the document "Using the NETCONF
Configuration Protocol over Secure Shell (SSH)".  The WG proposes 
that the Internet draft 'draft-ietf-netconf-ssh-02.txt' is the 
completed version of this document.  This document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-02.txt

Abstract:
   This document describes a simple method for invoking and running the
   NETCONF configuration protocol within a Secure Shell (SSH) session as
   an SSH subsystem.

The WG members are strongly urged to review this document as 
soon as possible, and express any concerns, or identify any errors,
in an email to the NETCONF WG mailing list.

Unless there are strong objections, published on the NETCONF WG mailing
list by November 28, 2004, this document will be forwarded to the OPS 
Area Directors for standards track consideration by the IESG.

Please send all comments to the WG mailing list at netconf@ops.ietf.org.

Andy and Simon


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Sun Oct 31 12:34:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15827
	for <netconf-archive@lists.ietf.org>; Sun, 31 Oct 2004 12:34:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COJRx-0004lX-34
	for netconf-data@psg.com; Sun, 31 Oct 2004 17:25:05 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COJRw-0004lC-7f
	for netconf@ops.ietf.org; Sun, 31 Oct 2004 17:25:04 +0000
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 31 Oct 2004 09:34:57 -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 i9VHOcnC011140
	for <netconf@ops.ietf.org>; Sun, 31 Oct 2004 09:24:38 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn5-1096.cisco.com [10.21.92.72])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAO97463;
	Sun, 31 Oct 2004 09:25:01 -0800 (PST)
Message-Id: <4.3.2.7.2.20041031090013.02b62948@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 31 Oct 2004 09:25:00 -0700
To: netconf@ops.ietf.org
From: Andy Bierman <abierman@cisco.com>
Subject: Begin WG Last Call: draft-ietf-netconf-prot-04
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Hi,

The NETCONF WG has completed work on the NETCONF Configuration
Protocol.  The WG proposes that the Internet draft
'draft-ietf-netconf-prot-04.txt' is the completed version of 
this document.  This document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-04.txt

Abstract:
   The NETCONF configuration protocol defined in this document provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices.  It uses an XML-based data encoding for the
   configuration data as well as the protocol messages.  The NETCONF
   protocol operations are realized on top of a simple RPC layer.

The WG members are strongly urged to review this document as 
soon as possible, and express any concerns, or identify any errors,
in an email to the NETCONF WG mailing list.

Unless there are strong objections, published on the NETCONF WG mailing
list by November 28, 2004, this document will be forwarded to the OPS 
Area Directors for standards track consideration by the IESG.

Please send all comments to the WG mailing list at netconf@ops.ietf.org.

Andy and Simon




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


From owner-netconf@ops.ietf.org  Sun Oct 31 13:21:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15758
	for <netconf-archive@lists.ietf.org>; Sun, 31 Oct 2004 12:33:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COJUX-0005BY-36
	for netconf-data@psg.com; Sun, 31 Oct 2004 17:27:45 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COJUW-0005Ae-5y
	for netconf@ops.ietf.org; Sun, 31 Oct 2004 17:27:44 +0000
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 31 Oct 2004 09:37:37 -0800
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 i9VHRbom000962;
	Sun, 31 Oct 2004 09:27:37 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn5-1096.cisco.com [10.21.92.72])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAO97541;
	Sun, 31 Oct 2004 09:27:40 -0800 (PST)
Message-Id: <4.3.2.7.2.20041031092645.02383488@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 31 Oct 2004 09:27:40 -0700
To: agenda@ietf.org
From: Andy Bierman <abierman@cisco.com>
Subject: NETCONF WG agenda for IETF #61
Cc: netconf@ops.ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_338649191==_"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

--=====================_338649191==_
Content-Type: text/plain; charset="us-ascii"


--=====================_338649191==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="netconf_ietf61_agenda.txt"

Network Configuration WG (netconf)
IETF #61
November 11, 2004 : 1300 - 1500
===============================

Chairs:  

Simon Leinen <simon@switch.ch>
Andy Bierman <abierman@cisco.com>

Agenda:

  - Discussion of WG Documents
    - NETCONF Configuration Protocol
    - Using the NETCONF Protocol over BEEP
    - Using the NETCONF Protocol over SOAP
    - Using the NETCONF Protocol over SSH

Internet Drafts:

NETCONF Configuration Protocol
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-04.txt

Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
(BEEP)
http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-02.txt

Using the Network Configuration Protocol (NETCONF) Over the Simple
Object Access Protocol (SOAP)
http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-03.txt

Using the NETCONF Configuration Protocol over Secure Shell (SSH)
http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-02.txt



--=====================_338649191==_--


--
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  Sun Oct 31 13:21:10 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15765
	for <netconf-archive@lists.ietf.org>; Sun, 31 Oct 2004 12:33:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1COJSM-0004pT-9Q
	for netconf-data@psg.com; Sun, 31 Oct 2004 17:25:30 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1COJSL-0004pC-GR
	for netconf@ops.ietf.org; Sun, 31 Oct 2004 17:25:29 +0000
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 31 Oct 2004 09:35:22 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9VHPQcp013857
	for <netconf@ops.ietf.org>; Sun, 31 Oct 2004 09:25:26 -0800 (PST)
Received: from abierman-xp.cisco.com (sjc-vpn5-1096.cisco.com [10.21.92.72])
	by mira-sjc5-c.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAO97477;
	Sun, 31 Oct 2004 09:25:26 -0800 (PST)
Message-Id: <4.3.2.7.2.20041031091223.023766c0@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 31 Oct 2004 09:25:25 -0700
To: netconf@ops.ietf.org
From: Andy Bierman <abierman@cisco.com>
Subject: Begin WG Last Call: draft-ietf-netconf-soap-03
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Hi,

The NETCONF WG has completed work on the document "Using the Network
Configuration Protocol (NETCONF) Over the Simple Object Access 
Protocol (SOAP)".  The WG proposes that the Internet draft
'draft-ietf-netconf-soap-03.txt' is the completed version of 
this document.  This document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-03.txt

Abstract:
   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 that yield application protocols sufficient for
   NETCONF.

The WG members are strongly urged to review this document as 
soon as possible, and express any concerns, or identify any errors,
in an email to the NETCONF WG mailing list.

Unless there are strong objections, published on the NETCONF WG mailing
list by November 28, 2004, this document will be forwarded to the OPS 
Area Directors for standards track consideration by the IESG.

Please send all comments to the WG mailing list at netconf@ops.ietf.org.

Andy and Simon


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>