From owner-netconf@ops.ietf.org Wed Mar 01 06:37:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEPdi-0002bS-BF
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 06:37:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEPdh-0001qV-RS
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 06:37:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEPW4-0008Mt-0h
	for netconf-data@psg.com; Wed, 01 Mar 2006 11:29:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.163] (helo=ihemail2.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FEPW2-0008Mf-Pn
	for netconf@ops.ietf.org; Wed, 01 Mar 2006 11:29:10 +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 k21BT5wZ018109;
	Wed, 1 Mar 2006 05:29:06 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <DVB4YAYA>; Wed, 1 Mar 2006 12:29:04 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Eliot Lear (E-mail)" <lear@cisco.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        "Elwyn Davies (E-mail)"
	 <elwynd@dial.pipex.com>
Subject: FW: Gen-art review of draft-ietf-netconf-beep-08.txt
Date: Wed, 1 Mar 2006 12:29:04 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78

Not sure how much of this (if any) will make it into a DISCUSS,
but since (I believe) Eliot is in Europ, I decided to forward
rigth away, so Eliot can check and respond. Pls copy IESG
on your response (unless you just want to check with the WG
first). I did not analyze these comments yet myself, they
just came in.

Bert

-----Original Message-----
From: Elwyn Davies [mailto:elwynd@dial.pipex.com]
Sent: Wednesday, March 01, 2006 12:05
To: gen-art@ietf.org
Cc: Mary Barnes; Wijnen, Bert (Bert)
Subject: Gen-art review of draft-ietf-netconf-beep-08.txt


I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-netconf-beep-08.txt
Intended Status: Proposed Standard (WG submission)
Shepherding AD: Bert Wijnen
Review Trigger: IESG Telechat 2 March 2006

Summary:
This document is not ready for PS.

There is a considerable lack of clarity in mapping the requirements and 
roles between the various protocols which are being combined in this 
protocol, and the manager/agent terminology used has been eschewed by 
NETCONF in favour of client/server.  If used at all manager/agent 
terminology should be confined to the 'reversability' motivation in the 
introduction.

The emphasis on reversability may be confusing: Checking with the 
NETCONF protocol, if I understand correctly, a given endpoint in a 
session is confined to being a client or a server.  Thus although a BEEP 
channel is reversible the NETCONF session that runs over it is not and 
indeed the transport protocol has to tell NETCONF which sort of endpoint 
(client or server) it is.

The security considerations section specifies requirements and 
operations rather than just discussing the threats and their mitigation.

Review:

Endpoint roles:
There are three pairs of terms in use in the draft for the roles of the 
two ends of the conversation:
1. manager and agent (sort of implicitly how NETCONF would use the profile)
2. listener and initiator (BEEP)
3. client and server (TLS)
The mapping between the terms in 1 and 2 is apparently explained in s2.1 
but this explanation is not really a complete reflection of the 
situation explained in the BEEP RFC: ie the client/server terminology 
for the initial setup followed by the listener/initiator terminology for 
subsequent exchanges. In turn the mapping between 2 and 3 is not made 
explicit - I thought I could guess but after reflection I am not 
absolutely sure and it would be sensible to make it absolutely clear.

However NETCONF does not talk about managers and agents but about 
clients and servers, and BEEP also talks about clients and servers after 
the channel is set up. So we really ought to be talking about four pairs 
of roles and how they interrelate:
1. NETCONF client and server (this is what the profile has to support)
2. BEEP listener and initiator (setting up a channel from either end)
3. BEEP client and server (mapping to NETCONF and emphasising that it is 
not tied to listener/initiator roles)
4. TLS client and server (not sure which way round this is supposed to map)

I don't think the document overall expresses what needs to be said here 
and also doesn't give the semantics to express which way round the 
eventual NETCONF client/server connection is going to be setup.


Message and object conventions:
BEEP messages vs XML objects:
Much as I like to see the proper pleasantries being exchanged before the 
manager and agent get down to business, I think that when para 1 of s2.1 
says 'greetings are exchanged' I think it means '(BEEP) Greeting 
messages are exchanged' (2 places).

In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This 
presumably means in the first Greeting message but it could also be 
talking about the <greeting> element in that message - this is a bit 
confusing unless you are very familiar with BEEP.  I think it would be 
best to say 'in the first BEEP Greeting message' here, or alternatively 
'in the <greeting> element of the first BEEP Greeting message.

Version of SASL PLAIN to be used:
This specification refers to RFC2595 but the SASL PLAIN mechanism is 
currently under revision (see draft-ietf-sasl-plain-08.txt).  Should 
this (new) specification be using the new PLAIN specification? The 
latter part of para 5 of s2.1 seems a bit garbled and tautologous - 
rework needed.

Certificate management:
I was wondering whether some of the material from s5.2 of RFC3259 
regardsing serverName etc could be usefully repeated here?

Channels:
If I understand correctly, everything in s2.1 leads to the first BEEP 
channel (channel 0) being established between a pair of elements.  I 
think it would be good to mention channel 0 here because otherwise it 
makes its first appearance in s2.4 when it is being closed.

Extra channels:
>
>    Certain NETCONF capabilities may require additional BEEP channels.
>    When such capabilities are defined, a BEEP mapping must be defined 
> as well
>
The phraseology used here doesn't make it very clear if this is about 
possible future extensions or something that already exists.  If some do 
exist it would be good to give an example.  I am not sure how the second 
sentence ties in with the original statement in the abstract i.e. that 
this document *is* the BEEP mapping for NETCONF!  This probably ought to 
go in a separate extensibility section.

s2.4, Locks:
A pointer to the relevant section of ref [1] talking about locks would 
be helpful

s3, requirements:
The material after the second sentence of the second paragraph is about 
requirements and specification of how TLS and SASL are  to be used.  
This doesn't belong here.  It should all be specified before we get to 
this section.  It should probably make it clear that TLS is recommended 
rather than mandatory.


Editorial nits:
[Abstract: I take it from draft-netconf-prot that NETCONF is not an 
acronym.]

BEEP messages: It doesn't desperately matter but are the message 
character counts right?  I wasn't sufficiently anally retentive to check 
them.

s1.1: s/transportlayer/transport layer/
s1.1: Expand CLI acronym.

s2.2, para 1: s/new channel/a new channel/

s2.3: s/<rpc> tag/<rpc> element/ (?)

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



From owner-netconf@ops.ietf.org Wed Mar 01 08:42:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FERag-0000qv-4N
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 08:42:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FERaf-00064Z-Ho
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 08:42:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FERTC-000IwI-4v
	for netconf-data@psg.com; Wed, 01 Mar 2006 13:34:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FERTB-000Iw5-BZ
	for netconf@ops.ietf.org; Wed, 01 Mar 2006 13:34:21 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-3.cisco.com with ESMTP; 01 Mar 2006 05:34:21 -0800
X-IronPort-AV: i="4.02,156,1139212800"; 
   d="scan'208"; a="411240623:sNHT36077628"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k21DYKVb000209;
	Wed, 1 Mar 2006 05:34:20 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4397.cisco.com [10.61.81.44])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k21DaTGM017318;
	Wed, 1 Mar 2006 05:36:34 -0800
Message-ID: <4405A2D4.6000401@cisco.com>
Date: Wed, 01 Mar 2006 14:34:12 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        "Elwyn Davies (E-mail)" <elwynd@dial.pipex.com>
Subject: Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt
References: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=7814; t=1141220196; x=1141652396;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20FW=3A=20Gen-art=20review=20of=20draft-ietf-netconf-beep-08.txt
	|To:=22Wijnen,=20Bert=20(Bert)=22=20<bwijnen@lucent.com>;
	X=v=3Dmtcc.com=3B=20h=3Do7ro44+z0+Hl5LNpSQKRthpxC5o=3D; b=gKAKadl2SRuQsgVPOgLBcvZ/lUctoP7q/LQclbP36lfPDswsR2lADliZVkycBXFh3UR89OQ/
	w7WVayaMHy6urMhqdyfpIuKmFyS7ypXjY8Pvwb7xUKBbebmWRQNxrx3Uf1rkKN7e1l+j8EFLYYu
	qcq7zEw41+7+tichgYE1S8yI=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7

Elwyn,

Thank you for your review.  Please find my responses below.
> There is a considerable lack of clarity in mapping the requirements and 
> roles between the various protocols which are being combined in this 
> protocol, and the manager/agent terminology used has been eschewed by 
> NETCONF in favour of client/server.  If used at all manager/agent 
> terminology should be confined to the 'reversability' motivation in the 
> introduction.
>   

In the community we find ourselves, manager and agent are well
understood terms.  Anyone who does not understand them is unlikely to
implement the protocol.  If there is a bug, it is in the base
specification in the use of the terms client and server, as they can be
overloaded beyond recognition.

> The emphasis on reversability may be confusing: Checking with the 
> NETCONF protocol, if I understand correctly, a given endpoint in a 
> session is confined to being a client or a server.  Thus although a BEEP 
> channel is reversible the NETCONF session that runs over it is not and 
> indeed the transport protocol has to tell NETCONF which sort of endpoint 
> (client or server) it is.
>   
Apparently it did not sufficiently confuse you.  You understood what we
meant.
> The security considerations section specifies requirements and 
> operations rather than just discussing the threats and their mitigation.
>   

The security considerations section should be viewed in the context of
the base protocol.  I will not reiterate everything said there.

> Review:
>
> Endpoint roles:
> There are three pairs of terms in use in the draft for the roles of the 
> two ends of the conversation:
> 1. manager and agent (sort of implicitly how NETCONF would use the profile)
> 2. listener and initiator (BEEP)
> 3. client and server (TLS)
> The mapping between the terms in 1 and 2 is apparently explained in s2.1 
> but this explanation is not really a complete reflection of the 
> situation explained in the BEEP RFC: ie the client/server terminology 
> for the initial setup followed by the listener/initiator terminology for 
> subsequent exchanges. In turn the mapping between 2 and 3 is not made 
> explicit - I thought I could guess but after reflection I am not 
> absolutely sure and it would be sensible to make it absolutely clear.
>
> However NETCONF does not talk about managers and agents but about 
> clients and servers, and BEEP also talks about clients and servers after 
> the channel is set up. So we really ought to be talking about four pairs 
> of roles and how they interrelate:
> 1. NETCONF client and server (this is what the profile has to support)
> 2. BEEP listener and initiator (setting up a channel from either end)
> 3. BEEP client and server (mapping to NETCONF and emphasising that it is 
> not tied to listener/initiator roles)
> 4. TLS client and server (not sure which way round this is supposed to map)
>
> I don't think the document overall expresses what needs to be said here 
> and also doesn't give the semantics to express which way round the 
> eventual NETCONF client/server connection is going to be setup.
>   

I have proposed a change to the mapping to address this point, but
ultimately it has boiled down to this: a manager knows its a manager and
an agent knows its an agent.  As it says in the draft at the end of
section 2.1:

  We now distinguish between manager  and agent, and it is assumed that
each knows its role in the
  conversation.

I would still prefer to have agent and manager profile roles, but that
was not the working group's choice.
>
> Message and object conventions:
> BEEP messages vs XML objects:
> Much as I like to see the proper pleasantries being exchanged before the 
> manager and agent get down to business, I think that when para 1 of s2.1 
> says 'greetings are exchanged' I think it means '(BEEP) Greeting 
> messages are exchanged' (2 places).
>   
Yes.  I would be happy to change the text to this if there are no
objections.
> In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This 
> presumably means in the first Greeting message but it could also be 
> talking about the <greeting> element in that message - this is a bit 
> confusing unless you are very familiar with BEEP.  I think it would be 
> best to say 'in the first BEEP Greeting message' here, or alternatively 
> 'in the <greeting> element of the first BEEP Greeting message.
>   
This is in the context of the SASL and TLS profiles.  Profiles in BEEP
are only advertised in the <greeting> section.  The reader is assumed to
be familiar with RFCs 3080 and 3081.
> Version of SASL PLAIN to be used:
> This specification refers to RFC2595 but the SASL PLAIN mechanism is 
> currently under revision (see draft-ietf-sasl-plain-08.txt).  Should 
> this (new) specification be using the new PLAIN specification? The 
> latter part of para 5 of s2.1 seems a bit garbled and tautologous - 
> rework needed.
>   

Unless there is a specific security concern, I would rather not further
block this draft.
> Certificate management:
> I was wondering whether some of the material from s5.2 of RFC3259 
> regardsing serverName etc could be usefully repeated here?
>   

Could you please be more specific as to how?
> Channels:
> If I understand correctly, everything in s2.1 leads to the first BEEP 
> channel (channel 0) being established between a pair of elements.  I 
> think it would be good to mention channel 0 here because otherwise it 
> makes its first appearance in s2.4 when it is being closed.
>
> Extra channels:
>   
>>    Certain NETCONF capabilities may require additional BEEP channels.
>>    When such capabilities are defined, a BEEP mapping must be defined 
>> as well
>>
>>     
> The phraseology used here doesn't make it very clear if this is about 
> possible future extensions or something that already exists.  If some do 
> exist it would be good to give an example.  I am not sure how the second 
> sentence ties in with the original statement in the abstract i.e. that 
> this document *is* the BEEP mapping for NETCONF!  This probably ought to 
> go in a separate extensibility section.
>   
I would be happy to change the text to indicate that new capabilities
that make use of additional channels will require an update to this
mapping specification.
> s2.4, Locks:
> A pointer to the relevant section of ref [1] talking about locks would 
> be helpful
>   
The reader is presumed to be familiar with the core specification.
> s3, requirements:
> The material after the second sentence of the second paragraph is about 
> requirements and specification of how TLS and SASL are  to be used.  
> This doesn't belong here.  It should all be specified before we get to 
> this section.  
I would be happy to move this text forward to discussion of the two
profiles.
> It should probably make it clear that TLS is recommended 
> rather than mandatory.
>   
I believe that is already clear as my use of "ifs" in this document
exceeded my "if" quota ;-)
>
> Editorial nits:
> [Abstract: I take it from draft-netconf-prot that NETCONF is not an 
> acronym.]
>
> BEEP messages: It doesn't desperately matter but are the message 
> character counts right?  I wasn't sufficiently anally retentive to check 
> them.
>   
If there is one thing more you or others could check I wish it would be
this.  I believe I was careful to count characters in each example,.
> s1.1: s/transportlayer/transport layer/
>   

> s1.1: Expand CLI acronym.
>
>   
I believe this is a well understood acronym.
> s2.2, para 1: s/new channel/a new channel/
>
> s2.3: s/<rpc> tag/<rpc> element/ (?)
>   

Thank you again,

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 Wed Mar 01 16:32:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEYvc-0007G1-Qu
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 16:32:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEYvc-0006ZC-2K
	for netconf-archive@lists.ietf.org; Wed, 01 Mar 2006 16:32:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEYk7-0006vK-Tt
	for netconf-data@psg.com; Wed, 01 Mar 2006 21:20:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0
Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <elwynd@dial.pipex.com>)
	id 1FEVUN-000GOp-1C
	for netconf@ops.ietf.org; Wed, 01 Mar 2006 17:51:51 +0000
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1FEVUD-0000Y0-NJ; Wed, 01 Mar 2006 17:51:42 +0000
Message-ID: <4405DFBC.7040208@dial.pipex.com>
Date: Wed, 01 Mar 2006 17:54:04 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, 
 "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt
References: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com> <4405A2D4.6000401@cisco.com>
In-Reply-To: <4405A2D4.6000401@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070

Thanks for your responses.

Some further comments in line (especially in relation to PLAIN):

Regards,
Elwyn


Eliot Lear wrote:
> Elwyn,
>
> Thank you for your review.  Please find my responses below.
>   
>> There is a considerable lack of clarity in mapping the requirements and 
>> roles between the various protocols which are being combined in this 
>> protocol, and the manager/agent terminology used has been eschewed by 
>> NETCONF in favour of client/server.  If used at all manager/agent 
>> terminology should be confined to the 'reversability' motivation in the 
>> introduction.
>>   
>>     
>
> In the community we find ourselves, manager and agent are well
> understood terms.  Anyone who does not understand them is unlikely to
> implement the protocol.  If there is a bug, it is in the base
> specification in the use of the terms client and server, as they can be
> overloaded beyond recognition.
>   
Indeed: for those of us introduced to SNMP at a tender age, manager and 
agent come naturally, but this is a mapping to NETCONF and for better or 
for worse the NETCONF WG has decided on client and server so I think 
this spec has to be couched in those terms.
>   
>> The emphasis on reversability may be confusing: Checking with the 
>> NETCONF protocol, if I understand correctly, a given endpoint in a 
>> session is confined to being a client or a server.  Thus although a BEEP 
>> channel is reversible the NETCONF session that runs over it is not and 
>> indeed the transport protocol has to tell NETCONF which sort of endpoint 
>> (client or server) it is.
>>   
>>     
> Apparently it did not sufficiently confuse you.  You understood what we
> meant.
>   
BUT only after spending a couple of hours digging into BEEP, NETCONF and 
TLS, and asking a friend.   The point is that the reversibility applies 
to who can start the connection but once NETCONF gets going a given 
channel is not reversible: getting this from the specification was not 
so easy.
>> The security considerations section specifies requirements and 
>> operations rather than just discussing the threats and their mitigation.
>>   
>>     
>
> The security considerations section should be viewed in the context of
> the base protocol.  I will not reiterate everything said there.
>   
That is not what I am asking for.  The whole business of managing 
certificates and what profiles are advertised are parts of the 
functionality that have to be implemented.  Looking inside the security 
considerations for this is not something that I would hope to have to do.
>   
>> Review:
>>
>> Endpoint roles:
>> There are three pairs of terms in use in the draft for the roles of the 
>> two ends of the conversation:
>> 1. manager and agent (sort of implicitly how NETCONF would use the profile)
>> 2. listener and initiator (BEEP)
>> 3. client and server (TLS)
>> The mapping between the terms in 1 and 2 is apparently explained in s2.1 
>> but this explanation is not really a complete reflection of the 
>> situation explained in the BEEP RFC: ie the client/server terminology 
>> for the initial setup followed by the listener/initiator terminology for 
>> subsequent exchanges. In turn the mapping between 2 and 3 is not made 
>> explicit - I thought I could guess but after reflection I am not 
>> absolutely sure and it would be sensible to make it absolutely clear.
>>
>> However NETCONF does not talk about managers and agents but about 
>> clients and servers, and BEEP also talks about clients and servers after 
>> the channel is set up. So we really ought to be talking about four pairs 
>> of roles and how they interrelate:
>> 1. NETCONF client and server (this is what the profile has to support)
>> 2. BEEP listener and initiator (setting up a channel from either end)
>> 3. BEEP client and server (mapping to NETCONF and emphasising that it is 
>> not tied to listener/initiator roles)
>> 4. TLS client and server (not sure which way round this is supposed to map)
>>
>> I don't think the document overall expresses what needs to be said here 
>> and also doesn't give the semantics to express which way round the 
>> eventual NETCONF client/server connection is going to be setup.
>>   
>>     
>
> I have proposed a change to the mapping to address this point, but
> ultimately it has boiled down to this: a manager knows its a manager and
> an agent knows its an agent.  As it says in the draft at the end of
> section 2.1:
>
>   We now distinguish between manager  and agent, and it is assumed that
> each knows its role in the
>   conversation.
>
> I would still prefer to have agent and manager profile roles, but that
> was not the working group's choice.
>   
>> Message and object conventions:
>> BEEP messages vs XML objects:
>> Much as I like to see the proper pleasantries being exchanged before the 
>> manager and agent get down to business, I think that when para 1 of s2.1 
>> says 'greetings are exchanged' I think it means '(BEEP) Greeting 
>> messages are exchanged' (2 places).
>>   
>>     
> Yes.  I would be happy to change the text to this if there are no
> objections.
>   
>> In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This 
>> presumably means in the first Greeting message but it could also be 
>> talking about the <greeting> element in that message - this is a bit 
>> confusing unless you are very familiar with BEEP.  I think it would be 
>> best to say 'in the first BEEP Greeting message' here, or alternatively 
>> 'in the <greeting> element of the first BEEP Greeting message.
>>   
>>     
> This is in the context of the SASL and TLS profiles.  Profiles in BEEP
> are only advertised in the <greeting> section.  The reader is assumed to
> be familiar with RFCs 3080 and 3081.
>   
>> Version of SASL PLAIN to be used:
>> This specification refers to RFC2595 but the SASL PLAIN mechanism is 
>> currently under revision (see draft-ietf-sasl-plain-08.txt).  Should 
>> this (new) specification be using the new PLAIN specification? The 
>> latter part of para 5 of s2.1 seems a bit garbled and tautologous - 
>> rework needed.
>>   
>>     
>
> Unless there is a specific security concern, I would rather not further
> block this draft.
>   
I noticed that Russ Housley has raised a DISCUSS in relation to the use 
of simple identity certificates for clients.  Your comment prompted me 
to go and look at what the update of PLAIN was doing and as a result I read:
>    When the PLAIN mechanism is used, the server gains the ability to
>    impersonate the user to all services with the same password
>    regardless of any encryption provided by TLS or other network privacy
>    mechanisms.  While many other authentication mechanisms have similar
>    weaknesses, stronger SASL mechanisms such as Kerberos address this
>    issue.  Clients are encouraged to have an operational mode where all
>    mechanisms which are likely to reveal the user's password to the
>    server are disabled.
>   
It occurs to me that the combination of the reversibility of BEEP, PLAIN 
and simple identity certificates is possibly a serious security risk. I 
am not a security expert but I think I could envisage an attack as follows:
The attacker impersonates a server (agent) using a simple identity 
certificate and captures the password  supplied by the client. It then 
turns round and using the password and the same certificate impersonates 
a client (manager) to a different, real server (agent).
Consequently it is not only the client end that needs more specificity 
in its certificate but also the server end.
>
>
>   

>> Certificate management:
>> I was wondering whether some of the material from s5.2 of RFC3259 
>> regardsing serverName etc could be usefully repeated here?
>>   
>>     
>
> Could you please be more specific as to how?
>   
Sorry this was a typo: I meant RFC3529!
>> Channels:
>> If I understand correctly, everything in s2.1 leads to the first BEEP 
>> channel (channel 0) being established between a pair of elements.  I 
>> think it would be good to mention channel 0 here because otherwise it 
>> makes its first appearance in s2.4 when it is being closed.
>>
>> Extra channels:
>>   
>>     
>>>    Certain NETCONF capabilities may require additional BEEP channels.
>>>    When such capabilities are defined, a BEEP mapping must be defined 
>>> as well
>>>
>>>     
>>>       
>> The phraseology used here doesn't make it very clear if this is about 
>> possible future extensions or something that already exists.  If some do 
>> exist it would be good to give an example.  I am not sure how the second 
>> sentence ties in with the original statement in the abstract i.e. that 
>> this document *is* the BEEP mapping for NETCONF!  This probably ought to 
>> go in a separate extensibility section.
>>   
>>     
> I would be happy to change the text to indicate that new capabilities
> that make use of additional channels will require an update to this
> mapping specification.
>   
>> s2.4, Locks:
>> A pointer to the relevant section of ref [1] talking about locks would 
>> be helpful
>>   
>>     
> The reader is presumed to be familiar with the core specification.
>   
>> s3, requirements:
>> The material after the second sentence of the second paragraph is about 
>> requirements and specification of how TLS and SASL are  to be used.  
>> This doesn't belong here.  It should all be specified before we get to 
>> this section.  
>>     
> I would be happy to move this text forward to discussion of the two
> profiles.
>   
>> It should probably make it clear that TLS is recommended 
>> rather than mandatory.
>>   
>>     
> I believe that is already clear as my use of "ifs" in this document
> exceeded my "if" quota ;-)
>   
>> Editorial nits:
>> [Abstract: I take it from draft-netconf-prot that NETCONF is not an 
>> acronym.]
>>
>> BEEP messages: It doesn't desperately matter but are the message 
>> character counts right?  I wasn't sufficiently anally retentive to check 
>> them.
>>   
>>     
> If there is one thing more you or others could check I wish it would be
> this.  I believe I was careful to count characters in each example,.
>   
>> s1.1: s/transportlayer/transport layer/
>>   
>>     
>
>   
>> s1.1: Expand CLI acronym.
>>
>>   
>>     
> I believe this is a well understood acronym.
>   
>> s2.2, para 1: s/new channel/a new channel/
>>
>> s2.3: s/<rpc> tag/<rpc> element/ (?)
>>   
>>     
>
> Thank you again,
>
> 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 Thu Mar 02 04:28:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEk6t-00023I-4Y
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 04:28:35 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEk6r-0005R8-RM
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 04:28:35 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEjyi-000HKc-A6
	for netconf-data@psg.com; Thu, 02 Mar 2006 09:20:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FEjyh-000HKK-RZ
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 09:20:07 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-2.cisco.com with ESMTP; 02 Mar 2006 01:20:07 -0800
X-IronPort-AV: i="4.02,159,1139212800"; 
   d="scan'208"; a="311090650:sNHT32391928"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k229K6w1008264;
	Thu, 2 Mar 2006 01:20:06 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp222.cisco.com [10.61.64.222])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k229MH2I025898;
	Thu, 2 Mar 2006 01:22:18 -0800
Message-ID: <4406B8C2.7030806@cisco.com>
Date: Thu, 02 Mar 2006 10:20:02 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Brian Carpenter <brc@zurich.ibm.com>
CC: iesg@ietf.org, elwynd@dial.pipex.com, simon@switch.ch,
        netconf <netconf@ops.ietf.org>
Subject: Re: DISCUSS: draft-ietf-netconf-beep
References: <E1FEjsc-00078z-VN@ietf.org>
In-Reply-To: <E1FEjsc-00078z-VN@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1102; t=1141291339; x=1141723539;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20DISCUSS=3A=20draft-ietf-netconf-beep
	|To:Brian=20Carpenter=20<brc@zurich.ibm.com>;
	X=v=3Dmtcc.com=3B=20h=3DL3zplkql/UTTtCknrik+OVCkYwU=3D; b=eSc5XAJMRGQ2nqalildN7tJRSl1H31XJKqvbrtqxTqCSW+rsCXvkjG1hAB4z8q7uA6er4m4x
	CFutCUzLRXpUq69ldm5Lz4zttPWCCDT5s1XYmUvsIvLfwWe4R/ZwW3Q5FlP2y3PovgMevKXCnw8
	pueEevMZ3SwB9mL+ghNquenU=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Brian,

As Andy and I responded to Elwyn, this was discussed within the working
group.  The consensus was at the time that the client knows its a client
and the server knows its a server so this isn't really a problem.  I was
in the minority at the time.  My preference would be two separate BEEP
profiles, and this was in fact the case in an earlier version of the
document, as I recall.

Eliot
ps: whatever tool you're using to generate this email is generating
illegal destination addresses in the "To" field.


Brian Carpenter wrote:
> Discuss:
> (Based on Gen-ART review by Elwyn Davies)
>
> The base NETCONF protocol spec talks about 'client/server' instead of 'manager/agent'. This document uses 'manager/agent' but needs to be
> consistent with the base spec.
>
> The base NETCONF protocol spec requires (in section 2):
>
>   
>>    The transport protocol MUST provide a mechanism to indicate the
>>    session type (client or server) to the NETCONF protocol layer.
>>     
>
> So where does the BEEP mapping do this? If that isn't defined,
> it's a bug.
>
>   

--
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 Mar 02 05:47:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FElLN-0003Cp-RZ
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 05:47:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FElLM-0000Ef-En
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 05:47:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FElE7-000NZD-4A
	for netconf-data@psg.com; Thu, 02 Mar 2006 10:40:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FElE6-000NYn-CI
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 10:40:06 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 599B62D
	for <netconf@ops.ietf.org>; Thu,  2 Mar 2006 11:40:05 +0100 (CET)
Date: Thu, 02 Mar 2006 11:39:57 +0100 (CET)
Message-Id: <20060302.113957.97396921.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: unknown-namespace
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

Hi,

The description for the <error-tag> unknown-namespace says:

   Tag:         unknown-namespace
   Error-type:  rpc, protocol, application
   Severity:    error
   Error-info:  Name of the unexpected namespace
   Description: An unexpected namespace is present

The Error-info text seems to be wrong.  <error-info> can't just be the
name of the unexpected namespace.  For the other errors, the
Error-info text specifies which element within the <error-info> should
be present.

Was the intention to have a similar subelement of <error-info>,
e.g. <bad-namespace>?  Even so, maybe <bad-element> should be
populated with the name of the element where the unknown-namespace was
introduced.

Or was the intention that the error info would be (which the text
seems to indicate):

   <error-info>urn:my:bad:namespace</error-info>


/martin

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



From owner-netconf@ops.ietf.org Thu Mar 02 06:19:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FElqc-0007ho-Oc
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 06:19:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FElqb-0001PX-FT
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 06:19:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FElkF-0000Ng-8K
	for netconf-data@psg.com; Thu, 02 Mar 2006 11:13:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FElkE-0000NM-JD
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 11:13:18 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-3.cisco.com with ESMTP; 02 Mar 2006 03:12:59 -0800
X-IronPort-AV: i="4.02,159,1139212800"; 
   d="scan'208"; a="411687320:sNHT52122478086"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k22BCw7T004927;
	Thu, 2 Mar 2006 03:12:58 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp222.cisco.com [10.61.64.222])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k22BF84Y026275;
	Thu, 2 Mar 2006 03:15:09 -0800
Message-ID: <4406D336.8090004@cisco.com>
Date: Thu, 02 Mar 2006 12:12:54 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
CC: iesg@ietf.org, elwynd@dial.pipex.com, simon@switch.ch,
        netconf <netconf@ops.ietf.org>
Subject: Re: DISCUSS: draft-ietf-netconf-beep
References: <E1FEjsc-00078z-VN@ietf.org> <4406B8C2.7030806@cisco.com> <4406C645.6040302@zurich.ibm.com>
In-Reply-To: <4406C645.6040302@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=563; t=1141298111; x=1141730311;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20DISCUSS=3A=20draft-ietf-netconf-beep
	|To:Brian=20E=20Carpenter=20<brc@zurich.ibm.com>;
	X=v=3Dmtcc.com=3B=20h=3DDM4Urcf+QQzBM3UDQmPK2/zba78=3D; b=nxL2JURJVDLVyF+Yb/1kXnDGHCmQV55U1MlpxgJi9ss7z9S4OT9eIUcLJvS7Va8420O8vuXy
	0NiIs4VyUxcQT52g2PojTe2UtP0SksuDewNKsV9/Nz5KWxt9wMnFYTgDnAunEWgjHOWpu0+sHNM
	SYZnlTC6DZ1XxI+dMPztniU0=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

Brian E Carpenter wrote:
> Yes but, there remains an inconsistency with a solid
> requirement of the protocol spec. I don't see how you
> can expect the IESG to approve in the same meeting a draft
> that says you MUST do something and another draft that
> says you don't need to. Would you rather I put a DISCUSS
> on the protocol spec?
>
> (I assume the terminology issue will get fixed and isn't
> contentious.)

No, my personal preference is to go with two capabilities.  Barring
objections from WG I will send proposed text later today.

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 Thu Mar 02 08:15:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEneU-0001H2-3S
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 08:15:30 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEneT-0005ac-Ox
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 08:15:30 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEnUP-0009Nr-DK
	for netconf-data@psg.com; Thu, 02 Mar 2006 13:05:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <brc@zurich.ibm.com>)
	id 1FEksU-000LqU-40
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 10:17:46 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k22AHiVV135318
	for <netconf@ops.ietf.org>; Thu, 2 Mar 2006 10:17:44 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k22AI0xA245146
	for <netconf@ops.ietf.org>; Thu, 2 Mar 2006 11:18:00 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k22AHhRl019021
	for <netconf@ops.ietf.org>; Thu, 2 Mar 2006 11:17:43 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k22AHgXM019015;
	Thu, 2 Mar 2006 11:17:42 +0100
Received: from zurich.ibm.com (sig-9-145-249-16.de.ibm.com [9.145.249.16])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA60780;
	Thu, 2 Mar 2006 11:17:41 +0100
Message-ID: <4406C645.6040302@zurich.ibm.com>
Date: Thu, 02 Mar 2006 11:17:41 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: iesg@ietf.org, elwynd@dial.pipex.com, simon@switch.ch,
        netconf <netconf@ops.ietf.org>
Subject: Re: DISCUSS: draft-ietf-netconf-beep
References: <E1FEjsc-00078z-VN@ietf.org> <4406B8C2.7030806@cisco.com>
In-Reply-To: <4406B8C2.7030806@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

Yes but, there remains an inconsistency with a solid
requirement of the protocol spec. I don't see how you
can expect the IESG to approve in the same meeting a draft
that says you MUST do something and another draft that
says you don't need to. Would you rather I put a DISCUSS
on the protocol spec?

(I assume the terminology issue will get fixed and isn't
contentious.)

     Brian


Eliot Lear wrote:
> Brian,
> 
> As Andy and I responded to Elwyn, this was discussed within the working
> group.  The consensus was at the time that the client knows its a client
> and the server knows its a server so this isn't really a problem.  I was
> in the minority at the time.  My preference would be two separate BEEP
> profiles, and this was in fact the case in an earlier version of the
> document, as I recall.
> 
> Eliot
> ps: whatever tool you're using to generate this email is generating
> illegal destination addresses in the "To" field.
> 
> 
> Brian Carpenter wrote:
> 
>>Discuss:
>>(Based on Gen-ART review by Elwyn Davies)
>>
>>The base NETCONF protocol spec talks about 'client/server' instead of 'manager/agent'. This document uses 'manager/agent' but needs to be
>>consistent with the base spec.
>>
>>The base NETCONF protocol spec requires (in section 2):
>>
>>  
>>
>>>   The transport protocol MUST provide a mechanism to indicate the
>>>   session type (client or server) to the NETCONF protocol layer.
>>>    
>>
>>So where does the BEEP mapping do this? If that isn't defined,
>>it's a bug.
>>
>>  
> 
> 
> 




--
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 Mar 02 13:21:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEsQx-0002Ec-9V
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 13:21:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEsQw-0001LB-03
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 13:21:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEsIQ-0004yg-LH
	for netconf-data@psg.com; Thu, 02 Mar 2006 18:13:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FEsIN-0004yS-WF
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 18:13:00 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-1.cisco.com with ESMTP; 02 Mar 2006 10:12:59 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22ICww1019343;
	Thu, 2 Mar 2006 10:12:58 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp30.cisco.com [10.61.64.30])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k22IF7pH029460;
	Thu, 2 Mar 2006 10:15:08 -0800
Message-ID: <440735A6.9010007@cisco.com>
Date: Thu, 02 Mar 2006 19:12:54 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: Brian E Carpenter <brc@zurich.ibm.com>, iesg@ietf.org,
        elwynd@dial.pipex.com, simon@switch.ch, netconf <netconf@ops.ietf.org>
Subject: Re: DISCUSS: draft-ietf-netconf-beep
References: <E1FEjsc-00078z-VN@ietf.org> <4406B8C2.7030806@cisco.com> <4406C645.6040302@zurich.ibm.com> <4406D336.8090004@cisco.com>
In-Reply-To: <4406D336.8090004@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=866; t=1141323310; x=1141755510;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20DISCUSS=3A=20draft-ietf-netconf-beep
	|To:Eliot=20Lear=20<lear@cisco.com>;
	X=v=3Dmtcc.com=3B=20h=3D1lsdF3oPp85Ldr/CFxv7vspokUk=3D; b=o8r8nxWA8VYNhTORuMJX26c5qOjRWRH0DXU+izZNJ4W/LJevSqWbETBoFBptXaU9r+/QTz9M
	gbXuTC020gKVDPVWWGFTMN/LiU4zNyIk9fRSEbuktu4pXbmxmFnic2rlGUE864S7nsBITNnV8Y5
	HLG/vTf1RK87wJuFZpMAxB1U=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22

Eliot Lear wrote:

> No, my personal preference is to go with two capabilities.  Barring
> objections from WG I will send proposed text later today.
>   
I'm sorry.  I needed a boot to the head.  Here is a method that does not
require two capabilities.

New text after 2.1p2:

    After all BEEP greeting messages are exchanged in order for roles to
    be clear,  the agent MUST advertise the NETCONF profile.  The
    manager MUST NOT advertise the NETCONF profile.   If the agent side
    of the communication (either initiator or listener) receives a BEEP
    <greeting> element that contains the NETCONF profile, it MUST close
    the connection.  Similarly, if neither side issues a NETCONF profile
    it is equally an error, and the listener MUST close the connection.

Discussion

No new profiles are needed using this scheme.

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 Thu Mar 02 13:43:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEslf-0001iR-D5
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 13:43:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEslc-00026i-2o
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 13:43:15 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEsfD-0006xm-Vp
	for netconf-data@psg.com; Thu, 02 Mar 2006 18:36:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FEsfB-0006xD-A0
	for netconf@ops.ietf.org; Thu, 02 Mar 2006 18:36:33 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k22IaMSq021056;
	Thu, 2 Mar 2006 10:36:22 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <FZB9S0C8>; Thu, 2 Mar 2006 10:36:23 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7F47@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Eliot Lear'" <lear@cisco.com>
Cc: Brian E Carpenter <brc@zurich.ibm.com>, iesg@ietf.org,
        elwynd@dial.pipex.com, simon@switch.ch, netconf <netconf@ops.ietf.org>
Subject: RE: DISCUSS: draft-ietf-netconf-beep
Date: Thu, 2 Mar 2006 10:36:13 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

+1

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Eliot Lear
> Sent: Thursday, March 02, 2006 1:13 PM
> To: Eliot Lear
> Cc: Brian E Carpenter; iesg@ietf.org; elwynd@dial.pipex.com;
> simon@switch.ch; netconf
> Subject: Re: DISCUSS: draft-ietf-netconf-beep
> 
> 
> Eliot Lear wrote:
> 
> > No, my personal preference is to go with two capabilities.  Barring
> > objections from WG I will send proposed text later today.
> >   
> I'm sorry.  I needed a boot to the head.  Here is a method 
> that does not
> require two capabilities.
> 
> New text after 2.1p2:
> 
>     After all BEEP greeting messages are exchanged in order 
> for roles to
>     be clear,  the agent MUST advertise the NETCONF profile.  The
>     manager MUST NOT advertise the NETCONF profile.   If the 
> agent side
>     of the communication (either initiator or listener) 
> receives a BEEP
>     <greeting> element that contains the NETCONF profile, it 
> MUST close
>     the connection.  Similarly, if neither side issues a 
> NETCONF profile
>     it is equally an error, and the listener MUST close the 
> connection.
> 
> Discussion
> 
> No new profiles are needed using this scheme.
> 
> 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 Thu Mar 02 20:51:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEzRv-00076V-Nd
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 20:51:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FEzRv-0004eO-C5
	for netconf-archive@lists.ietf.org; Thu, 02 Mar 2006 20:51:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FEzGR-000Fv4-V1
	for netconf-data@psg.com; Fri, 03 Mar 2006 01:39:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FEzGR-000Fus-49
	for netconf@ops.ietf.org; Fri, 03 Mar 2006 01:39:27 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k231Unw3029331
	for <netconf@ops.ietf.org>; Thu, 2 Mar 2006 20:30:49 -0500
Received: (qmail 14673 invoked from network); 3 Mar 2006 01:30:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 3 Mar 2006 01:30:49 -0000
Message-ID: <44079C48.5060707@andybierman.com>
Date: Thu, 02 Mar 2006 17:30:48 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org, Rob Enns <rpe@juniper.net>
Subject: Re: unknown-namespace
References: <20060302.113957.97396921.mbj@tail-f.com>
In-Reply-To: <20060302.113957.97396921.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Martin Bjorklund wrote:
> Hi,
>
> The description for the <error-tag> unknown-namespace says:
>
>    Tag:         unknown-namespace
>    Error-type:  rpc, protocol, application
>    Severity:    error
>    Error-info:  Name of the unexpected namespace
>    Description: An unexpected namespace is present
>
> The Error-info text seems to be wrong.  <error-info> can't just be the
> name of the unexpected namespace.  For the other errors, the
> Error-info text specifies which element within the <error-info> should
> be present.
>
> Was the intention to have a similar subelement of <error-info>,
> e.g. <bad-namespace>?  Even so, maybe <bad-element> should be
> populated with the name of the element where the unknown-namespace was
> introduced.
>
> Or was the intention that the error info would be (which the text
> seems to indicate):
>
>    <error-info>urn:my:bad:namespace</error-info>
>
>   

You are right (again).
I discussed this with Rob.
It was always the intent that <error-info> be a container.
If we define standard error-info content that is a simpleType
instead of complexType, then the agent cannot send other
error-info sub-elements without using mixed content.
We definitely want to avoid that.

We are going to change the definition of the 'unknown-namespace'
error in Appendix A to define a 'bad-namespace' sub-element,
instead of the simple string content that the description clause
now suggests.

This will make is possible to identify the element with the unknown 
namespace
as you suggest:

<error-info>
  <bad-namespace>foo</bad-namespace>
  <bad-element>bar</bad-element>
</error-info>

This matches the bad-namespace/bad-attribute approach the
rest of NETCONF uses.

> /martin
>   

Andy


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



From owner-netconf@ops.ietf.org Fri Mar 03 03:44:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FF5tP-0005EX-Ir
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 03:44:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FF5tN-0002fk-12
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 03:44:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FF5iO-000O3O-QY
	for netconf-data@psg.com; Fri, 03 Mar 2006 08:32:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FF5iM-000O3A-Ir
	for netconf@ops.ietf.org; Fri, 03 Mar 2006 08:32:43 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by test-iport-1.cisco.com with ESMTP; 03 Mar 2006 00:32:42 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k238WfGv015086;
	Fri, 3 Mar 2006 00:32:41 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4354.cisco.com [10.61.81.1])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k238Ymhq002581;
	Fri, 3 Mar 2006 00:34:49 -0800
Message-ID: <4407FF26.5090601@cisco.com>
Date: Fri, 03 Mar 2006 09:32:38 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Elwyn Davies <elwynd@dial.pipex.com>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt
References: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com> <4405A2D4.6000401@cisco.com> <4405DFBC.7040208@dial.pipex.com>
In-Reply-To: <4405DFBC.7040208@dial.pipex.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=8566; t=1141374891; x=1141807091;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20FW=3A=20Gen-art=20review=20of=20draft-ietf-netconf-beep-08.txt
	|To:Elwyn=20Davies=20<elwynd@dial.pipex.com>;
	X=v=3Dmtcc.com=3B=20h=3DZ0UOHFUOXmN9yMQOoC1k6wqRkQc=3D; b=eOG3o+cRMrm9KgiilcaDaJiEPdoriuVxtEBAX3hYuh8bGrrkGzNDiQqMkmiLdY/wHq+CkRD4
	lxsGUV3WYaeLCNeNWJtbrvRjZ0UkmT2xdEgbtpYjXW2zPWEzuKdTRjJ7WcCohKlwvrq3U8ruRZj
	rB7nQviiDnlYC3Vi4BjxLwIo=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c

Elwyn,

More discussion below.
 
> Indeed: for those of us introduced to SNMP at a tender age, manager
> and agent come naturally, but this is a mapping to NETCONF and for
> better or for worse the NETCONF WG has decided on client and server so
> I think this spec has to be couched in those terms.
If this were a small amount of work, I wouldn't argue the point.  It's a
large amount of work to rework the draft for all of that, and BEEP
specifically avoids the use of client/server terms.  This having been
said, let me propose the following wording be added as follows:

NEW S2P2:

    For purposes of this document a manager is a NETCONF client, and an
    agent is a NETCONF server.  Use of client/server language in BEEP is
    avoided because of the common notion that in networking clients
    connect to servers.


>>  
>>> The emphasis on reversability may be confusing: Checking with the
>>> NETCONF protocol, if I understand correctly, a given endpoint in a
>>> session is confined to being a client or a server.  Thus although a
>>> BEEP channel is reversible the NETCONF session that runs over it is
>>> not and indeed the transport protocol has to tell NETCONF which sort
>>> of endpoint (client or server) it is.
>>>       
>> Apparently it did not sufficiently confuse you.  You understood what we
>> meant.
>>   
> BUT only after spending a couple of hours digging into BEEP, NETCONF
> and TLS, and asking a friend.   The point is that the reversibility
> applies to who can start the connection but once NETCONF gets going a
> given channel is not reversible: getting this from the specification
> was not so easy.
With the added text I sent previously I believe this problem is now
resolved.
>>> The security considerations section specifies requirements and
>>> operations rather than just discussing the threats and their
>>> mitigation.
>>>       
>>
>> The security considerations section should be viewed in the context of
>> the base protocol.  I will not reiterate everything said there.
>>   
> That is not what I am asking for.  The whole business of managing
> certificates and what profiles are advertised are parts of the
> functionality that have to be implemented.  Looking inside the
> security considerations for this is not something that I would hope to
> have to do.
I believe I addressed this concern below.
>>  
>>> Message and object conventions:
>>> BEEP messages vs XML objects:
>>> Much as I like to see the proper pleasantries being exchanged before
>>> the manager and agent get down to business, I think that when para 1
>>> of s2.1 says 'greetings are exchanged' I think it means '(BEEP)
>>> Greeting messages are exchanged' (2 places).
>>>       
>> Yes.  I would be happy to change the text to this if there are no
>> objections.

To be clear:

Section 2.1p1:

OLD:
  greetings are exchanged, they SHOULD each announce their support for

NEW:
  BEEP greeting messages are exchanged, they SHOULD each announce their
support for

And Section 2.1p2:

OLD:
  Once TLS has been started, a new greeting is sent by both initiator

NEW:
  Once TLS has been started, a new BEEP greeting message is sent by both
initiator


>>  
>>> In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This
>>> presumably means in the first Greeting message but it could also be
>>> talking about the <greeting> element in that message - this is a bit
>>> confusing unless you are very familiar with BEEP.  I think it would
>>> be best to say 'in the first BEEP Greeting message' here, or
>>> alternatively 'in the <greeting> element of the first BEEP Greeting
>>> message.
>>>       
>> This is in the context of the SASL and TLS profiles.  Profiles in BEEP
>> are only advertised in the <greeting> section.  The reader is assumed to
>> be familiar with RFCs 3080 and 3081.
>>  
>>> Version of SASL PLAIN to be used:
>>> This specification refers to RFC2595 but the SASL PLAIN mechanism is
>>> currently under revision (see draft-ietf-sasl-plain-08.txt).  Should
>>> this (new) specification be using the new PLAIN specification? The
>>> latter part of para 5 of s2.1 seems a bit garbled and tautologous -
>>> rework needed.
>>>       
>>
>> Unless there is a specific security concern, I would rather not further
>> block this draft.
>>   
> I noticed that Russ Housley has raised a DISCUSS in relation to the
> use of simple identity certificates for clients.  Your comment
> prompted me to go and look at what the update of PLAIN was doing and
> as a result I read:
>>    When the PLAIN mechanism is used, the server gains the ability to
>>    impersonate the user to all services with the same password
>>    regardless of any encryption provided by TLS or other network privacy
>>    mechanisms.  While many other authentication mechanisms have similar
>>    weaknesses, stronger SASL mechanisms such as Kerberos address this
>>    issue.  Clients are encouraged to have an operational mode where all
>>    mechanisms which are likely to reveal the user's password to the
>>    server are disabled.
>>   
> It occurs to me that the combination of the reversibility of BEEP,
> PLAIN and simple identity certificates is possibly a serious security
> risk. I am not a security expert but I think I could envisage an
> attack as follows:
> The attacker impersonates a server (agent) using a simple identity
> certificate and captures the password  supplied by the client. It then
> turns round and using the password and the same certificate
> impersonates a client (manager) to a different, real server (agent).
> Consequently it is not only the client end that needs more specificity
> in its certificate but also the server end.

Server-side certs are not subject to which role is played.  The draft
makes this clear.

>>
>>
>>   
>
>>> Certificate management:
>>> I was wondering whether some of the material from s5.2 of RFC3259
>>> regardsing serverName etc could be usefully repeated here?
>>>       
>>
>> Could you please be more specific as to how?
>>   
> Sorry this was a typo: I meant RFC3529!
If I understand the discussion in RFC-3529 they are virtualizing the
service.  While I have no objection in principle, I'd suggest that is a
bit of an extension and not something that need be dealt with in the
first version of the standard.  Again, I would agree that it is a good
subject for future work.

>>> Channels:
>>> If I understand correctly, everything in s2.1 leads to the first
>>> BEEP channel (channel 0) being established between a pair of
>>> elements.  I think it would be good to mention channel 0 here
>>> because otherwise it makes its first appearance in s2.4 when it is
>>> being closed.
>>>
>>> Extra channels:
>>>      
>>>>    Certain NETCONF capabilities may require additional BEEP channels.
>>>>    When such capabilities are defined, a BEEP mapping must be
>>>> defined as well
>>>>
>>>>           
>>> The phraseology used here doesn't make it very clear if this is
>>> about possible future extensions or something that already exists. 
>>> If some do exist it would be good to give an example.  I am not sure
>>> how the second sentence ties in with the original statement in the
>>> abstract i.e. that this document *is* the BEEP mapping for NETCONF! 
>>> This probably ought to go in a separate extensibility section.
>>>       
>> I would be happy to change the text to indicate that new capabilities
>> that make use of additional channels will require an update to this
>> mapping specification.
Section 2.2 second to last paragraph:

OLD:

  Certain NETCONF capabilities may require additional BEEP channels.

NEW:

  Future NETCONF capabilities may require additional BEEP channels.

>>  
>>> s2.4, Locks:
>>> A pointer to the relevant section of ref [1] talking about locks
>>> would be helpful
>>>       
>> The reader is presumed to be familiar with the core specification.
>>  
>>> s3, requirements:
>>> The material after the second sentence of the second paragraph is
>>> about requirements and specification of how TLS and SASL are  to be
>>> used.  This doesn't belong here.  It should all be specified before
>>> we get to this section.      
>> I would be happy to move this text forward to discussion of the two
>> profiles.

I see that there already exists a forward reference already in the text
in S2.1p5.  I hope this would suffice.

Thank you again,

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 Mar 03 11:05:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FFCmJ-0008E8-6J
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 11:05:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FFCmI-0002PN-PB
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 11:05:15 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FFCf7-000CCX-7e
	for netconf-data@psg.com; Fri, 03 Mar 2006 15:57:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [64.40.101.249] (helo=www.icesoft.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ted.goddard@icesoft.com>)
	id 1FFCf6-000CCL-FB
	for netconf@ops.ietf.org; Fri, 03 Mar 2006 15:57:48 +0000
Received: from [10.18.39.60] ([64.141.118.170])
	by www.icesoft.com (Kerio MailServer 6.1.2)
	(using TLSv1/SSLv3 with cipher RC4-SHA (128 bits));
	Fri, 3 Mar 2006 08:08:04 -0800
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <4407FF26.5090601@cisco.com>
References: <7D5D48D2CAA3D84C813F5B154F43B15509721941@nl0006exch001u.nl.lucent.com> <4405A2D4.6000401@cisco.com> <4405DFBC.7040208@dial.pipex.com> <4407FF26.5090601@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7DE8F101-55EA-4B5A-81E8-A758A78BC665@icesoft.com>
Content-Transfer-Encoding: 7bit
From: Ted Goddard <ted.goddard@icesoft.com>
Subject: draft-ietf-netconf-soap-08
Date: Fri, 3 Mar 2006 08:57:44 -0700
To: "Netconf (E-mail)" <netconf@ops.ietf.org>,
 Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.746.2)
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


I intend to prepare the update draft-ietf-netconf-soap-08.txt as
follows;  are there any additional comments?

4.1  Integrity, Privacy, and Authentication

    The NETCONF SOAP binding relies on an underlying secure transport  
for
    integrity and privacy.  Such transports are expected to include TLS
    [9] (which, when combined with HTTP, is referred to as HTTPS) and
    IPsec.  There are a number of options for authentication (some of
    which are deployment-specific):

    o  within the transport (such as with TLS client certificates)

    o  within HTTP (such as Digest Access Authentication [7])

    o  within SOAP (such as a digital signature in the header [17])

    HTTP, BEEP, and SOAP level authentication can be integrated with
    RADIUS [10] (Remote Authentication Dial In User Service) to support
    remote authentication databases.

    At a miniumum, all conforming NETCONF over SOAP implementations MUST
    support TLS.  Specifically, NETCONF over SOAP over HTTP MUST support
    NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST
    support NETCONF over SOAP over BEEP over TLS.

...

    [7]   Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
          Luotonen, A., Sink, E., and L. Stewart, "HTTP Authentication:
          Basic and Digest Access Authentication", RFC 2617, June 1999,
          <http://www.ietf.org/rfc/rfc2617.txt>.


Thanks,
Ted.



--
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 Mar 03 17:05:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FFHlb-0000wJ-QR
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 16:24:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FFHL5-00068i-A4
	for netconf-archive@lists.ietf.org; Fri, 03 Mar 2006 15:57:27 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FFHE5-000CMl-Mf
	for netconf-data@psg.com; Fri, 03 Mar 2006 20:50:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [209.173.53.84] (helo=willow.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FFHE3-000CLI-Jm
	for netconf@ops.ietf.org; Fri, 03 Mar 2006 20:50:11 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k23Ko29W021537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FFHDu-0005Jt-Cc; Fri, 03 Mar 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-beep-09.txt 
Message-Id: <E1FFHDu-0005Jt-Cc@stiedprstage1.ietf.org>
Date: Fri, 03 Mar 2006 15:50:02 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

--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-09.txt
	Pages		: 14
	Date		: 2006-3-3
	
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-09.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-09.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-09.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:	<2006-3-3143639.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2006-3-3143639.I-D@ietf.org>

--OtherAccess--

--NextPart--

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



From owner-netconf@ops.ietf.org Mon Mar 06 02:57:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGAaV-0006fe-NT
	for netconf-archive@lists.ietf.org; Mon, 06 Mar 2006 02:57:03 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FGAaM-0004AG-AW
	for netconf-archive@lists.ietf.org; Mon, 06 Mar 2006 02:56:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FGATv-000EoQ-78
	for netconf-data@psg.com; Mon, 06 Mar 2006 07:50:15 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no 
	version=3.1.0
Received: from [209.173.53.70] (helo=oak.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FGATt-000EoA-Tv
	for netconf@ops.ietf.org; Mon, 06 Mar 2006 07:50:14 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k267o1BX007525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Mar 2006 07:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FGATh-0008KM-Dw; Mon, 06 Mar 2006 02:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-soap-08.txt 
Message-Id: <E1FGATh-0008KM-Dw@stiedprstage1.ietf.org>
Date: Mon, 06 Mar 2006 02:50:01 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title		: Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)
	Author(s)	: T. Goddard
	Filename	: draft-ietf-netconf-soap-08.txt
	Pages		: 22
	Date		: 2006-3-5
	
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 (Hypertext
   Transport Protocol) and SOAP over BEEP (Blocks Exchange Extensible
   Protocol) bindings for NETCONF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-netconf-soap-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-soap-08.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:	<2006-3-5184150.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2006-3-5184150.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From owner-netconf@ops.ietf.org Mon Mar 06 15:56:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGMkh-0003o7-LK
	for netconf-archive@lists.ietf.org; Mon, 06 Mar 2006 15:56:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FGMkg-0003j3-QL
	for netconf-archive@lists.ietf.org; Mon, 06 Mar 2006 15:56:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FGMed-000Eio-Ir
	for netconf-data@psg.com; Mon, 06 Mar 2006 20:50:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no 
	version=3.1.0
Received: from [209.173.57.70] (helo=pine.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FGMec-000Ehs-SC
	for netconf@ops.ietf.org; Mon, 06 Mar 2006 20:50:07 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko2vP010460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 6 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FGMeY-000575-7t; Mon, 06 Mar 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-prot-12.txt 
Message-Id: <E1FGMeY-000575-7t@stiedprstage1.ietf.org>
Date: Mon, 06 Mar 2006 15:50:02 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a

--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-12.txt
	Pages		: 105
	Date		: 2006-3-6
	
The NETCONF configuration protocol defined in this document provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices.  It uses an Extensible Markup Language (XML) based
   data encoding for the configuration data as well as the protocol
   messages.  The NETCONF protocol operations are realized on top of a
   simple Remote Procedure Call (RPC) layer.

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

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

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

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

Content-Type: text/plain
Content-ID:	<2006-3-6112957.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 Mar 09 07:17:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHK5J-0005Wd-Oc
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 07:17:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHK5H-00088m-AU
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 07:17:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHJy7-0005gK-BZ
	for netconf-data@psg.com; Thu, 09 Mar 2006 12:10:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FHJy6-0005fU-Fh
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 12:10:10 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k29C5qt19102
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 07:05:52 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Second Example in section 7.2 of netconf-proto
Date: Thu, 9 Mar 2006 07:10:02 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Second Example in section 7.2 of netconf-proto
Thread-Index: AcZDcmT6tIO04VxDTZ21KzqiLysWEA==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

hi

In section 7.2, the second example indicates it will add an interface,
but uses the operator of replace. The definition of replace does not
actually say that if the entry does not exist, it is created. Should it,
or should the operator of create be used instead in this example?

I also wonder with these examples if there is an implicit assumption
that the key is name and this somehow defines whether something exists
or not?

      Add an interface named "Ethernet0/0" to the running configuration,
      replacing any previous interface with that name:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config xmlns:xc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns=3D"http://example.com/schema/1.2/config">
             <interface xc:operation=3D"replace">
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
               <address>
                 <name>192.0.2.4</name>
                 <prefix-length>24</prefix-length>
               </address>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>


Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

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



From owner-netconf@ops.ietf.org Thu Mar 09 08:03:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHKnV-0006kX-26
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 08:03:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHKnS-0000pO-I4
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 08:03:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHKjc-0009Lt-D3
	for netconf-data@psg.com; Thu, 09 Mar 2006 12:59:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FHKjb-0009LU-MK
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 12:59:15 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 103692D;
	Thu,  9 Mar 2006 13:59:14 +0100 (CET)
Date: Thu, 09 Mar 2006 13:59:06 +0100 (CET)
Message-Id: <20060309.135906.106612823.mbj@tail-f.com>
To: schishol@nortel.com
Cc: netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

"Sharon Chisholm" <schishol@nortel.com> wrote:
> hi
> 
> In section 7.2, the second example indicates it will add an interface,
> but uses the operator of replace. The definition of replace does not
> actually say that if the entry does not exist, it is created.

If it doesn't exist and you try to 'replace', it's an error. This is
not clearly defined in 7.2, but in the description of the error
'data-missing' it says:

   Tag:         data-missing
   Error-type:  application
   Severity:    error
   Error-info:  none
   Description: Request could not be completed because the relevant
                data model content does not exist.  For example,
                a 'replace' or 'delete' operation was attempted on
                data which does not exist.


'create' creates an non-existing; it's an error if it exists.
'replace' replaces an existing; it's an error if it doesn't exist.
'merge' creates if it doesn't exist, and modifies if it exists.
'delete' deletes an existing; it's an error if it doesn't exist.

So the example text is a bit unclear.



/martin

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



From owner-netconf@ops.ietf.org Thu Mar 09 09:43:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHMMk-00074r-Vm
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 09:43:46 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHMMh-0004ET-Js
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 09:43:46 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHMHy-000G3Y-Ti
	for netconf-data@psg.com; Thu, 09 Mar 2006 14:38:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHMHx-000G3K-Pk
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 14:38:50 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k29EcmBf011917
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 09:38:48 -0500
Received: (qmail 31654 invoked from network); 9 Mar 2006 14:38:47 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 9 Mar 2006 14:38:47 -0000
Message-ID: <44103E35.8080403@andybierman.com>
Date: Thu, 09 Mar 2006 06:39:49 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com> <20060309.135906.106612823.mbj@tail-f.com>
In-Reply-To: <20060309.135906.106612823.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Martin Bjorklund wrote:
> "Sharon Chisholm" <schishol@nortel.com> wrote:
>   
>> hi
>>
>> In section 7.2, the second example indicates it will add an interface,
>> but uses the operator of replace. The definition of replace does not
>> actually say that if the entry does not exist, it is created.
>>     
>
> If it doesn't exist and you try to 'replace', it's an error. This is
> not clearly defined in 7.2, but in the description of the error
> 'data-missing' it says:
>
>    Tag:         data-missing
>    Error-type:  application
>    Severity:    error
>    Error-info:  none
>    Description: Request could not be completed because the relevant
>                 data model content does not exist.  For example,
>                 a 'replace' or 'delete' operation was attempted on
>                 data which does not exist.
>
>
> 'create' creates an non-existing; it's an error if it exists.
> 'replace' replaces an existing; it's an error if it doesn't exist.
> 'merge' creates if it doesn't exist, and modifies if it exists.
> 'delete' deletes an existing; it's an error if it doesn't exist.
>
> So the example text is a bit unclear.
>   

This error text is wrong.
Replace does not cause an error if the data does not exist.
That was the reason we added create. 

Merge and replace do not care about existing data.

Create on data that already exists is an error.

Delete on data that does not exist is an error.

Replace foo with nothing is not an error.

Merge foo with nothing is not an error.

Replace nothing with foo is not an error.

Merge nothing with foo is not an error.


>
>
> /martin
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 09 09:59:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHMcA-0003ZG-3B
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 09:59:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHMc8-0004kx-Of
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 09:59:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHMS0-000Gx4-V7
	for netconf-data@psg.com; Thu, 09 Mar 2006 14:49:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHMS0-000Gwp-80
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 14:49:12 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k29EnB27026773
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 09:49:11 -0500
Received: (qmail 6285 invoked from network); 9 Mar 2006 14:49:10 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 9 Mar 2006 14:49:10 -0000
Message-ID: <441040A4.6010006@andybierman.com>
Date: Thu, 09 Mar 2006 06:50:12 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Sharon Chisholm wrote:
> hi
>
> In section 7.2, the second example indicates it will add an interface,
> but uses the operator of replace. The definition of replace does not
> actually say that if the entry does not exist, it is created. Should it,
> or should the operator of create be used instead in this example?
>
> I also wonder with these examples if there is an implicit assumption
> that the key is name and this somehow defines whether something exists
> or not?
>
>   

How about some text that says:

"The manager must understand the data model being used.
In these examples, the manager knows a priori that the 'name' element
is used for instance identification to distinguish multiple instances
of the 'interface' element.


>       Add an interface named "Ethernet0/0" to the running configuration,
>       replacing any previous interface with that name:
>
>      <rpc message-id="101"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <edit-config>
>          <target>
>            <running/>
>          </target>
>          <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
>            <top xmlns="http://example.com/schema/1.2/config">
>              <interface xc:operation="replace">
>                <name>Ethernet0/0</name>
>                <mtu>1500</mtu>
>                <address>
>                  <name>192.0.2.4</name>
>                  <prefix-length>24</prefix-length>
>                </address>
>              </interface>
>            </top>
>          </config>
>        </edit-config>
>      </rpc>
>
>      <rpc-reply message-id="101"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <ok/>
>      </rpc-reply>
>
>
> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
>
>   

Andy

> -


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



From owner-netconf@ops.ietf.org Thu Mar 09 10:01:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHMeH-0004SZ-2p
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:01:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHMeE-0004p0-LO
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:01:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHMZO-000HY8-NS
	for netconf-data@psg.com; Thu, 09 Mar 2006 14:56:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FHMZL-000HX3-SV
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 14:56:48 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id E7AF859;
	Thu,  9 Mar 2006 15:56:46 +0100 (CET)
Date: Thu, 09 Mar 2006 15:56:38 +0100 (CET)
Message-Id: <20060309.155638.118969008.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44103E35.8080403@andybierman.com>
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
	<20060309.135906.106612823.mbj@tail-f.com>
	<44103E35.8080403@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

Andy Bierman <ietf@andybierman.com> wrote:
> This error text is wrong.
> Replace does not cause an error if the data does not exist.

That was quite some change to the current draft!


/martin

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



From owner-netconf@ops.ietf.org Thu Mar 09 10:29:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHN4w-000826-KA
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:29:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHN4v-0005bG-6Q
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:29:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHN04-000JfF-FX
	for netconf-data@psg.com; Thu, 09 Mar 2006 15:24:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FHN03-000Jf1-Ln
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 15:24:23 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k29FOKF29222
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 10:24:21 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Second Example in section 7.2 of netconf-proto
Date: Thu, 9 Mar 2006 10:24:19 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40748C8E8@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Second Example in section 7.2 of netconf-proto
Thread-Index: AcZDibPNCWn4HunfRoS94tgxA2ZzzAAA35qg
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

hi

Well, as a minimum, it appears to be an ambiguity in the specification
that different implementations have interpreted differently. After we
agree which we agree(d) with, can I suggest we update the description of
replace to be explicit?

Thanks,

Sharon

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
Sent: Thursday, March 09, 2006 9:57 AM
To: ietf@andybierman.com
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto


Andy Bierman <ietf@andybierman.com> wrote:
> This error text is wrong.
> Replace does not cause an error if the data does not exist.

That was quite some change to the current draft!


/martin


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



From owner-netconf@ops.ietf.org Thu Mar 09 10:36:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHNBi-0002xA-4r
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:36:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHNBg-0005lX-Qz
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:36:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHN7e-000KOI-Nz
	for netconf-data@psg.com; Thu, 09 Mar 2006 15:32:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHN7d-000KO4-Vt
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 15:32:14 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k29FWBw3012473
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 10:32:12 -0500
Received: (qmail 13999 invoked from network); 9 Mar 2006 15:32:10 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 9 Mar 2006 15:32:10 -0000
Message-ID: <44104AB9.20006@andybierman.com>
Date: Thu, 09 Mar 2006 07:33:13 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: error-path for multiple instances
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

Hi,

How should error-info be enhanced to support multiple similar errors?

Consider an edit-config that is changing the 'mtu' object
to an illegal value in 2 or more interfaces:


...
 <config>
   <interfaces xmlns="http://example.com/schema/1.0">
     <interface>
       <name>eth0</name>
       <mtu>64000</mtu>
     </interface>
     <interface>
       <name>eth1</name>
       <mtu>64000</mtu>
     </interface>
   </interfaces>
 </config>



So first I added an <error-level> error element,
because it is a lot easier and more compact than error-path.

Then I added a <bad-value> element, so you can tell that
the row with value '64000' had the error.  Well of course,
that doesn't solve the problem either.

Then I added a <instance-id> element, which does solve the problem:

  <error-info xmlns:ex="example.com-blah" xmlns:ncx="ncx-blah">
    <bad-element>mtu</bad=element>
    <ncx:error-level>5</ncx:error-level>
    <ncx:bad-value>64000</ncx:bad-value>
    <ncx:instance-id>
          <ex:name>eth0</ex:name>
    </ncx:instance-id>
  </error-info>

I guess if you could use Xpath too (and that's what the WG should do):

<error-path xmlns:nc="netconf-blah" xmlns:ex="example.com-blah">
   
/nc:rpc/nc:edit-config/nc:config/ex:interfaces/ex:interface[ex:name="eth0"]/ex:mtu
</error-path>

IMO, it is a subjective decision which is better: Xpath or XML.


Andy




  

         

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



From owner-netconf@ops.ietf.org Thu Mar 09 10:50:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHNP8-0004Hs-9v
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:50:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHNP7-00066B-0k
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 10:50:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHNFC-000L1M-11
	for netconf-data@psg.com; Thu, 09 Mar 2006 15:40:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHNFB-000L11-8r
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 15:40:01 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k29FXpLx025529
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 10:33:51 -0500
Received: (qmail 928 invoked from network); 9 Mar 2006 15:33:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr4.mgt.bos.netsol.com with SMTP; 9 Mar 2006 15:33:50 -0000
Message-ID: <44104B1C.3070409@andybierman.com>
Date: Thu, 09 Mar 2006 07:34:52 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>	<20060309.135906.106612823.mbj@tail-f.com>	<44103E35.8080403@andybierman.com> <20060309.155638.118969008.mbj@tail-f.com>
In-Reply-To: <20060309.155638.118969008.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>   
>> This error text is wrong.
>> Replace does not cause an error if the data does not exist.
>>     
>
> That was quite some change to the current draft!
>
>   

I could dig up lots of email messages from a couple years ago that
shows that this is not a change -- it is how replace has always worked.
The (unfortunate) extra 2 words in the error description is the bug.


> /martin
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 09 11:33:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHO4r-0006VM-UA
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 11:33:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHO4q-0007hg-5p
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 11:33:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHNxl-000OL0-7h
	for netconf-data@psg.com; Thu, 09 Mar 2006 16:26:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_WHOIS_BOGONS,UNPARSEABLE_RELAY autolearn=no version=3.1.0
Received: from [139.76.165.215] (helo=aismt08p.bellsouth.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FHNxk-000OKk-6B
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 16:26:04 +0000
Received: from ([90.152.53.183])
	by aismt08p.bellsouth.com with SMTP  id KP-AXPNC.118211642;
	Thu, 09 Mar 2006 11:25:29 -0500
Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 9 Mar 2006 10:25:31 -0600
Received: from mail pickup service by 01AL10015010161.ad.bls.com with Microsoft SMTPSVC;
	 Thu, 9 Mar 2006 10:24:26 -0600
Received: from 01AL10015010117.ad.bls.com ([90.152.52.44]) by 01AL10015010161.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 9 Mar 2006 09:28:58 -0600
Received: from 01al10015010106.ad.bls.com ([90.152.5.114]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 9 Mar 2006 09:28:58 -0600
Received: from aismt13g.bellsouth.com ([139.76.165.223])
 by 01al10015010106.ad.bls.com (SMSSMTP 4.1.9.35) with SMTP id M2006030909285802678
 for <barbara.stark@bellsouth.com>; Thu, 09 Mar 2006 09:28:58 -0600
Received: from ([147.28.0.62])
	by aismt13g.bellsouth.com with ESMTP with TLS id KP-BRBPN.42041623;
	Thu, 09 Mar 2006 10:17:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHMZO-000HY8-NS
	for netconf-data@psg.com; Thu, 09 Mar 2006 14:56:50 +0000
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FHMZL-000HX3-SV
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 14:56:48 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id E7AF859;
	Thu,  9 Mar 2006 15:56:46 +0100 (CET)
Date: Thu, 09 Mar 2006 15:56:38 +0100 (CET)
Message-Id: <20060309.155638.118969008.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44103E35.8080403@andybierman.com>
References: <713043CE8B8E1348AF3C546DBE02C1B40742D6FC@zcarhxm2.corp.nortel.com>
	<20060309.135906.106612823.mbj@tail-f.com>
	<44103E35.8080403@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-esp: ESP<42>=RBL:<0> RDNS:<0> SHA:<26> UHA:<0> SLS:<0> BAYES:<0> URL
	Substring Dictionary (TRU8):<0> Spam Dictionary (TRU8):<0>
	NigeriaScam Dictionary (TRU8):<0> BellSouth Spam SS:<0> HTML
	Dictionary (TRU8):<16> Porn Dictionary (TRU8):<0> Embed HTML
	Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL
	Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> 
X-OriginalArrivalTime: 09 Mar 2006 15:28:58.0355 (UTC) FILETIME=[2F3C8430:01C6438E]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Andy Bierman <ietf@andybierman.com> wrote:
> This error text is wrong.
> Replace does not cause an error if the data does not exist.

That was quite some change to the current draft!


/martin

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <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 Thu Mar 09 12:10:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHOf8-0002rX-NV
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:10:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHOf8-0000MO-7S
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:10:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHOaW-0001hx-Fk
	for netconf-data@psg.com; Thu, 09 Mar 2006 17:06:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FHOaV-0001hj-FX
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 17:06:07 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k29H5oZf003599;
	Thu, 9 Mar 2006 09:05:54 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <GH8GRK1A>; Thu, 9 Mar 2006 09:05:50 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7F6D@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
        Martin Bjorklund
	 <mbj@tail-f.com>
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: RE: Second Example in section 7.2 of netconf-proto
Date: Thu, 9 Mar 2006 09:05:48 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

Hi Andy,

Email messages from two years ago aside, this is a pernicious
and foolish definition of 'replace' that collides with the
common semantics of 'replace' in all good quality software.

Silently 'replacing' something that isn't there is just plain
wrong.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Thursday, March 09, 2006 9:40 AM
> To: Martin Bjorklund
> Cc: schishol@nortel.com; netconf@ops.ietf.org
> Subject: Re: Second Example in section 7.2 of netconf-proto
> 
> 
> Martin Bjorklund wrote:
> > "Sharon Chisholm" <schishol@nortel.com> wrote:
> >   
> >> hi
> >>
> >> In section 7.2, the second example indicates it will add 
> an interface,
> >> but uses the operator of replace. The definition of 
> replace does not
> >> actually say that if the entry does not exist, it is created.
> >>     
> >
> > If it doesn't exist and you try to 'replace', it's an error. This is
> > not clearly defined in 7.2, but in the description of the error
> > 'data-missing' it says:
> >
> >    Tag:         data-missing
> >    Error-type:  application
> >    Severity:    error
> >    Error-info:  none
> >    Description: Request could not be completed because the relevant
> >                 data model content does not exist.  For example,
> >                 a 'replace' or 'delete' operation was attempted on
> >                 data which does not exist.
> >
> >
> > 'create' creates an non-existing; it's an error if it exists.
> > 'replace' replaces an existing; it's an error if it doesn't exist.
> > 'merge' creates if it doesn't exist, and modifies if it exists.
> > 'delete' deletes an existing; it's an error if it doesn't exist.
> >
> > So the example text is a bit unclear.
> >   
> 
> This error text is wrong.
> Replace does not cause an error if the data does not exist.
> That was the reason we added create. 
> 
> Merge and replace do not care about existing data.
> 
> Create on data that already exists is an error.
> 
> Delete on data that does not exist is an error.
> 
> Replace foo with nothing is not an error.
> 
> Merge foo with nothing is not an error.
> 
> Replace nothing with foo is not an error.
> 
> Merge nothing with foo is not an error.
> 
> 
> >
> >
> > /martin
> >   
> 
> Andy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 09 12:34:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHP1r-0005pK-7g
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:34:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHP1q-00016J-OU
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:34:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHOvX-0003PU-5Y
	for netconf-data@psg.com; Thu, 09 Mar 2006 17:27:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHOvW-0003PF-0s
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 17:27:50 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k29HRhTM020960
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 12:27:45 -0500
Received: (qmail 2192 invoked from network); 9 Mar 2006 17:27:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 9 Mar 2006 17:27:30 -0000
Message-ID: <441065C0.3000106@andybierman.com>
Date: Thu, 09 Mar 2006 09:28:32 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: Martin Bjorklund <mbj@tail-f.com>, schishol@nortel.com,
        netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <CFEE79A465B35C4385389BA5866BEDF00C7F6D@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7F6D@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c

McDonald, Ira wrote:
> Hi Andy,
>
> Email messages from two years ago aside, this is a pernicious
> and foolish definition of 'replace' that collides with the
> common semantics of 'replace' in all good quality software.
>
> Silently 'replacing' something that isn't there is just plain
> wrong.
>   

Look in the archives for the threads about the create and delete operations.
Remember that NETCONF comes from Junoscript which comes from CLI.
NE CLI has established semantics for merge and replace.
NETCONF preserves those semantics.

For those applications which want pickier semantics
(i.e., create only if doesn't exist and delete only if exists)
we added the create and delete values to the operation attribute.

It is unfortunate that the term 'replace' in the router world doesn't
meet your expectations. In that world, replace the running config
with this other config means "make the new config happen regardless
of what was there before".  NETCONF applies that term to the
individual data elements as well as the entire config, which may be awkward.


> Cheers,
> - Ira
>   

Andy

>
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
>
>   
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>> Behalf Of Andy Bierman
>> Sent: Thursday, March 09, 2006 9:40 AM
>> To: Martin Bjorklund
>> Cc: schishol@nortel.com; netconf@ops.ietf.org
>> Subject: Re: Second Example in section 7.2 of netconf-proto
>>
>>
>> Martin Bjorklund wrote:
>>     
>>> "Sharon Chisholm" <schishol@nortel.com> wrote:
>>>   
>>>       
>>>> hi
>>>>
>>>> In section 7.2, the second example indicates it will add 
>>>>         
>> an interface,
>>     
>>>> but uses the operator of replace. The definition of 
>>>>         
>> replace does not
>>     
>>>> actually say that if the entry does not exist, it is created.
>>>>     
>>>>         
>>> If it doesn't exist and you try to 'replace', it's an error. This is
>>> not clearly defined in 7.2, but in the description of the error
>>> 'data-missing' it says:
>>>
>>>    Tag:         data-missing
>>>    Error-type:  application
>>>    Severity:    error
>>>    Error-info:  none
>>>    Description: Request could not be completed because the relevant
>>>                 data model content does not exist.  For example,
>>>                 a 'replace' or 'delete' operation was attempted on
>>>                 data which does not exist.
>>>
>>>
>>> 'create' creates an non-existing; it's an error if it exists.
>>> 'replace' replaces an existing; it's an error if it doesn't exist.
>>> 'merge' creates if it doesn't exist, and modifies if it exists.
>>> 'delete' deletes an existing; it's an error if it doesn't exist.
>>>
>>> So the example text is a bit unclear.
>>>   
>>>       
>> This error text is wrong.
>> Replace does not cause an error if the data does not exist.
>> That was the reason we added create. 
>>
>> Merge and replace do not care about existing data.
>>
>> Create on data that already exists is an error.
>>
>> Delete on data that does not exist is an error.
>>
>> Replace foo with nothing is not an error.
>>
>> Merge foo with nothing is not an error.
>>
>> Replace nothing with foo is not an error.
>>
>> Merge nothing with foo is not an error.
>>
>>
>>     
>>> /martin
>>>   
>>>       
>> Andy
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <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 Thu Mar 09 12:49:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHPGW-0006C1-2O
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:49:32 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHPGV-0001bM-Ky
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:49:32 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHP97-0004fo-4u
	for netconf-data@psg.com; Thu, 09 Mar 2006 17:41:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FHP96-0004fa-D5
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 17:41:52 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k29HfcC1004919;
	Thu, 9 Mar 2006 09:41:38 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <GH8GRLA3>; Thu, 9 Mar 2006 09:41:39 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7F6E@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
        "McDonald, Ira"
	 <imcdonald@sharplabs.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, schishol@nortel.com,
        netconf@ops.ietf.org
Subject: RE: Second Example in section 7.2 of netconf-proto
Date: Thu, 9 Mar 2006 09:41:38 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250

Hi Andy,

Ah, I see - NETCONF really is limited to configuring routers,
and is not meant to be a general replacement for configuration
of network elements using SNMP/CMIP/etc?

Not a very lofty goal, IMHO.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Thursday, March 09, 2006 12:29 PM
> To: McDonald, Ira
> Cc: Martin Bjorklund; schishol@nortel.com; netconf@ops.ietf.org
> Subject: Re: Second Example in section 7.2 of netconf-proto
> 
> 
> McDonald, Ira wrote:
> > Hi Andy,
> >
> > Email messages from two years ago aside, this is a pernicious
> > and foolish definition of 'replace' that collides with the
> > common semantics of 'replace' in all good quality software.
> >
> > Silently 'replacing' something that isn't there is just plain
> > wrong.
> >   
> 
> Look in the archives for the threads about the create and 
> delete operations.
> Remember that NETCONF comes from Junoscript which comes from CLI.
> NE CLI has established semantics for merge and replace.
> NETCONF preserves those semantics.
> 
> For those applications which want pickier semantics
> (i.e., create only if doesn't exist and delete only if exists)
> we added the create and delete values to the operation attribute.
> 
> It is unfortunate that the term 'replace' in the router world doesn't
> meet your expectations. In that world, replace the running config
> with this other config means "make the new config happen regardless
> of what was there before".  NETCONF applies that term to the
> individual data elements as well as the entire config, which 
> may be awkward.
> 
> 
> > Cheers,
> > - Ira
> >   
> 
> Andy
> 
> >
> > Ira McDonald (Musician / Software Architect)
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: imcdonald@sharplabs.com
> >
> >   
> >> -----Original Message-----
> >> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org]On
> >> Behalf Of Andy Bierman
> >> Sent: Thursday, March 09, 2006 9:40 AM
> >> To: Martin Bjorklund
> >> Cc: schishol@nortel.com; netconf@ops.ietf.org
> >> Subject: Re: Second Example in section 7.2 of netconf-proto
> >>
> >>
> >> Martin Bjorklund wrote:
> >>     
> >>> "Sharon Chisholm" <schishol@nortel.com> wrote:
> >>>   
> >>>       
> >>>> hi
> >>>>
> >>>> In section 7.2, the second example indicates it will add 
> >>>>         
> >> an interface,
> >>     
> >>>> but uses the operator of replace. The definition of 
> >>>>         
> >> replace does not
> >>     
> >>>> actually say that if the entry does not exist, it is created.
> >>>>     
> >>>>         
> >>> If it doesn't exist and you try to 'replace', it's an 
> error. This is
> >>> not clearly defined in 7.2, but in the description of the error
> >>> 'data-missing' it says:
> >>>
> >>>    Tag:         data-missing
> >>>    Error-type:  application
> >>>    Severity:    error
> >>>    Error-info:  none
> >>>    Description: Request could not be completed because 
> the relevant
> >>>                 data model content does not exist.  For example,
> >>>                 a 'replace' or 'delete' operation was attempted on
> >>>                 data which does not exist.
> >>>
> >>>
> >>> 'create' creates an non-existing; it's an error if it exists.
> >>> 'replace' replaces an existing; it's an error if it doesn't exist.
> >>> 'merge' creates if it doesn't exist, and modifies if it exists.
> >>> 'delete' deletes an existing; it's an error if it doesn't exist.
> >>>
> >>> So the example text is a bit unclear.
> >>>   
> >>>       
> >> This error text is wrong.
> >> Replace does not cause an error if the data does not exist.
> >> That was the reason we added create. 
> >>
> >> Merge and replace do not care about existing data.
> >>
> >> Create on data that already exists is an error.
> >>
> >> Delete on data that does not exist is an error.
> >>
> >> Replace foo with nothing is not an error.
> >>
> >> Merge foo with nothing is not an error.
> >>
> >> Replace nothing with foo is not an error.
> >>
> >> Merge nothing with foo is not an error.
> >>
> >>
> >>     
> >>> /martin
> >>>   
> >>>       
> >> Andy
> >>
> >>
> >> --
> >> to unsubscribe send a message to netconf-request@ops.ietf.org with
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <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 Thu Mar 09 12:53:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHPKW-0005nd-LC
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:53:40 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHPKV-0001hC-CC
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 12:53:40 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHPFw-0005Kp-3k
	for netconf-data@psg.com; Thu, 09 Mar 2006 17:48:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHPFv-0005Kb-B3
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 17:48:55 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k29HmrBf006212
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 12:48:53 -0500
Received: (qmail 18581 invoked from network); 9 Mar 2006 17:48:53 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 9 Mar 2006 17:48:53 -0000
Message-ID: <44106AC3.90307@andybierman.com>
Date: Thu, 09 Mar 2006 09:49:55 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: Martin Bjorklund <mbj@tail-f.com>, schishol@nortel.com,
        netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <CFEE79A465B35C4385389BA5866BEDF00C7F6E@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7F6E@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

McDonald, Ira wrote:
> Hi Andy,
>
> Ah, I see - NETCONF really is limited to configuring routers,
> and is not meant to be a general replacement for configuration
> of network elements using SNMP/CMIP/etc?
>
> Not a very lofty goal, IMHO.
>   

First of all, SNMP and CMIP failed completely at the task
of network equipment configuration.

So, yes, our trivial goal is merely to standardize the configuration
of NE devices.  Since this has yet to be accomplished by
any standards body, maybe it isn't so easy.

When we learn how to boil a lake, we will move on
to larger bodies of water.  :-)

> Cheers,
> - Ira
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 09 14:51:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHRAq-0004jm-SH
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 14:51:48 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHRAo-0005RS-Iq
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 14:51:48 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHR64-000E56-Me
	for netconf-data@psg.com; Thu, 09 Mar 2006 19:46:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FHR64-000E4s-5i
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 19:46:52 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k29Jja1Z096526;
	Thu, 9 Mar 2006 11:45:37 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k29JjZ547440;
	Thu, 9 Mar 2006 11:45:36 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k29JooYE061192;
	Thu, 9 Mar 2006 14:50:50 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603091950.k29JooYE061192@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Martin Bjorklund <mbj@tail-f.com>, schishol@nortel.com,
   netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto 
In-Reply-To: Your message of "Thu, 09 Mar 2006 06:39:49 PST."
             <44103E35.8080403@andybierman.com> 
Date: Thu, 09 Mar 2006 14:50:50 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

Andy Bierman writes:
>Merge and replace do not care about existing data.
>Create on data that already exists is an error.
>Delete on data that does not exist is an error.
>Replace foo with nothing is not an error.
>Merge foo with nothing is not an error.
>Replace nothing with foo is not an error.
>Merge nothing with foo is not an error.

This all jibes with my memory.  The purpose of replace was
to replace any and all matching data with the new incoming
config.  So failing if nothing exists wouldn't help anyone.
If you wanted that, you would use "create".

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 09 15:10:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHRT2-0002To-Ly
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 15:10:36 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHRT1-00068b-Cf
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 15:10:36 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHRPB-000Fjh-Pt
	for netconf-data@psg.com; Thu, 09 Mar 2006 20:06:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FHRPB-000FjT-14
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 20:06:37 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k29K6ZTM010907
	for <netconf@ops.ietf.org>; Thu, 9 Mar 2006 15:06:35 -0500
Received: (qmail 25216 invoked from network); 9 Mar 2006 20:06:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 9 Mar 2006 20:06:35 -0000
Message-ID: <44108AC9.6000106@andybierman.com>
Date: Thu, 09 Mar 2006 12:06:33 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Martin Bjorklund <mbj@tail-f.com>, schishol@nortel.com,
        netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <200603091950.k29JooYE061192@idle.juniper.net>
In-Reply-To: <200603091950.k29JooYE061192@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

Phil Shafer wrote:
> Andy Bierman writes:
>   
>> Merge and replace do not care about existing data.
>> Create on data that already exists is an error.
>> Delete on data that does not exist is an error.
>> Replace foo with nothing is not an error.
>> Merge foo with nothing is not an error.
>> Replace nothing with foo is not an error.
>> Merge nothing with foo is not an error.
>>     
>
> This all jibes with my memory.  The purpose of replace was
> to replace any and all matching data with the new incoming
> config.  So failing if nothing exists wouldn't help anyone.
> If you wanted that, you would use "create".
>   

This really matters when you consider simple ordered lists like ACLs.
Without 'replace' you could not exchange all the old entries in the list
for some new entries -- in one operation. 

> Thanks,
>  Phil
>
>   

Andy



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



From owner-netconf@ops.ietf.org Thu Mar 09 16:08:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHSMp-0002Uu-0i
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 16:08:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHSMn-0002AK-9x
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 16:08:14 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHS5G-000JE6-SA
	for netconf-data@psg.com; Thu, 09 Mar 2006 20:50:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [209.173.53.70] (helo=oak.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FHS5G-000JDm-9o
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 20:50:06 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko1BX027025
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Mar 2006 20:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FHS5B-0008WF-R2; Thu, 09 Mar 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-beep-10.txt 
Message-Id: <E1FHS5B-0008WF-R2@stiedprstage1.ietf.org>
Date: Thu, 09 Mar 2006 15:50:01 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

--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-10.txt
	Pages		: 15
	Date		: 2006-3-9
	
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-10.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-10.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-10.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:	<2006-3-9110753.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2006-3-9110753.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 Mar 09 16:08:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHSMp-0002WM-Hm
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 16:08:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHSMo-0002AK-Vr
	for netconf-archive@lists.ietf.org; Thu, 09 Mar 2006 16:08:15 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FHS5X-000JHY-3z
	for netconf-data@psg.com; Thu, 09 Mar 2006 20:50:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no 
	version=3.1.0
Received: from [209.173.57.70] (helo=pine.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FHS5O-000JFQ-Gk
	for netconf@ops.ietf.org; Thu, 09 Mar 2006 20:50:14 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2vP024946
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FHS5C-00005I-1h; Thu, 09 Mar 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-ssh-06.txt 
Message-Id: <E1FHS5C-00005I-1h@stiedprstage1.ietf.org>
Date: Thu, 09 Mar 2006 15:50:02 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

--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-06.txt
	Pages		: 11
	Date		: 2006-3-9
	
This document describes a method for invoking and running the NETCONF
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-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-netconf-ssh-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-ssh-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2006-3-9112511.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2006-3-9112511.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 Sun Mar 12 01:46:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIKLq-0006p5-SX
	for netconf-archive@lists.ietf.org; Sun, 12 Mar 2006 01:46:50 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FIKLl-0003Nc-E1
	for netconf-archive@lists.ietf.org; Sun, 12 Mar 2006 01:46:50 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FIKBE-000Nu2-Tg
	for netconf-data@psg.com; Sun, 12 Mar 2006 06:35:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [217.12.11.79] (helo=smtp010.mail.ukl.yahoo.com)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <vincent.cridlig@loria.fr>)
	id 1FIKBD-000Ntq-MQ
	for netconf@ops.ietf.org; Sun, 12 Mar 2006 06:35:52 +0000
Received: (qmail 2170 invoked from network); 12 Mar 2006 06:35:49 -0000
Received: from unknown (HELO ?192.168.0.2?) (cridligv@213.44.155.5 with plain)
  by smtp010.mail.ukl.yahoo.com with SMTP; 12 Mar 2006 06:35:49 -0000
Message-ID: <4413C1D6.5010103@loria.fr>
Date: Sun, 12 Mar 2006 07:38:14 +0100
From: Cridlig Vincent <vincent.cridlig@loria.fr>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  arnaud.Goulois@enst-bretagne.fr,  netconf@ops.ietf.org
Subject: Re: [ensuite] Probleme avec le module BGP
References: <1141657675.440c504b92cf7@diogel.enst-bretagne.fr>
In-Reply-To: <1141657675.440c504b92cf7@diogel.enst-bretagne.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

Hi,

This is because the BGP module has not been developped yet on the 
manager side (YencaPManager).
Even if it works on the agent (YencaP).
For now, you have to use the base operations (edit-config, get-config, 
...) to configure BGP with YencaPManager.

Vincent


arnaud.Goulois@enst-bretagne.fr wrote:

>Bonjour,
>
>Nous essayons de configurer BGP grace au module fourni. Nous avons suivi
>les indications pour l'installation (ie installation de Quagga,
>modification du fichier modules.xml comme indiqué dans la doc). Cependant,
>lorsque nous choisissons ce module dans le yencaPManager nous avons le
>message d'erreur suivant : [Errno 2] No such file or directory: 'bgp'
>Nous avons essayé différentes config en vain...
>Merci pour votre aide.
>
>Cordialement,
>
>Arnaud Goulois
>  
>


	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com


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



From owner-netconf@ops.ietf.org Mon Mar 13 03:32:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIiTS-0000Bf-Ns
	for netconf-archive@lists.ietf.org; Mon, 13 Mar 2006 03:32:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FIiTO-0005pW-B5
	for netconf-archive@lists.ietf.org; Mon, 13 Mar 2006 03:32:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FIiMN-0003Vc-KF
	for netconf-data@psg.com; Mon, 13 Mar 2006 08:24:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [152.81.1.70] (helo=macker.loria.fr)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <vincent.cridlig@loria.fr>)
	id 1FIiMK-0003VJ-Ai
	for netconf@ops.ietf.org; Mon, 13 Mar 2006 08:24:56 +0000
Received: from localhost.loria.fr (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP id 5A1266448F
	for <netconf@ops.ietf.org>; Mon, 13 Mar 2006 09:24:54 +0100 (CET)
X-Amavix: Anti-virus check done by ClamAV
X-Amavix: Scanned by Amavix
Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136])
	by macker.loria.fr (Postfix) with ESMTP id 2A293630D1
	for <netconf@ops.ietf.org>; Mon, 13 Mar 2006 09:24:50 +0100 (CET)
Message-ID: <44152D0C.8010302@loria.fr>
Date: Mon, 13 Mar 2006 09:27:56 +0100
From: Vincent Cridlig <vincent.cridlig@loria.fr>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: Mailing error
Content-Type: multipart/mixed;
 boundary="------------070805000502050506080301"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

This is a multi-part message in MIME format.
--------------070805000502050506080301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sorry about my previous mail, I confused two mailing lists.
Vincent


--------------070805000502050506080301
Content-Type: text/x-vcard; charset=utf-8;
 name="vincent.cridlig.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="vincent.cridlig.vcf"

begin:vcard
fn:Vincent Cridlig
n:Cridlig;Vincent
org:LORIA - INRIA Lorraine;Madynes
adr:;;;Nancy;;;France
email;internet:cridligv@loria.fr
title:PhD Student
tel;work:+33 (0)3 83 59 20 48
url:http://www.loria.fr/~cridligv
version:2.1
end:vcard


--------------070805000502050506080301--

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



From owner-netconf@ops.ietf.org Wed Mar 15 18:03:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJf1R-0001ud-Cw
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:03:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJf1Q-0003Rf-3b
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:03:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJetq-000DDN-2B
	for netconf-data@psg.com; Wed, 15 Mar 2006 22:55:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.161] (helo=ihemail1.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FJetp-000DD7-Bp
	for netconf@ops.ietf.org; Wed, 15 Mar 2006 22:55:25 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2FMtDYS026294;
	Wed, 15 Mar 2006 16:55:14 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <G3YWZTYJ>; Wed, 15 Mar 2006 23:55:11 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E18DD@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "Andy Bierman (E-mail)" <ietf@andybierman.com>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	d  [I06-051127-0011]
Date: Wed, 15 Mar 2006 23:55:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

I was trying to find the answer to this IANA quesion,
and I cannot find it. Did we (WG) decide what we want?

I need to know BEFORE the IESG telechat (11:30 EST) tomorrow (thursday)
if possible.

Bert

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of IANA
> Sent: Tuesday, February 28, 2006 18:44
> To: 'Wijnen, Bert (Bert)'
> Cc: 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
> iana-drafts@icann.org
> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standard [I06-051127-0011]
> 
> 
> Bert,
> 
> I still don't see what range the port needs to go in...
> User (0-1023) or system (1024-49151) range?
> 
> Am I missing a note somewhere that give this information?
> 
> Thanks,
> 
> Michelle
> IANA

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



From owner-netconf@ops.ietf.org Wed Mar 15 18:13:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJfBD-0007eh-Lx
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:13:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJfBD-0003o8-Cc
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:13:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJf7n-000Eb8-QG
	for netconf-data@psg.com; Wed, 15 Mar 2006 23:09:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FJf7n-000Eao-3y
	for netconf@ops.ietf.org; Wed, 15 Mar 2006 23:09:51 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2FN9f1Z067443;
	Wed, 15 Mar 2006 15:09:41 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2FN9e511145;
	Wed, 15 Mar 2006 15:09:40 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2FNEpYE088682;
	Wed, 15 Mar 2006 18:14:52 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603152314.k2FNEpYE088682@idle.juniper.net>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
   "Andy Bierman (E-mail)" <ietf@andybierman.com>,
   "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
   IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011] 
In-Reply-To: Your message of "Wed, 15 Mar 2006 23:55:10 +0100."
             <7D5D48D2CAA3D84C813F5B154F43B155098E18DD@nl0006exch001u.nl.lucent.com> 
Date: Wed, 15 Mar 2006 18:14:51 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

The only reason to have it <1024 is to keep unix users from running
it as non-root.  While this is fairly weak security, it does prevent
untrusted users on trusted hosts (whose host-key your client likes)
from starting a process that mimics the real ssh-based netconf daemon
and skims whatever information it can.  Then again, I guess you'd
need to be root to have the private version of the host key, so
it's not really an issue.

So IMHO it doesn't matter.

Thanks,
 Phil



"Wijnen, Bert (Bert)" writes:
>I was trying to find the answer to this IANA quesion,
>and I cannot find it. Did we (WG) decide what we want?
>
>I need to know BEFORE the IESG telechat (11:30 EST) tomorrow (thursday)
>if possible.
>
>Bert
>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>> Behalf Of IANA
>> Sent: Tuesday, February 28, 2006 18:44
>> To: 'Wijnen, Bert (Bert)'
>> Cc: 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
>> iana-drafts@icann.org
>> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
>> Standard [I06-051127-0011]
>> 
>> 
>> Bert,
>> 
>> I still don't see what range the port needs to go in...
>> User (0-1023) or system (1024-49151) range?
>> 
>> Am I missing a note somewhere that give this information?
>> 
>> Thanks,
>> 
>> Michelle
>> IANA
>
>--
>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 Wed Mar 15 18:23:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJfKn-0002Dx-S0
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:23:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJfKn-0003xX-I1
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:23:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJfHN-000FK3-Mc
	for netconf-data@psg.com; Wed, 15 Mar 2006 23:19:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.161] (helo=ihemail1.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FJfHM-000FJo-Op
	for netconf@ops.ietf.org; Wed, 15 Mar 2006 23:19:44 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2FNJY4D001411;
	Wed, 15 Mar 2006 17:19:35 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <G3YWZ4AM>; Thu, 16 Mar 2006 00:19:33 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E18E1@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Phil Shafer <phil@juniper.net>,
        "Wijnen, Bert (Bert)"
	 <bwijnen@lucent.com>
Cc: "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "Andy Bierman (E-mail)" <ietf@andybierman.com>,
        "'Netconf (E-mail)'"
	 <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011] 
Date: Thu, 16 Mar 2006 00:19:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

But am amswer of "it doies not matter" does not help the IANA
to make an assignment. We as a WG must choose. If it does not
matter, then I guess we're saying >1024.

Bert

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Thursday, March 16, 2006 00:15
> To: Wijnen, Bert (Bert)
> Cc: 'Margaret Wasserman (E-mail)'; Andy Bierman (E-mail); 'Netconf
> (E-mail)'; iana-drafts@icann.org; IANA
> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standar d [I06-051127-0011] 
> 
> 
> The only reason to have it <1024 is to keep unix users from running
> it as non-root.  While this is fairly weak security, it does prevent
> untrusted users on trusted hosts (whose host-key your client likes)
> from starting a process that mimics the real ssh-based netconf daemon
> and skims whatever information it can.  Then again, I guess you'd
> need to be root to have the private version of the host key, so
> it's not really an issue.
> 
> So IMHO it doesn't matter.
> 
> Thanks,
>  Phil
> 
> 
> 
> "Wijnen, Bert (Bert)" writes:
> >I was trying to find the answer to this IANA quesion,
> >and I cannot find it. Did we (WG) decide what we want?
> >
> >I need to know BEFORE the IESG telechat (11:30 EST) tomorrow 
> (thursday)
> >if possible.
> >
> >Bert
> >
> >> -----Original Message-----
> >> From: owner-netconf@ops.ietf.org 
[mailto:owner-netconf@ops.ietf.org]On
>> Behalf Of IANA
>> Sent: Tuesday, February 28, 2006 18:44
>> To: 'Wijnen, Bert (Bert)'
>> Cc: 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
>> iana-drafts@icann.org
>> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
>> Standard [I06-051127-0011]
>> 
>> 
>> Bert,
>> 
>> I still don't see what range the port needs to go in...
>> User (0-1023) or system (1024-49151) range?
>> 
>> Am I missing a note somewhere that give this information?
>> 
>> Thanks,
>> 
>> Michelle
>> IANA
>
>--
>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 Wed Mar 15 18:34:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJfVo-0003Kd-RR
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:34:40 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJfVo-000475-Df
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 18:34:40 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJfRv-000Fyr-Ck
	for netconf-data@psg.com; Wed, 15 Mar 2006 23:30:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJfRs-000FyE-IZ
	for netconf@ops.ietf.org; Wed, 15 Mar 2006 23:30:36 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2FNUYhB010447
	for <netconf@ops.ietf.org>; Wed, 15 Mar 2006 18:30:35 -0500
Received: (qmail 15035 invoked from network); 15 Mar 2006 23:30:34 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 15 Mar 2006 23:30:34 -0000
Message-ID: <4418A3BA.6020306@andybierman.com>
Date: Wed, 15 Mar 2006 15:31:06 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: Phil Shafer <phil@juniper.net>,
        "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
  d [I06-051127-0011]
References: <7D5D48D2CAA3D84C813F5B154F43B155098E18E1@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155098E18E1@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1

Wijnen, Bert (Bert) wrote:
> But am amswer of "it doies not matter" does not help the IANA
> to make an assignment. We as a WG must choose. If it does not
> matter, then I guess we're saying >1024.
>   

Eliot did answer this -- we want a port number < 1024

> Bert
>   

Andy

>   
>> -----Original Message-----
>> From: Phil Shafer [mailto:phil@juniper.net]
>> Sent: Thursday, March 16, 2006 00:15
>> To: Wijnen, Bert (Bert)
>> Cc: 'Margaret Wasserman (E-mail)'; Andy Bierman (E-mail); 'Netconf
>> (E-mail)'; iana-drafts@icann.org; IANA
>> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
>> Standar d [I06-051127-0011] 
>>
>>
>> The only reason to have it <1024 is to keep unix users from running
>> it as non-root.  While this is fairly weak security, it does prevent
>> untrusted users on trusted hosts (whose host-key your client likes)
>> from starting a process that mimics the real ssh-based netconf daemon
>> and skims whatever information it can.  Then again, I guess you'd
>> need to be root to have the private version of the host key, so
>> it's not really an issue.
>>
>> So IMHO it doesn't matter.
>>
>> Thanks,
>>  Phil
>>
>>
>>
>> "Wijnen, Bert (Bert)" writes:
>>     
>>> I was trying to find the answer to this IANA quesion,
>>> and I cannot find it. Did we (WG) decide what we want?
>>>
>>> I need to know BEFORE the IESG telechat (11:30 EST) tomorrow 
>>>       
>> (thursday)
>>     
>>> if possible.
>>>
>>> Bert
>>>
>>>       
>>>> -----Original Message-----
>>>> From: owner-netconf@ops.ietf.org 
>>>>         
> [mailto:owner-netconf@ops.ietf.org]On
>   
>>> Behalf Of IANA
>>> Sent: Tuesday, February 28, 2006 18:44
>>> To: 'Wijnen, Bert (Bert)'
>>> Cc: 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
>>> iana-drafts@icann.org
>>> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
>>> Standard [I06-051127-0011]
>>>
>>>
>>> Bert,
>>>
>>> I still don't see what range the port needs to go in...
>>> User (0-1023) or system (1024-49151) range?
>>>
>>> Am I missing a note somewhere that give this information?
>>>
>>> Thanks,
>>>
>>> Michelle
>>> IANA
>>>       
>> --
>> 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 Wed Mar 15 20:10:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJh0t-00088i-1b
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 20:10:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJh0r-0007BO-O9
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 20:10:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJgwM-000NqM-R4
	for netconf-data@psg.com; Thu, 16 Mar 2006 01:06:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJgwL-000Npr-KJ
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 01:06:10 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2G168hB016110
	for <netconf@ops.ietf.org>; Wed, 15 Mar 2006 20:06:08 -0500
Received: (qmail 28664 invoked from network); 16 Mar 2006 01:06:08 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 16 Mar 2006 01:06:08 -0000
Message-ID: <4418BA2E.8030700@andybierman.com>
Date: Wed, 15 Mar 2006 17:06:54 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: transport mappings capability
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

Hi,


Remind me again how a manager figures out which optional
transport mappings are supported?

A client connects to NETCONF-over-SSH on the new mandatory
NETCONF-over-SSH port -- that much I understand.  Except
for trial and error, how does the client know
if the agent supports BEEP, SOAP, and on which
ports.  What if NETCONF over SOAP/HTTPS is available
on port 443?  What about NETCONF over SSH on port 23?

Do we need a 'transport' capability similar to our 'url' capability?
 
====================================

Capability: transport

Purpose: Describes the transport mappings supported by the agent

urn:ietf:params:netconf:capability:transport:1.0?
               protocols={ssh,ssh:23,beep,soap,soap:443}

Key: <prot> == protocol on the default NETCONF port for that protocol
     <prot>:<num> == protocol on the specified port number

The capability 'protocols={ssh}' is the default, and therefore not required
to be present if no other transport mappings are supported.

Affected/new operations: none/none

=====================================

IMO, the whole point of this programmatic interface thing
is efficient, deterministic exchanges between the manager and agent.


Andy


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



From owner-netconf@ops.ietf.org Wed Mar 15 21:40:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJiPA-0001yR-3Q
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 21:40:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJiP8-0000Ng-R8
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 21:40:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJiKb-00038r-9J
	for netconf-data@psg.com; Thu, 16 Mar 2006 02:35:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FJiKa-00038f-KP
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 02:35:16 +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 k2G2Z5X24853;
	Wed, 15 Mar 2006 18:35:05 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2G2Yx549844;
	Wed, 15 Mar 2006 18:34:59 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2G2eAYE089433;
	Wed, 15 Mar 2006 21:40:10 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603160240.k2G2eAYE089433@idle.juniper.net>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
   "Andy Bierman (E-mail)" <ietf@andybierman.com>,
   "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
   IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011] 
In-Reply-To: Your message of "Thu, 16 Mar 2006 00:19:33 +0100."
             <7D5D48D2CAA3D84C813F5B154F43B155098E18E1@nl0006exch001u.nl.lucent.com> 
Date: Wed, 15 Mar 2006 21:40:10 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

"Wijnen, Bert (Bert)" writes:
>But am amswer of "it doies not matter" does not help the IANA
>to make an assignment. We as a WG must choose. If it does not
>matter, then I guess we're saying >1024.

Sorry, that was what I meant.  If it doesn't matter to the
netconf protocol, we shouldn't be eating the relatively
scarce resource.  Especially three of them.

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 Wed Mar 15 22:24:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJj6g-00066d-Sw
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 22:24:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJj6f-0002Aa-JU
	for netconf-archive@lists.ietf.org; Wed, 15 Mar 2006 22:24:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJj0b-0005rh-Sn
	for netconf-data@psg.com; Thu, 16 Mar 2006 03:18:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJj0a-0005rU-7Y
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 03:18:40 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2G3IchB010961
	for <netconf@ops.ietf.org>; Wed, 15 Mar 2006 22:18:39 -0500
Received: (qmail 6559 invoked from network); 16 Mar 2006 03:18:38 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 16 Mar 2006 03:18:38 -0000
Message-ID: <4418D950.3090400@andybierman.com>
Date: Wed, 15 Mar 2006 19:19:44 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>, Eliot Lear <lear@cisco.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <200603160240.k2G2eAYE089433@idle.juniper.net>
In-Reply-To: <200603160240.k2G2eAYE089433@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

Phil Shafer wrote:
> "Wijnen, Bert (Bert)" writes:
>   
>> But am amswer of "it doies not matter" does not help the IANA
>> to make an assignment. We as a WG must choose. If it does not
>> matter, then I guess we're saying >1024.
>>     
>
> Sorry, that was what I meant.  If it doesn't matter to the
> netconf protocol, we shouldn't be eating the relatively
> scarce resource.  Especially three of them.
>   

I see your point.
AFAIK, the WG never discussed the need for a port number < 1024
in any detail.  Since our authorization schemes don't rely on a system
port number to work ;-) and the WG never specifically decided this issue,
we should revisit this question.

Why do we need system port numbers?
If we don't, then Phil is right, we should get numbers > 1024.
(Eliot, do you have a response?)
> Thanks,
>  Phil
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 16 01:03:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJlZu-0002FF-Oo
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 01:03:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJlZu-0005n0-7v
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 01:03:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJlV2-000FXL-Ek
	for netconf-data@psg.com; Thu, 16 Mar 2006 05:58:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FJlV1-000FX9-Nj
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 05:58:15 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2G5vpOF023992;
	Wed, 15 Mar 2006 21:57:55 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <G41HH0ML>; Wed, 15 Mar 2006 21:57:52 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FA0@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
        "Wijnen, Bert (Bert)"
	 <bwijnen@lucent.com>
Cc: Phil Shafer <phil@juniper.net>,
        "'Margaret Wasserman (E-mail)'"
	 <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011]
Date: Wed, 15 Mar 2006 21:57:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3

No, as Phil Shafer just said, there's no justification for
Netconf consuming the scarce resource of a well-known port
less than 1024.  

And just asking is NOT a sufficient justification, Andy.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Wednesday, March 15, 2006 6:31 PM
> To: Wijnen, Bert (Bert)
> Cc: Phil Shafer; 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
> iana-drafts@icann.org; IANA
> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standar d [I06-051127-0011]
> 
> 
> Wijnen, Bert (Bert) wrote:
> > But am amswer of "it doies not matter" does not help the IANA
> > to make an assignment. We as a WG must choose. If it does not
> > matter, then I guess we're saying >1024.
> >   
> 
> Eliot did answer this -- we want a port number < 1024
> 
> > Bert
> >   
> 
> Andy
> 
> >   
> >> -----Original Message-----
> >> From: Phil Shafer [mailto:phil@juniper.net]
> >> Sent: Thursday, March 16, 2006 00:15
> >> To: Wijnen, Bert (Bert)
> >> Cc: 'Margaret Wasserman (E-mail)'; Andy Bierman (E-mail); 'Netconf
> >> (E-mail)'; iana-drafts@icann.org; IANA
> >> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> >> Standar d [I06-051127-0011] 
> >>
> >>
> >> The only reason to have it <1024 is to keep unix users from running
> >> it as non-root.  While this is fairly weak security, it 
> does prevent
> >> untrusted users on trusted hosts (whose host-key your client likes)
> >> from starting a process that mimics the real ssh-based 
> netconf daemon
> >> and skims whatever information it can.  Then again, I guess you'd
> >> need to be root to have the private version of the host key, so
> >> it's not really an issue.
> >>
> >> So IMHO it doesn't matter.
> >>
> >> Thanks,
> >>  Phil
> >>
> >>
> >>
> >> "Wijnen, Bert (Bert)" writes:
> >>     
> >>> I was trying to find the answer to this IANA quesion,
> >>> and I cannot find it. Did we (WG) decide what we want?
> >>>
> >>> I need to know BEFORE the IESG telechat (11:30 EST) tomorrow 
> >>>       
> >> (thursday)
> >>     
> >>> if possible.
> >>>
> >>> Bert
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: owner-netconf@ops.ietf.org 
> >>>>         
> > [mailto:owner-netconf@ops.ietf.org]On
> >   
> >>> Behalf Of IANA
> >>> Sent: Tuesday, February 28, 2006 18:44
> >>> To: 'Wijnen, Bert (Bert)'
> >>> Cc: 'Margaret Wasserman (E-mail)'; 'Netconf (E-mail)';
> >>> iana-drafts@icann.org
> >>> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> >>> Standard [I06-051127-0011]
> >>>
> >>>
> >>> Bert,
> >>>
> >>> I still don't see what range the port needs to go in...
> >>> User (0-1023) or system (1024-49151) range?
> >>>
> >>> Am I missing a note somewhere that give this information?
> >>>
> >>> Thanks,
> >>>
> >>> Michelle
> >>> IANA
> >>>       
> >> --
> >> 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 Thu Mar 16 07:14:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJrNM-0002It-A4
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 07:14:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJrNK-0007KK-Mr
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 07:14:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJrHQ-000Flm-R1
	for netconf-data@psg.com; Thu, 16 Mar 2006 12:08:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FJrHP-000FlY-TD
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 12:08:36 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B9C654F0001
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 13:08:34 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 16 Mar 2006 13:08:34 +0100
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 16 Mar 2006 13:08:34 +0100
Message-ID: <44195542.3090701@ericsson.com>
Date: Thu, 16 Mar 2006 13:08:34 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: IETF 65 NETCONF WG agenda
References: <43FB5F80.5010703@andybierman.com>
In-Reply-To: <43FB5F80.5010703@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Mar 2006 12:08:34.0300 (UTC) FILETIME=[593B93C0:01C648F2]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Hello,
Draft-12 writes

    Tag:         access-denied
    Error-type:  rpc, protocol, application
    Severity:    error
    Error-info:  none
    Description: Access to the requested RPC, protocol operation,
                 or data model is denied because authorization failed

This does not specify which part of an operation is denied. Now imagine that we have an 
edit-config operation that touches the configuration in 10 different places from which 
only one is denied.

How will the operator find out which part is rejected ? Do we need a get-config operation 
? Wouldn't it be better to include in the error-info the rejected part ?

Balazs


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



From owner-netconf@ops.ietf.org Thu Mar 16 10:21:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJuI7-0007jV-51
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 10:21:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJuI5-0005AG-Rx
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 10:21:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJuCj-00050P-99
	for netconf-data@psg.com; Thu, 16 Mar 2006 15:15:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJuCi-000508-CC
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 15:15:56 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2GFFsOj024761
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 10:15:55 -0500
Received: (qmail 801 invoked from network); 16 Mar 2006 15:15:54 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 16 Mar 2006 15:15:54 -0000
Message-ID: <441981A3.5020704@andybierman.com>
Date: Thu, 16 Mar 2006 07:17:55 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: IETF 65 NETCONF WG agenda
References: <43FB5F80.5010703@andybierman.com> <44195542.3090701@ericsson.com>
In-Reply-To: <44195542.3090701@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

Balazs Lengyel wrote:
> Hello,
> Draft-12 writes
>
>    Tag:         access-denied
>    Error-type:  rpc, protocol, application
>    Severity:    error
>    Error-info:  none
>    Description: Access to the requested RPC, protocol operation,
>                 or data model is denied because authorization failed
>
> This does not specify which part of an operation is denied. Now 
> imagine that we have an edit-config operation that touches the 
> configuration in 10 different places from which only one is denied.
>
> How will the operator find out which part is rejected ? Do we need a 
> get-config operation ? Wouldn't it be better to include in the 
> error-info the rejected part ?

This has traditionally been a no-no in the security world.
You don't tell attackers anything that might help them
get further.    The agent doesn't know the difference
between a buggy manager and an attack.

>
> Balazs

Andy

>
>
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 16 11:59:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJvp8-0002Vz-9F
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 11:59:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJvp7-0000NG-03
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 11:59:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJviw-000CGO-GL
	for netconf-data@psg.com; Thu, 16 Mar 2006 16:53:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FJviv-000CG9-T8
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 16:53:17 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-3.cisco.com with ESMTP; 16 Mar 2006 08:53:17 -0800
X-IronPort-AV: i="4.02,198,1139212800"; 
   d="scan'208"; a="416524036:sNHT74793164"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2GGrHw1001399;
	Thu, 16 Mar 2006 08:53:17 -0800 (PST)
Received: from [171.71.249.189] (dhcp-171-71-249-189.cisco.com [171.71.249.189])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2GGsain013899;
	Thu, 16 Mar 2006 08:54:36 -0800
Message-ID: <441997FE.5060103@cisco.com>
Date: Thu, 16 Mar 2006 08:53:18 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Phil Shafer <phil@juniper.net>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <200603160240.k2G2eAYE089433@idle.juniper.net> <4418D950.3090400@andybierman.com>
In-Reply-To: <4418D950.3090400@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=119; t=1142528077; x=1142960277;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Evaluation=3A=20draft-ietf-netconf-ssh-05.txt=20to=20Proposed=20
	Standar=0A=20d=20[I06-051127-0011]
	|To:Andy=20Bierman=20<ietf@andybierman.com>;
	X=v=3Dmtcc.com=3B=20h=3DREt3pw5DMAZu3/Bs1nnu3sqcEno=3D; b=sElPfmmRxK2nXvb99AToJV5sGuJzD6PXs1V6NqGnrGRLtbYU4MdV5sBsoVXvlJX59eabOv6E
	+1AWqZKLDgeJR5w6mvcWLSsY8f5GAHvDhyf6LSWD57qbtQgddMUUhFeEs2DrL5SVNxFWTEpS4F6
	jYmMBysgTqGq4t8EYd55//yE=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014

Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
REASON TO MAKE THE PORT PRIVILEGED?!!

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 Thu Mar 16 13:23:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJx8f-0005rL-7q
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 13:23:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJx8d-00038H-RS
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 13:23:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJx4W-000IxO-C0
	for netconf-data@psg.com; Thu, 16 Mar 2006 18:19:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FJx4T-000Iwx-P0
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 18:19:37 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2GIJZT08466
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 13:19:35 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Date: Thu, 16 Mar 2006 13:19:33 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40762962B@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Thread-Index: AcZJG17gm+5/hQimSMKdhhUBHGIXWgACoaXw
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

hi

Just to clarify, the options are the following?

1) Standards assignment < 1024
2) Informal assignment > 1023
3) Say nothing

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Eliot Lear
Sent: Thursday, March 16, 2006 11:53 AM
To: Andy Bierman
Cc: Phil Shafer; Wijnen, Bert (Bert); 'Margaret Wasserman (E-mail)';
'Netconf (E-mail)'; iana-drafts@icann.org; IANA
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
Standar d [I06-051127-0011]


Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
REASON TO MAKE THE PORT PRIVILEGED?!!

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 Thu Mar 16 13:29:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxEA-0000fS-2i
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 13:29:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxE9-0003Ha-PE
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 13:29:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxBC-000JQY-J2
	for netconf-data@psg.com; Thu, 16 Mar 2006 18:26:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FJxBB-000JQJ-Rc
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 18:26:34 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2GIQTT09505
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 13:26:29 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: transport mappings capability
Date: Thu, 16 Mar 2006 13:26:27 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407629649@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: transport mappings capability
Thread-Index: AcZIlqHntKi/lfmGQkqVg0utWRyjkAAkB1CQ
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

hi

It's a bit of a chicken and an egg issues. If I can talk to you, I know
how to talk to you. If I can't talk to you, I can't learn how to talk to
you. A well-known port would certainly be helpful for this case.

I guess your capability proposal is to solve the problem where I might
prefer to talk to you using another transport protocol. Having a
capability wouldn't hurt in this case, but this is more of a corner case
then being able to talk in the first place.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, March 15, 2006 8:07 PM
To: Netconf (E-mail)
Subject: transport mappings capability


Hi,


Remind me again how a manager figures out which optional transport
mappings are supported?

A client connects to NETCONF-over-SSH on the new mandatory
NETCONF-over-SSH port -- that much I understand.  Except for trial and
error, how does the client know if the agent supports BEEP, SOAP, and on
which ports.  What if NETCONF over SOAP/HTTPS is available on port 443?
What about NETCONF over SSH on port 23?

Do we need a 'transport' capability similar to our 'url' capability?
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Capability: transport

Purpose: Describes the transport mappings supported by the agent

urn:ietf:params:netconf:capability:transport:1.0?
               protocols=3D{ssh,ssh:23,beep,soap,soap:443}

Key: <prot> =3D=3D protocol on the default NETCONF port for that =
protocol
     <prot>:<num> =3D=3D protocol on the specified port number

The capability 'protocols=3D{ssh}' is the default, and therefore not
required to be present if no other transport mappings are supported.

Affected/new operations: none/none

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

IMO, the whole point of this programmatic interface thing
is efficient, deterministic exchanges between the manager and agent.


Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Thu Mar 16 14:04:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxlh-0005xg-0m
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:04:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxlg-0004rs-K4
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:04:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxhR-000Lvc-RP
	for netconf-data@psg.com; Thu, 16 Mar 2006 18:59:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJxhQ-000LvP-Hu
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 18:59:53 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2GIxoDT022095
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 13:59:51 -0500
Received: (qmail 25074 invoked from network); 16 Mar 2006 18:59:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 16 Mar 2006 18:59:50 -0000
Message-ID: <4419B620.1070308@andybierman.com>
Date: Thu, 16 Mar 2006 11:01:52 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: transport mappings capability
References: <713043CE8B8E1348AF3C546DBE02C1B407629649@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407629649@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2

Sharon Chisholm wrote:
> hi
>
> It's a bit of a chicken and an egg issues. If I can talk to you, I know
> how to talk to you. If I can't talk to you, I can't learn how to talk to
> you. A well-known port would certainly be helpful for this case.
>
>   

We will have that.

> I guess your capability proposal is to solve the problem where I might
> prefer to talk to you using another transport protocol. Having a
> capability wouldn't hurt in this case, but this is more of a corner case
> then being able to talk in the first place.
>   

There is no corner case.   It is just a need to discover all the
mappings that an agent will support.

A manager can always talk to an agent over the default mapping (SSH).
The issue is whether a standard capability, standard data model,
or proprietary mechanism be used to find out if any other mappings
are supported.  


> Sharon
>   

Andy

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Wednesday, March 15, 2006 8:07 PM
> To: Netconf (E-mail)
> Subject: transport mappings capability
>
>
> Hi,
>
>
> Remind me again how a manager figures out which optional transport
> mappings are supported?
>
> A client connects to NETCONF-over-SSH on the new mandatory
> NETCONF-over-SSH port -- that much I understand.  Except for trial and
> error, how does the client know if the agent supports BEEP, SOAP, and on
> which ports.  What if NETCONF over SOAP/HTTPS is available on port 443?
> What about NETCONF over SSH on port 23?
>
> Do we need a 'transport' capability similar to our 'url' capability?
>  
> ====================================
>
> Capability: transport
>
> Purpose: Describes the transport mappings supported by the agent
>
> urn:ietf:params:netconf:capability:transport:1.0?
>                protocols={ssh,ssh:23,beep,soap,soap:443}
>
> Key: <prot> == protocol on the default NETCONF port for that protocol
>      <prot>:<num> == protocol on the specified port number
>
> The capability 'protocols={ssh}' is the default, and therefore not
> required to be present if no other transport mappings are supported.
>
> Affected/new operations: none/none
>
> =====================================
>
> IMO, the whole point of this programmatic interface thing
> is efficient, deterministic exchanges between the manager and agent.
>
>
> Andy
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 16 14:04:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxls-00062K-4J
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:04:28 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxlr-0004s8-RR
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:04:28 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxhc-000LxO-Bv
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:00:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJxhb-000Lwq-Au
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:00:03 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2GJ02DT022369
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 14:00:02 -0500
Received: (qmail 25227 invoked from network); 16 Mar 2006 19:00:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 16 Mar 2006 19:00:01 -0000
Message-ID: <4419B62A.5090600@andybierman.com>
Date: Thu, 16 Mar 2006 11:02:02 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: Phil Shafer <phil@juniper.net>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <200603160240.k2G2eAYE089433@idle.juniper.net> <4418D950.3090400@andybierman.com> <441997FE.5060103@cisco.com>
In-Reply-To: <441997FE.5060103@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

Eliot Lear wrote:
> Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
> REASON TO MAKE THE PORT PRIVILEGED?!!
>   

I guess you feel strongly about it then?  ;-)

Most of the WG doesn't seem to care either way.

The most compelling reason not to use a system port number is
to save them for the future.  Simon pointed out there are about 312 such
port numbers left.  The difference between 309 and 312 isn't very 
compelling.

IMO, since CLI over SSH is by default on a system port, then NETCONF 
over SSH
should do the same.  SOAP and BEEP mappings should be in the same range as
the SSH mapping, to be consistent.  (The default for SOAP over HTTPS is
a system port, as well as SOAP over BEEP.)   This would be consistent
with best current practice for CLI.

This seems to be more compelling logic than saving 3 system port numbers.

Unless there any strong objections,  we will ask for port numbers < 1024.


> Eliot
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 16 14:06:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxoG-0008MT-Bh
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:06:56 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxoF-0004yv-V5
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:06:56 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxl6-000MFB-C2
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:03:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FJxl5-000MF0-J1
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:03:39 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2GJ3Qpc020434;
	Thu, 16 Mar 2006 11:03:30 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYXFY9>; Thu, 16 Mar 2006 11:03:27 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Sharon Chisholm'" <schishol@nortel.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011]
Date: Thu, 16 Mar 2006 11:03:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

Hi Sharon, Eliot, et al,

You've all misreprented the choices - actual options are:

(1) IANA-assigned "Well Known Port" (0 to 1023)
    - approximately 70% are now assigned 
    - very scarce resource

(2) IANA-assigned "Registered Port" (1024 to 49151)
    - approximately %12 are now assigned 
    - plentiful resource

(3) Unregistered "Dynamic or Private Port" (49152 to 65535)
    - not a reasonable choice for NetConf or any standard service

Option (2) is obviously the prudent choide.

It is not possible to use NetConf (or SHOULD NOT be) without
strong authentication - in any case, security professionals
do NOT accept the pseudo-security of "well known ports" based
on their numeric values.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Sharon Chisholm
> Sent: Thursday, March 16, 2006 1:20 PM
> To: Netconf (E-mail)
> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standar d [I06-051127-0011]
> 
> 
> hi
> 
> Just to clarify, the options are the following?
> 
> 1) Standards assignment < 1024
> 2) Informal assignment > 1023
> 3) Say nothing
> 
> Sharon
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Eliot Lear
> Sent: Thursday, March 16, 2006 11:53 AM
> To: Andy Bierman
> Cc: Phil Shafer; Wijnen, Bert (Bert); 'Margaret Wasserman (E-mail)';
> 'Netconf (E-mail)'; iana-drafts@icann.org; IANA
> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standar d [I06-051127-0011]
> 
> 
> Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
> REASON TO MAKE THE PORT PRIVILEGED?!!
> 
> 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 Thu Mar 16 14:07:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxot-0000BI-18
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:07:35 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxor-0004zc-Nd
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:07:35 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxm1-000ML2-JS
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:04:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJxlz-000MKd-2W
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:04:35 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2GJ4XOj006732
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 14:04:33 -0500
Received: (qmail 27391 invoked from network); 16 Mar 2006 19:04:33 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 16 Mar 2006 19:04:33 -0000
Message-ID: <4419B73A.90104@andybierman.com>
Date: Thu, 16 Mar 2006 11:06:34 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <713043CE8B8E1348AF3C546DBE02C1B40762962B@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40762962B@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Sharon Chisholm wrote:
> hi
>
> Just to clarify, the options are the following?
>
> 1) Standards assignment < 1024
> 2) Informal assignment > 1023
> 3) Say nothing
>   

No -- this is about IANA port assignments.
Port numbers < 1024 are system port numers.
Usually, only privileged users (e.g., root) can run programs
related to protocols running on these port numbers.

> Sharon
>   

Andy

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Eliot Lear
> Sent: Thursday, March 16, 2006 11:53 AM
> To: Andy Bierman
> Cc: Phil Shafer; Wijnen, Bert (Bert); 'Margaret Wasserman (E-mail)';
> 'Netconf (E-mail)'; iana-drafts@icann.org; IANA
> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
> Standar d [I06-051127-0011]
>
>
> Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
> REASON TO MAKE THE PORT PRIVILEGED?!!
>
> 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 Thu Mar 16 14:09:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxqv-0001Gx-31
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:09:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxqt-00057P-Pg
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:09:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJxnW-000MZO-6M
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:06:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS,UPPERCASE_25_50 autolearn=no version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FJxnV-000MZB-PR
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:06:09 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by test-iport-1.cisco.com with ESMTP; 16 Mar 2006 11:06:08 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2GJ67Gv025144;
	Thu, 16 Mar 2006 11:06:07 -0800 (PST)
Received: from [171.71.249.189] (dhcp-171-71-249-189.cisco.com [171.71.249.189])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2GJ7RaA015207;
	Thu, 16 Mar 2006 11:07:27 -0800
Message-ID: <4419B721.7090805@cisco.com>
Date: Thu, 16 Mar 2006 11:06:09 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Phil Shafer <phil@juniper.net>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Margaret Wasserman (E-mail)'" <margaret@thingmagic.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>, iana-drafts@icann.org,
        IANA <iana@iana.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <200603160240.k2G2eAYE089433@idle.juniper.net> <4418D950.3090400@andybierman.com> <441997FE.5060103@cisco.com> <4419B62A.5090600@andybierman.com>
In-Reply-To: <4419B62A.5090600@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=264; t=1142536047; x=1142968247;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Evaluation=3A=20draft-ietf-netconf-ssh-05.txt=20to=20Proposed=20
	Standar=0A=20d=20[I06-051127-0011]
	|To:Andy=20Bierman=20<ietf@andybierman.com>;
	X=v=3Dmtcc.com=3B=20h=3DgP87ecBHkm7PjblNkkZD9SDRYGs=3D; b=cXIrgbOQmmUwKFNe3RSMfKXTPxQAcNB50jvgnEXtUJ9sSB4UdRWPBw6YDjC6+wnes4D/c4EE
	8cPYc7gOaiAiJOJjpoeq162IFRW7Qqs+oCpS1ssYGw7Ta6eXlH79S2Ath6XRISU3FdJ2c9Ceor0
	jYMdhu6QF1zKfSK6Jp/qcBq0=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

Andy Bierman wrote:
> Eliot Lear wrote:
>> Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
>> REASON TO MAKE THE PORT PRIVILEGED?!!
>>   
>
> I guess you feel strongly about it then?  ;-)

VERY coffee deprived this morning.

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 Thu Mar 16 14:22:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJy3k-0003Ou-9h
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:22:56 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJy3j-0005gQ-RR
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 14:22:56 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJy0W-000NdU-Oa
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:19:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [64.40.101.249] (helo=www.icesoft.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ted.goddard@icesoft.com>)
	id 1FJy0V-000Ncz-UD
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:19:35 +0000
Received: from [10.18.39.60] ([64.141.118.170])
	by www.icesoft.com (Kerio MailServer 6.1.2)
	(using TLSv1/SSLv3 with cipher RC4-SHA (128 bits))
	for netconf@ops.ietf.org;
	Thu, 16 Mar 2006 11:19:34 -0800
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <4419B73A.90104@andybierman.com>
References: <713043CE8B8E1348AF3C546DBE02C1B40762962B@zcarhxm2.corp.nortel.com> <4419B73A.90104@andybierman.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C434A244-7BF9-429F-B319-70B02E59559E@icesoft.com>
Content-Transfer-Encoding: 7bit
From: Ted Goddard <ted.goddard@icesoft.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Date: Thu, 16 Mar 2006 12:19:32 -0700
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
X-Mailer: Apple Mail (2.746.2)
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024


If ports <1024 are deemed appropriate for NETCONF
(I agree with Eliot; device configuration is as good as any reason
for a privileged port) NETCONF/SOAP/HTTP needs one port.

A port for SOAP over BEEP is already reserved, so it would be
reasonable to use this port for NETCONF/SOAP/BEEP:

soap-beep       605/tcp    SOAP over BEEP
soap-beep       605/udp    SOAP over BEEP

Ted.


On 16-Mar-06, at 12:06 PM, Andy Bierman wrote:

> Sharon Chisholm wrote:
>> hi
>>
>> Just to clarify, the options are the following?
>>
>> 1) Standards assignment < 1024
>> 2) Informal assignment > 1023
>> 3) Say nothing
>>
>
> No -- this is about IANA port assignments.
> Port numbers < 1024 are system port numers.
> Usually, only privileged users (e.g., root) can run programs
> related to protocols running on these port numbers.
>
>> Sharon
>>
>
> Andy
>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner- 
>> netconf@ops.ietf.org] On
>> Behalf Of Eliot Lear
>> Sent: Thursday, March 16, 2006 11:53 AM
>> To: Andy Bierman
>> Cc: Phil Shafer; Wijnen, Bert (Bert); 'Margaret Wasserman (E-mail)';
>> 'Netconf (E-mail)'; iana-drafts@icann.org; IANA
>> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
>> Standar d [I06-051127-0011]
>>
>>
>> Sorry- we are talking about CONFIGURATION OF THE DEVICE.  WHAT BETTER
>> REASON TO MAKE THE PORT PRIVILEGED?!!
>>
>> Eliot
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with  
>> the
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>>
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>



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



From owner-netconf@ops.ietf.org Thu Mar 16 15:07:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJylF-0007NY-C9
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 15:07:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJylE-0006w7-2y
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 15:07:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJyYB-0000ay-A5
	for netconf-data@psg.com; Thu, 16 Mar 2006 19:54:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FJyY2-0000Zw-Cs
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 19:54:14 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2GJsBT00518
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 14:54:11 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: netconf implementation guide
Date: Thu, 16 Mar 2006 14:54:04 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40762987A@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: netconf implementation guide
Thread-Index: AcYyth7xax4Hy2DHRHin+k/RytJNKAWfR3Xg
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

hi

Would these then be candidates for an updated Netconf RFC at a later
date?

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of y030737@njupt.edu.cn
Sent: Wednesday, February 15, 2006 11:31 PM
To: netconf@ops.ietf.org
Subject: RE: netconf implementation guide



I agree


> > Behalf Of Andy Bierman
> > Sent: Friday, February 10, 2006 4:51 PM
> > To: Netconf (E-mail)
> > Subject: netconf implementation guide
> >=20
> >=20
> > Hi,
> >=20
> > I think eventually we will keep collecting clarifications, maybe=20
> > even enough for a NETCONF Implementation Guide RFC.
> >=20
> > Are there any WG members willing to work on a
>



--
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 Thu Mar 16 15:54:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJzUN-0001OH-0h
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 15:54:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJzUM-0000Kj-N1
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 15:54:30 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FJzQl-0005Rm-Sk
	for netconf-data@psg.com; Thu, 16 Mar 2006 20:50:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FJzQk-0005RZ-Vl
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 20:50:47 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2GKFa4K022650
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 15:15:36 -0500
Received: (qmail 24825 invoked from network); 16 Mar 2006 20:15:36 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 16 Mar 2006 20:15:36 -0000
Message-ID: <4419C763.8070602@andybierman.com>
Date: Thu, 16 Mar 2006 12:15:31 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: netconf@ops.ietf.org
Subject: Re: netconf implementation guide
References: <713043CE8B8E1348AF3C546DBE02C1B40762987A@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40762987A@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

Sharon Chisholm wrote:
> hi
>
> Would these then be candidates for an updated Netconf RFC at a later
> date?
>   

Not in my opinion.
Implementation guides are usually informative, rather than normative.

Errata in the standard RFCs is something else entirely.

This doesn't even have to be an official WG activity.
Anybody can publish an Informational RFC (but you knew that).
I'm not sure how long it would take to collect enough info to
publish an RFC anyway.  I was thinking we would just collect
data for awhile on our WG WEB site that Simon maintains:

http://www.ops.ietf.org/netconf/

I think it will take a few more interoperability test events to
have enough implementations and variances in them to understand
what clarifications might be needed in the standard documents.

> Sharon
>   

Andy


> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of y030737@njupt.edu.cn
> Sent: Wednesday, February 15, 2006 11:31 PM
> To: netconf@ops.ietf.org
> Subject: RE: netconf implementation guide
>
>
>
> I agree
>
>
>   
>>> Behalf Of Andy Bierman
>>> Sent: Friday, February 10, 2006 4:51 PM
>>> To: Netconf (E-mail)
>>> Subject: netconf implementation guide
>>>
>>>
>>> Hi,
>>>
>>> I think eventually we will keep collecting clarifications, maybe 
>>> even enough for a NETCONF Implementation Guide RFC.
>>>
>>> Are there any WG members willing to work on a
>>>       
>
>
>
> --
> 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 Thu Mar 16 18:02:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK1Tz-0005Ol-8T
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 18:02:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK1Ty-00058b-Sg
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 18:02:15 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK1MF-000EoY-C6
	for netconf-data@psg.com; Thu, 16 Mar 2006 22:54:15 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <leinen@diotima.switch.ch>)
	id 1FK1MC-000Eo9-EN
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 22:54:12 +0000
Received: (from leinen@localhost)
	by diotima.switch.ch (8.13.5+Sun/8.13.5) id k2GMs1KD011708;
	Thu, 16 Mar 2006 23:54:01 +0100 (CET)
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Cc: "'Sharon Chisholm'" <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d
 [I06-051127-0011]
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: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com> (Ira
 McDonald's message of "Thu, 16 Mar 2006 11:03:23 -0800")
References: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com>
Date: Thu, 16 Mar 2006 23:54:01 +0100
Message-ID: <aaveue2e7q.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
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

McDonald, Ira writes:
> It is not possible to use NetConf (or SHOULD NOT be) without strong
> authentication - in any case, security professionals do NOT accept
> the pseudo-security of "well known ports" based on their numeric
> values.

Right, but using a <1024 port seems to be the convention for protocols
that talk with system-level entities - and a device's configuration
agent is certainly an example of one.  Therefore I think a port from
the well-known/system/privileged range is appropriate here.

I agree that "privileged" ports are a weak security mechanism.  But
then I don't understand why you are so worried about our contribution
to exhausting them.  Once the other 300 or so privileged ports will be
used up, people will simply be forced to abandon this weak security
concept (or try to reclaim old port assignments that have fallen out
of use, or open up another range of "privileged" ports).

In my personal experience, low port numbers seem to give security
admins a warmer and fuzzier feeling when you ask them to open ports in
their filters.  Therefore I think <1024 port would make NETCONF
deployment easier, if only slightly.
-- 
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 Thu Mar 16 18:04:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK1Vy-0000si-Oc
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 18:04:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK1Vy-0005Cb-FT
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 18:04:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK1Rs-000FOJ-G0
	for netconf-data@psg.com; Thu, 16 Mar 2006 23:00:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.69.195.72] (helo=pop-sarus.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FK1Rr-000FNo-OD
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 23:00:03 +0000
Received: from h-68-165-3-103.snvacaid.dynamic.covad.net ([68.165.3.103] helo=oemcomputer)
	by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FK1Rq-0001Gf-00
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 18:00:03 -0500
Message-ID: <007b01c6494d$b9aefc00$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Date: Thu, 16 Mar 2006 15:02:39 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Hi -

> From: "McDonald, Ira" <imcdonald@sharplabs.com>
> To: "'Sharon Chisholm'" <schishol@nortel.com>; "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Thursday, March 16, 2006 11:03 AM
> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
...
> (1) IANA-assigned "Well Known Port" (0 to 1023)
>     - approximately 70% are now assigned 
>     - very scarce resource
> 
> (2) IANA-assigned "Registered Port" (1024 to 49151)
>     - approximately %12 are now assigned 
>     - plentiful resource
> 
> (3) Unregistered "Dynamic or Private Port" (49152 to 65535)
>     - not a reasonable choice for NetConf or any standard service
> 
> Option (2) is obviously the prudent choide.

I strongly agree.

> It is not possible to use NetConf (or SHOULD NOT be) without
> strong authentication - in any case, security professionals
> do NOT accept the pseudo-security of "well known ports" based
> on their numeric values.
...

I find this rationale far more convincing than any of the
others put forth on this thread.

Randy


--
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 Mar 16 19:03:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK2Qz-0001Pq-Hh
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 19:03:13 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK2Qz-00080X-6s
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 19:03:13 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK2MX-000KtM-Ir
	for netconf-data@psg.com; Thu, 16 Mar 2006 23:58:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FK2MW-000Kt8-Ho
	for netconf@ops.ietf.org; Thu, 16 Mar 2006 23:58:36 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2GNwZDT025717
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 18:58:35 -0500
Received: (qmail 30651 invoked from network); 16 Mar 2006 23:58:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 16 Mar 2006 23:58:35 -0000
Message-ID: <4419FB84.9060003@andybierman.com>
Date: Thu, 16 Mar 2006 15:57:56 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com> <007b01c6494d$b9aefc00$6401a8c0@oemcomputer>
In-Reply-To: <007b01c6494d$b9aefc00$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

Randy Presuhn wrote:
> Hi -
>
>   
>> From: "McDonald, Ira" <imcdonald@sharplabs.com>
>> To: "'Sharon Chisholm'" <schishol@nortel.com>; "Netconf (E-mail)" <netconf@ops.ietf.org>
>> Sent: Thursday, March 16, 2006 11:03 AM
>> Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
>>     
> ...
>   
>> (1) IANA-assigned "Well Known Port" (0 to 1023)
>>     - approximately 70% are now assigned 
>>     - very scarce resource
>>
>> (2) IANA-assigned "Registered Port" (1024 to 49151)
>>     - approximately %12 are now assigned 
>>     - plentiful resource
>>
>> (3) Unregistered "Dynamic or Private Port" (49152 to 65535)
>>     - not a reasonable choice for NetConf or any standard service
>>
>> Option (2) is obviously the prudent choide.
>>     
>
> I strongly agree.
>
>   
>> It is not possible to use NetConf (or SHOULD NOT be) without
>> strong authentication - in any case, security professionals
>> do NOT accept the pseudo-security of "well known ports" based
>> on their numeric values.
>>     
> ...
>
> I find this rationale far more convincing than any of the
> others put forth on this thread.
>
>   

Let's leave security out of the argument for the moment.
At first, this is what made me think we didn't really need
a number < 1024.  Picking (2) out of spite just to make
a point that (1) is not strong enough security anyway
may not be the best choice.

Does the expected use of the protocol meet the criteria
for classifying it in the privileged system space?
When I looked at the problem this way,  I changed my mind.

The current  practice with CLI, HTML, and SMI based network management
protocols is to use privileged port numbers.  Why is NETCONF different?

> Randy
>
>   

Andy

> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 16 20:38:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK3um-0006UQ-9d
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 20:38:04 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK3uk-0002UR-0C
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 20:38:04 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK3qd-0002Qj-Hd
	for netconf-data@psg.com; Fri, 17 Mar 2006 01:33:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rpe@juniper.net>)
	id 1FK3qd-0002QX-06
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 01:33:47 +0000
Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126])
  by kremlin.juniper.net with ESMTP; 16 Mar 2006 17:33:46 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,103,1141632000"; 
   d="scan'208"; a="534224162:sNHT22221620"
Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 16 Mar 2006 17:33:46 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: transport mappings capability
Date: Thu, 16 Mar 2006 17:33:43 -0800
Message-ID: <B9247BD312AF424B92CA4A6B997779DA010A12EE@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: transport mappings capability
Thread-Index: AcZJLAAiSaygdhxiRLWEbYZdInex8wANo5Fg
From: "Rob Enns" <rpe@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Sharon Chisholm" <schishol@nortel.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 17 Mar 2006 01:33:46.0206 (UTC) FILETIME=[D55F67E0:01C64962]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

> > I guess your capability proposal is to solve the problem=20
> where I might
> > prefer to talk to you using another transport protocol. Having a
> > capability wouldn't hurt in this case, but this is more of=20
> a corner case
> > then being able to talk in the first place.
> >  =20
>=20
> There is no corner case.   It is just a need to discover all the
> mappings that an agent will support.
>=20
> A manager can always talk to an agent over the default mapping (SSH).
> The issue is whether a standard capability, standard data model,
> or proprietary mechanism be used to find out if any other mappings
> are supported. =20

I wonder if it would be used though. Would a manager connect to
an agent over SSH, discover that the agent supports SOAP, and go
back to use SOAP? Most deployments would know the connection
method by fiat.

Rob

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



From owner-netconf@ops.ietf.org Thu Mar 16 21:17:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK4Wz-0002Ph-Jp
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 21:17:33 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK4Wy-0003xi-9j
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 21:17:33 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK4SK-0005UL-2Z
	for netconf-data@psg.com; Fri, 17 Mar 2006 02:12:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FK4SJ-0005UA-88
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 02:12:43 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2H2CfkQ006163
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 21:12:41 -0500
Received: (qmail 7827 invoked from network); 17 Mar 2006 02:12:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 17 Mar 2006 02:12:41 -0000
Message-ID: <441A1ADF.3070607@andybierman.com>
Date: Thu, 16 Mar 2006 18:11:43 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Rob Enns <rpe@juniper.net>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: transport mappings capability
References: <B9247BD312AF424B92CA4A6B997779DA010A12EE@antitop.jnpr.net>
In-Reply-To: <B9247BD312AF424B92CA4A6B997779DA010A12EE@antitop.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

Rob Enns wrote:
>>> I guess your capability proposal is to solve the problem 
>>>       
>> where I might
>>     
>>> prefer to talk to you using another transport protocol. Having a
>>> capability wouldn't hurt in this case, but this is more of 
>>>       
>> a corner case
>>     
>>> then being able to talk in the first place.
>>>   
>>>       
>> There is no corner case.   It is just a need to discover all the
>> mappings that an agent will support.
>>
>> A manager can always talk to an agent over the default mapping (SSH).
>> The issue is whether a standard capability, standard data model,
>> or proprietary mechanism be used to find out if any other mappings
>> are supported.  
>>     
>
> I wonder if it would be used though. Would a manager connect to
> an agent over SSH, discover that the agent supports SOAP, and go
> back to use SOAP? Most deployments would know the connection
> method by fiat.
>   

The first decision is "should there be a standard mechanism for a manager to
discover the transport mappings that an agent is configured to use?"

If yes, then the next decision is "what mechanism?"

I think a standard data model is better than a capability.
Since we don't have any standard data models yet,
I suggested a capability, but a data model is the right choice.

This is really just "more configuration data" in the end.
A manager should be interested in the enabled transport mappings.
What if non-secure mappings (like SOAP/HTTP) are enabled
but should not be?  What if the configurable BEEP port has been changed
by one manager and now another manager can't talk to the agent over BEEP?

One could argue that since there are plenty of standard configuration
data models
more important than this one that don't exist either, there is little
urgency to
fix this particular problem.   (One would be right ;-)

> Rob
>   

Andy



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



From owner-netconf@ops.ietf.org Thu Mar 16 22:23:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK5Yf-0005Ye-SX
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 22:23:21 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK5Ye-0005pf-JR
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 22:23:21 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK5RU-0009li-Ac
	for netconf-data@psg.com; Fri, 17 Mar 2006 03:15:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rpe@juniper.net>)
	id 1FK5RT-0009lL-PL
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 03:15:55 +0000
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
  by borg.juniper.net with ESMTP; 16 Mar 2006 19:15:45 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,103,1141632000"; 
   d="scan'208"; a="537049383:sNHT24547432"
Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 16 Mar 2006 19:15:44 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Date: Thu, 16 Mar 2006 19:15:43 -0800
Message-ID: <B9247BD312AF424B92CA4A6B997779DA010A12FA@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Thread-Index: AcZJVckA+ysi7enLTLKaxXvwaXqn/wAGnXiw
From: "Rob Enns" <rpe@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 17 Mar 2006 03:15:44.0007 (UTC) FILETIME=[13DDC170:01C64971]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

> The current  practice with CLI, HTML, and SMI based network management
> protocols is to use privileged port numbers.  Why is NETCONF=20
> different?

My 2 cents: it's different because it's new, and the world has
changed since the time SNMP, TELNET, and SSH ports were assigned.=20
With cheap powerful networked computers available to anyone (vs. the
days=20
when multiuser networked machines were run by druids and locked=20
in a machine room) the distinction between <1024 and >1024 is=20
gone. Anyone can stick a computer on a network and open a port <1024.

So why burn a scarce port number when a non-scarce one is just as good?

(or, I agree with Ira)

Rob

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



From owner-netconf@ops.ietf.org Thu Mar 16 22:48:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK5ws-0004TL-OU
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 22:48:22 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK5ws-0006cb-EQ
	for netconf-archive@lists.ietf.org; Thu, 16 Mar 2006 22:48:22 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK5tM-000Bq5-TF
	for netconf-data@psg.com; Fri, 17 Mar 2006 03:44:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FK5tL-000Bpf-Np
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 03:44:44 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2H3ifOj013122
	for <netconf@ops.ietf.org>; Thu, 16 Mar 2006 22:44:42 -0500
Received: (qmail 4450 invoked from network); 17 Mar 2006 03:44:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 17 Mar 2006 03:44:41 -0000
Message-ID: <441A3061.3040201@andybierman.com>
Date: Thu, 16 Mar 2006 19:43:29 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Rob Enns <rpe@juniper.net>
CC: Randy Presuhn <randy_presuhn@mindspring.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <B9247BD312AF424B92CA4A6B997779DA010A12FA@antitop.jnpr.net>
In-Reply-To: <B9247BD312AF424B92CA4A6B997779DA010A12FA@antitop.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

Rob Enns wrote:
>> The current  practice with CLI, HTML, and SMI based network management
>> protocols is to use privileged port numbers.  Why is NETCONF 
>> different?
>>     
>
> My 2 cents: it's different because it's new, and the world has
> changed since the time SNMP, TELNET, and SSH ports were assigned. 
> With cheap powerful networked computers available to anyone (vs. the
> days 
> when multiuser networked machines were run by druids and locked 
> in a machine room) the distinction between <1024 and >1024 is 
> gone. Anyone can stick a computer on a network and open a port <1024.
>
> So why burn a scarce port number when a non-scarce one is just as good?
>
>   

By this logic, port numbers < 1024 aren't scarce anymore because there's
no reason to assign them anymore.   I agree with Eliot on his point
that configuration is a privileged activity, so saving the scarce port
numbers for something better isn't that compelling.


Early on, we decided that BEEP was going to be our mandatory-to-implement
transport because it has some perceived technical advantages (by some WG
members) over the other choices.  We ended up asking the NANOG list. 
The answer there, in no uncertain terms, was "change as few things at
once as possible, not as many things as possible".  So we have SSH as the
mandatory transport.

I am concerned that we are making the same sort of decision for 
operators here,
and we will be told later this is an unwanted change.

> (or, I agree with Ira)
>
> Rob
>   

Andy



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



From owner-netconf@ops.ietf.org Fri Mar 17 00:40:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FK7hd-0003fK-V4
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 00:40:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FK7hc-0001O2-M6
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 00:40:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FK7bw-000Jfv-FD
	for netconf-data@psg.com; Fri, 17 Mar 2006 05:34:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.69.195.67] (helo=pop-tawny.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FK7bv-000Jfh-5H
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 05:34:51 +0000
Received: from h-64-105-34-71.snvacaid.dynamic.covad.net ([64.105.34.71] helo=oemcomputer)
	by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FK7bu-0005cb-00
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 00:34:50 -0500
Message-ID: <001f01c64984$d9d28100$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com> <007b01c6494d$b9aefc00$6401a8c0@oemcomputer> <4419FB84.9060003@andybierman.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
Date: Thu, 16 Mar 2006 21:37:15 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hi -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Thursday, March 16, 2006 3:57 PM
> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
...
> The current  practice with CLI, HTML, and SMI based network management
> protocols is to use privileged port numbers.  Why is NETCONF different?
...

It isn't a legacy protocol.

But if folks think that using a particular port number will
improve security, or that using a number less that 1024
will simplify implementation or improve interoperability,
I don't care enough about this to keep arguing the point.

Randy


--
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 Mar 17 09:57:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGOR-00045B-Fq
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 09:57:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKGOQ-00018v-3U
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 09:57:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKGIO-0009TF-Qk
	for netconf-data@psg.com; Fri, 17 Mar 2006 14:51:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FKGIN-0009T3-OF
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 14:51:15 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2HEkrR13556
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 09:46:54 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Informal Issue summary for Netconf Notification
Date: Fri, 17 Mar 2006 09:51:10 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407683AF6@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Informal Issue summary for Netconf Notification
Thread-Index: AcZJ0jqIVSQ5trASSSy4sJG4CfBptw==
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

hi

Here is what I believe to be the current list of open issues against the
Netconf Event Notification draft, based on mailing list discussions.=20

1)	To <wrap> or not to <wrap>
This started out as an objection to the <rpc-one-way> tag. From
discussion on the mailing list, it seems that people are invested in the
analogy of the <rpc> tag to a traditional RPC, so keeping things as they
are was removed from the option list.  This leaves us with two:

A) Have a wrapper around the <notification> called something like
<one-way-message> which contains the message ID similar to the <rpc> tag
and also can appear in the same box in the Netconf Layer Picture.

B) Compress the two layers and move the message ID into the
<notification> and replace the Netconf Layer Picture with a more
complicated one that accurately shows this change in layers (Like the
one Andy suggested at one point).


2)	Endless reply versus subscription: seem to have consensus for
subscription

3)	Multiple-channel support: seem to have consensus to defer

4)	Need to verify mapping to application/transport protocols

Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

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



From owner-netconf@ops.ietf.org Fri Mar 17 11:12:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHYX-00047t-Hu
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:12:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHYW-0003zm-8q
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:12:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKHSM-000EYG-As
	for netconf-data@psg.com; Fri, 17 Mar 2006 16:05:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,PLING_PLING,SUBJ_ALL_CAPS autolearn=no version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKHSL-000EXn-Hp
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 16:05:37 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2HG5aOj012732
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 11:05:36 -0500
Received: (qmail 19370 invoked from network); 17 Mar 2006 16:05:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 17 Mar 2006 16:05:35 -0000
Message-ID: <441ADDD4.4060602@andybierman.com>
Date: Fri, 17 Mar 2006 08:03:32 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: PLEASE READ THE NOTIFICATIONS DRAFT!!!
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Hi,

There has not been much discussion of the Notifications draft
on the mailing list.  We need people to read it and send
comments.  Could someone implement NETCONF Notifications
from scratch, just from reading this document?



thanks,
Andy



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



From owner-netconf@ops.ietf.org Fri Mar 17 11:18:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHf9-0000TL-Mo
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:18:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHf8-0004J6-Bv
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:18:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKHYf-000F1P-1x
	for netconf-data@psg.com; Fri, 17 Mar 2006 16:12:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKHYe-000F16-7s
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 16:12:08 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2HGC64K011780
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 11:12:07 -0500
Received: (qmail 30040 invoked from network); 17 Mar 2006 16:12:06 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 17 Mar 2006 16:12:06 -0000
Message-ID: <441ADF5A.90506@andybierman.com>
Date: Fri, 17 Mar 2006 08:10:02 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FA9@mailsrvnt02.enet.sharplabs.com> <007b01c6494d$b9aefc00$6401a8c0@oemcomputer> <4419FB84.9060003@andybierman.com> <001f01c64984$d9d28100$6401a8c0@oemcomputer>
In-Reply-To: <001f01c64984$d9d28100$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Randy Presuhn wrote:
> Hi -
>
>   
>> From: "Andy Bierman" <ietf@andybierman.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
>> Sent: Thursday, March 16, 2006 3:57 PM
>> Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]
>>     
> ...
>   
>> The current  practice with CLI, HTML, and SMI based network management
>> protocols is to use privileged port numbers.  Why is NETCONF different?
>>     
> ...
>
> It isn't a legacy protocol.
>   

Try telling operators that SSH, HTTP, and SNMP are legacy protocols.
This is pretty much all that's out there.


> But if folks think that using a particular port number will
> improve security, or that using a number less that 1024
> will simplify implementation or improve interoperability,
> I don't care enough about this to keep arguing the point.
>   

We don't think we are improving security.
It is about following current practice, 'best' or otherwise.
IMO, there is a strong pre-existing expectation that a configuration
protocol like NETCONF should be in the system port number range.


> Randy
>   

Andy

>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Mar 17 11:39:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHzC-0006i2-0o
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:39:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHzA-0004yX-LA
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 11:39:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKHui-000Gau-GS
	for netconf-data@psg.com; Fri, 17 Mar 2006 16:34:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [192.147.142.39] (helo=seymour39.snmp.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <moulton@snmp.com>)
	id 1FKHuh-000Gah-90
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 16:34:55 +0000
Received: from ws4.snmp.com (seymour78.snmp.com [192.147.142.78])
	by seymour39.snmp.com (8.9.3p2-20030922/m.090605) with ESMTP id LAA15706;
	Fri, 17 Mar 2006 11:34:52 -0500 (EST)
Received: from ws4.snmp.com (ws4.snmp.com [192.147.142.78])
	by ws4.snmp.com (8.13.1/8.13.1) with ESMTP id k2HGYpSl029200;
	Fri, 17 Mar 2006 11:34:51 -0500
Message-Id: <200603171634.k2HGYpSl029200@ws4.snmp.com>
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1-RC3
To: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011] 
In-reply-to: Your message of Fri, 17 Mar 2006 08:10:02 -0800.
             <441ADF5A.90506@andybierman.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 17 Mar 2006 11:34:51 -0500
From: Steve Moulton <moulton@snmp.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1



On Friday, March 17 2006, Andy Bierman <ietf@andybierman.com> wrote:


> We don't think we are improving security.
> It is about following current practice, 'best' or otherwise.
> IMO, there is a strong pre-existing expectation that a configuration
> protocol like NETCONF should be in the system port number range.

As far as I can tell, the only security implication one way or the
other is whether non-netconf (i.e., other user) applications can
bind to the port, possibly preempting use by netconf (even though
the netconf service is likely to start before user applications).  
On unix-like systems, port numbers below 1024 enforce this.  
On non-unix-like systems, this argument may not hold.

If there is a difference wrt authentication, I don't see it (but my
security glasses are, at best, astigmatic).  

So, to my understanding, there are two arguments for reserving
a port below 1024:  preempting user processes, and pre-existing
expectation as noted by Andy.  It is not clear to me that
those at IANA who gatekeep such things will find these sufficiently
strong arguments.


---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton at snmp.com  Knoxville, TN 37920-9716 USA  http://www.snmp.com



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



From owner-netconf@ops.ietf.org Fri Mar 17 13:00:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKJFs-00029O-E4
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 13:00:52 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKIxR-00072T-8I
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 12:41:49 -0500
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FKIiZ-0000td-8X
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 12:26:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKIcl-000K7x-9c
	for netconf-data@psg.com; Fri, 17 Mar 2006 17:20:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKIcj-000K7f-SF
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 17:20:26 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2HGwMDT022198
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 11:58:22 -0500
Received: (qmail 27418 invoked from network); 17 Mar 2006 16:58:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 17 Mar 2006 16:58:22 -0000
Message-ID: <441AEA32.3040203@andybierman.com>
Date: Fri, 17 Mar 2006 08:56:18 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Steve Moulton <moulton@snmp.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
 d [I06-051127-0011]
References: <200603171634.k2HGYpSl029200@ws4.snmp.com>
In-Reply-To: <200603171634.k2HGYpSl029200@ws4.snmp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

Steve Moulton wrote:
> On Friday, March 17 2006, Andy Bierman <ietf@andybierman.com> wrote:
>
>
>   
>> We don't think we are improving security.
>> It is about following current practice, 'best' or otherwise.
>> IMO, there is a strong pre-existing expectation that a configuration
>> protocol like NETCONF should be in the system port number range.
>>     
>
> As far as I can tell, the only security implication one way or the
> other is whether non-netconf (i.e., other user) applications can
> bind to the port, possibly preempting use by netconf (even though
> the netconf service is likely to start before user applications).  
> On unix-like systems, port numbers below 1024 enforce this.  
> On non-unix-like systems, this argument may not hold.
>
> If there is a difference wrt authentication, I don't see it (but my
> security glasses are, at best, astigmatic).  
>
> So, to my understanding, there are two arguments for reserving
> a port below 1024:  preempting user processes, and pre-existing
> expectation as noted by Andy.  It is not clear to me that
> those at IANA who gatekeep such things will find these sufficiently
> strong arguments.
>   

Well they should -- just follow the logic:

1) It doesn't matter what the port number is
2) Port numbers <1024 are not important, and therefore not scarce
3) Use a >1024 number anyway to preserve this relatively scarce 
resource  (?)

OR

1) It doesn't matter what the port number is, except on unix implementations
2) Use a <1024 number, since their relative scarcity is irrelevant,
   and it will help unix implementations prevent hackers from easily 
spoofing
   the netconf agent.


>
> ---
> Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
> Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
> moulton at snmp.com  Knoxville, TN 37920-9716 USA  http://www.snmp.com
>
>
>   

Andy



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



From owner-netconf@ops.ietf.org Fri Mar 17 14:58:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKL5t-0006Yk-Ut
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 14:58:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKL5s-0003K2-IR
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 14:58:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKKxt-0007po-7f
	for netconf-data@psg.com; Fri, 17 Mar 2006 19:50:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKKxq-0007ok-D2
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 19:50:22 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2HJo6UX012115;
	Fri, 17 Mar 2006 11:50:10 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYY2VD>; Fri, 17 Mar 2006 11:50:07 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FB3@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011] 
Date: Fri, 17 Mar 2006 11:50:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

Steve Moulton wrote:
> 
> On Friday, March 17 2006, Andy Bierman <ietf@andybierman.com> wrote: 
> 
> > We don't think we are improving security.
> > It is about following current practice, 'best' or otherwise.
> > IMO, there is a strong pre-existing expectation that a configuration
> > protocol like NETCONF should be in the system port number range.
> 
> As far as I can tell, the only security implication one way or the
> other is whether non-netconf (i.e., other user) applications can
> bind to the port, possibly preempting use by netconf (even though
> the netconf service is likely to start before user applications).  
> On unix-like systems, port numbers below 1024 enforce this.  
> On non-unix-like systems, this argument may not hold.
> 
> If there is a difference wrt authentication, I don't see it (but my
> security glasses are, at best, astigmatic).  
> 
> So, to my understanding, there are two arguments for reserving
> a port below 1024:  preempting user processes, and pre-existing
> expectation as noted by Andy.  It is not clear to me that
> those at IANA who gatekeep such things will find these sufficiently
> strong arguments.
> 

Netconf is at best a 'niche' protocol at present, because:

(a) Netconf currently has no standard data models

(b) Netconf currently is intended for use only with routers and
    other intermediate network elements

(c) Netconf operations have fuzzy semantics, due to the lack of any
    standard data models (e.g., "merge this blob with that blob")

Therefore, Netconf in not plausibly a critical system service.

An IANA-assigned "Registered Port" (greater than 1024) is appropriate.

The argument that user processes may pre-bind the Netconf port applies
equally to an IANA-assigned "Well Known Port" (less than 1024).

I encourage the IETF ADs to intervene here and provide direction.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

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



From owner-netconf@ops.ietf.org Fri Mar 17 16:08:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMBP-0005qE-5x
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:08:27 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMBO-0005oN-Sp
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:08:27 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKM63-000CQy-UF
	for netconf-data@psg.com; Fri, 17 Mar 2006 21:02:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKM5z-000COm-OW
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 21:02:51 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by test-iport-1.cisco.com with ESMTP; 17 Mar 2006 13:02:30 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2HL2U7T009456;
	Fri, 17 Mar 2006 13:02:30 -0800 (PST)
Received: from [171.71.249.227] (dhcp-171-71-249-227.cisco.com [171.71.249.227])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2HL3jmT025476;
	Fri, 17 Mar 2006 13:03:45 -0800
Message-ID: <441B23E7.4040607@cisco.com>
Date: Fri, 17 Mar 2006 13:02:31 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
  d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FB3@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FB3@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=761; t=1142629425; x=1143061625;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Evaluation=3A=20draft-ietf-netconf-ssh-05.txt=20to=20Proposed=20
	Standar=0A=20=20d=20[I06-051127-0011]
	|To:=22McDonald,=20Ira=22=20<imcdonald@sharplabs.com>;
	X=v=3Dmtcc.com=3B=20h=3DbVTFLcqWsNZTXl8z84+t+0bhdCQ=3D; b=QO+fYPWT/2ZA/03tapZApfIWHkbKZKSS33WuZdhSNPaVXMIlp+kHPhj8+vTsrUsqMkdvM4GY
	PMLg74lcY8q4WBIcLzfX5f7VV1jxaCcREbg0uiXPqgiLc2XIxAZhRNE1at3EEmxvwaq/qARAWBX
	V98ByndbqirLwCqQWa17vJig=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

McDonald, Ira wrote:
> Netconf is at best a 'niche' protocol at present, because:
>
> (a) Netconf currently has no standard data models
>   

This has no bearing on the protocol.  We're not going to change ports
if/when this problem is solved.
> (b) Netconf currently is intended for use only with routers and
>     other intermediate network elements
>   

So what?
> (c) Netconf operations have fuzzy semantics, due to the lack of any
>     standard data models (e.g., "merge this blob with that blob")
>   

This is the same as (a).

> Therefore, Netconf in not plausibly a critical system service.
>   

That doesn't follow.  If device config gets shoved around it's a
critical system service - there are few more critical.

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 Mar 17 16:40:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMgt-0000no-Dh
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:40:59 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMgs-0006Wc-4y
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:40:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKMdJ-000Elk-KV
	for netconf-data@psg.com; Fri, 17 Mar 2006 21:37:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0
Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FKMdI-000ElY-Dj
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 21:37:17 +0000
Received: from h-64-105-35-147.snvacaid.dynamic.covad.net ([64.105.35.147] helo=oemcomputer)
	by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FKMdH-0002HH-00
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 16:37:15 -0500
Message-ID: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "netconf" <netconf@ops.ietf.org>
Subject: use of netconf to configure Unix systems
Date: Fri, 17 Mar 2006 13:39:42 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

Hi -

I'm intrigued by the concern that netconf should be assigned a Unix privileged port.
Does this mean that someone has or is developing a netconf data model to configure
Unix hosts or applications?  Are there other reasons for running a netconf server
on a Unix host?

Randy


--
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 Mar 17 16:45:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMl3-000268-9m
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:45:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMl2-0006Z1-0V
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:45:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKMhy-000FAv-Rq
	for netconf-data@psg.com; Fri, 17 Mar 2006 21:42:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKMhy-000FAU-9D
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 21:42:06 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2HLfxk3016194;
	Fri, 17 Mar 2006 13:41:59 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYYLPA>; Fri, 17 Mar 2006 13:41:59 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FB6@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Eliot Lear'" <lear@cisco.com>,
        "McDonald, Ira"
	 <imcdonald@sharplabs.com>
Cc: "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011]
Date: Fri, 17 Mar 2006 13:41:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465


Eliot Lear wrote:
> 
> McDonald, Ira wrote:
> > Netconf is at best a 'niche' protocol at present, because:
> >
> > (a) Netconf currently has no standard data models
> >   
> 
> This has no bearing on the protocol.  We're not going to change ports
> if/when this problem is solved.
> > (b) Netconf currently is intended for use only with routers and
> >     other intermediate network elements
> >   
> 
> So what?
> > (c) Netconf operations have fuzzy semantics, due to the lack of any
> >     standard data models (e.g., "merge this blob with that blob")
> >   
> 
> This is the same as (a).
> 
> > Therefore, Netconf in not plausibly a critical system service.
> >   
> 
> That doesn't follow.  If device config gets shoved around it's a
> critical system service - there are few more critical.

Hi Eliot,

If Netconf is not a _ubiquitous_ general replacement for SNMP
and other legacy configuration protocols for ALL network
elements, then it's not a critical system service - period.

Using IANA-assigned "Well Known Ports" is a political vanity
issue - not a technical issue.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

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



From owner-netconf@ops.ietf.org Fri Mar 17 16:47:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMmz-0005AG-Df
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:47:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMmy-0006ay-4P
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:47:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKMjK-000FIS-7g
	for netconf-data@psg.com; Fri, 17 Mar 2006 21:43:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKMjJ-000FIH-QC
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 21:43:29 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-1.cisco.com with ESMTP; 17 Mar 2006 13:43:29 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2HLhT7T004954;
	Fri, 17 Mar 2006 13:43:29 -0800 (PST)
Received: from [171.71.249.227] (dhcp-171-71-249-227.cisco.com [171.71.249.227])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2HLiiwE025834;
	Fri, 17 Mar 2006 13:44:44 -0800
Message-ID: <441B2D83.1030909@cisco.com>
Date: Fri, 17 Mar 2006 13:43:31 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
In-Reply-To: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=436; t=1142631884; x=1143064084;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20use=20of=20netconf=20to=20configure=20Unix=20systems
	|To:Randy=20Presuhn=20<randy_presuhn@mindspring.com>;
	X=v=3Dmtcc.com=3B=20h=3DygcNeoDMEeqT+9FA5Vv5YzqF4Mk=3D; b=bJTXubwOAd4XdHIhWbLyqgRLDjz+L4DiedlTGnPR209D6/jCH1EoOZpemcQfjL2UeVYQ0eu9
	IVYNon6cb6U7AVEz1O6iQV/yH9HBEqTZSWYxlJ5BSonq6Zq1M9zdp9WmDQhe9Gjg3u2ZSzBsDYx
	u7XLcOFBCPuSSaHMTkvkDx1w=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Certainly NETCONF has been implemented on devices that run UNIX, and I'm
sure we can expect more of that.

Eliot

Randy Presuhn wrote:
> Hi -
>
> I'm intrigued by the concern that netconf should be assigned a Unix privileged port.
> Does this mean that someone has or is developing a netconf data model to configure
> Unix hosts or applications?  Are there other reasons for running a netconf server
> on a Unix host?
>   

--
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 Mar 17 16:51:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMqi-0008Fi-J5
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:51:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMqh-0006eh-9I
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 16:51:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKMn7-000Fjb-IX
	for netconf-data@psg.com; Fri, 17 Mar 2006 21:47:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKMn7-000FjF-3L
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 21:47:25 +0000
Received: from sj-core-3.cisco.com ([171.68.223.137])
  by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 13:47:25 -0800
X-IronPort-AV: i="4.03,105,1141632000"; 
   d="scan'208"; a="1785993963:sNHT30979368"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2HLlO1j019112;
	Fri, 17 Mar 2006 13:47:24 -0800 (PST)
Received: from [171.71.249.227] (dhcp-171-71-249-227.cisco.com [171.71.249.227])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2HLmdU0025867;
	Fri, 17 Mar 2006 13:48:39 -0800
Message-ID: <441B2E6E.90701@cisco.com>
Date: Fri, 17 Mar 2006 13:47:26 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
  d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FB6@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FB6@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=776; t=1142632120; x=1143064320;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Evaluation=3A=20draft-ietf-netconf-ssh-05.txt=20to=20Proposed=20
	Standar=0A=20=20d=20[I06-051127-0011]
	|To:=22McDonald,=20Ira=22=20<imcdonald@sharplabs.com>;
	X=v=3Dmtcc.com=3B=20h=3D29zb58YzKM+1fe/6jf4Q0I6QdU0=3D; b=dKbpoRP5J3T0G3l4ts8+uTS3ZBbtYvrfTy5W6o7PxmMd5ffdL9p52ao/G19BCOJGFrfGNitC
	Eink4eBGwZ1QxbwzodGQhUFscRurM/2asibHSQKxMzFPqEse6ImJLwq8Y7VD/53EN3EgeDf1dOk
	OAYQ2CvKHNsUCa2x+Mlqb3pE=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

Ira,
> If Netconf is not a _ubiquitous_ general replacement for SNMP
> and other legacy configuration protocols for ALL network
> elements, then it's not a critical system service - period.
>   
SNMP didn't start as a ubiquitous replacement for anything.  It's a
mistake to make this decision based on popularity.  The question in my
opinion is ONLY a matter of who can bind the port and what impact it can
have.  Now, arguably one could argue that if you get your process
initiation order correct, this isn't a problem.  On the other hand, if a
process can be killed, then the problem recurs.  This to me is the
technical issue.  It's not a political vanity.  If we were talking
about, oh, say, the "talk" or "finger" protocols, I'd feel differently...

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 Mar 17 17:13:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNCo-00081d-PU
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:13:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNCm-0007d9-G4
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:13:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKN8v-000Hiv-1v
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:09:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <leinen@diotima.switch.ch>)
	id 1FKN8u-000Hia-1N
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:09:56 +0000
Received: (from leinen@localhost)
	by diotima.switch.ch (8.13.5+Sun/8.13.5) id k2HM9p3x016761;
	Fri, 17 Mar 2006 23:09:51 +0100 (CET)
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: "netconf" <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
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: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer> (Randy Presuhn's
 message of "Fri, 17 Mar 2006 13:39:42 -0800")
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
Date: Fri, 17 Mar 2006 23:09:51 +0100
Message-ID: <aa1wx0k9jk.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
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

Randy Presuhn writes:
> I'm intrigued by the concern that netconf should be assigned a Unix
> privileged port.

The IANA terminology is "well known port number", and a comment in the
IANA port-numbers file says they "... on most systems can only be used
by system (or root) processes or by programs executed by privileged
users." So I wouldn't be too fixated on Unix - although I'm not
familiar with how non-Unix systems actually handle this.  Whatever.

> Does this mean that someone has or is developing a netconf data
> model to configure Unix hosts or applications?

Not in their entirety, as far as I know, but YencaP is an example of a
NETCONF server implementation that runs on Unix hosts and provides
configuration access to some applications, in particular Zebra's BGP
daemon.

Note also that not all Unix-based systems are hosts in the classical
sense, many routers and other appliances are also based on Unix
(Juniper's are just one example).

> Are there other reasons for running a netconf server on a Unix host?

I can think of plenty.  I guess many vendors of Unix-based appliances
want to hide the traditional Unix way of configuring things
(a maze of twisty config files under /etc, all in different formats).
-- 
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 Mar 17 17:15:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNDx-0000Zy-Uh
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:15:09 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNDv-0007fY-AF
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:15:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNAE-000Hsh-BQ
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:11:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.194.124.237] (helo=execdsl.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKNAD-000HsQ-M4
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:11:17 +0000
Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com)
  by execdsl.com (CommuniGate Pro SMTP 4.2.7)
  with ESMTP id 13106281; Fri, 17 Mar 2006 15:11:13 -0700
Message-Id: <7.0.1.0.0.20060317170613.0329d9b8@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 17 Mar 2006 17:11:16 -0500
To: Eliot Lear <lear@cisco.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed
  Standar d [I06-051127-0011]
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
In-Reply-To: <441B2E6E.90701@cisco.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FB6@mailsrvnt02.enet.sharplabs.com>
 <441B2E6E.90701@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

This seems to argue that any service that needs to be assigned a port 
number must be using a port number <1024. (After all, if it didn't, 
anyone could grab that port.)
As a matter of widely accepted practice, that is no longer the 
case.  For example, SIP servers (and proxies) use ports above 
1024.  In fact, if you look at the IANA registries, many, many, 
protocols use well known ports above 1024.
I can not see any reason that NetConf is any more special than a lot 
of those protocols.
So why should netconf demand a port less than 1024.

(As far as I can tell, the distinction between <1024 and >1024 ought 
to be removed.  There is nothing the IETF is defining that benefits 
from that distinct.  that abolition is enhanced if we stop trying to 
make special use of <1024 port.  If that were my only reason, or even 
the most important reason, I wouldn't bother sending this.)

Yours,
Joel M. Halpern

At 04:47 PM 3/17/2006, Eliot Lear wrote:
>Ira,
> > If Netconf is not a _ubiquitous_ general replacement for SNMP
> > and other legacy configuration protocols for ALL network
> > elements, then it's not a critical system service - period.
> >
>SNMP didn't start as a ubiquitous replacement for anything.  It's a
>mistake to make this decision based on popularity.  The question in my
>opinion is ONLY a matter of who can bind the port and what impact it can
>have.  Now, arguably one could argue that if you get your process
>initiation order correct, this isn't a problem.  On the other hand, if a
>process can be killed, then the problem recurs.  This to me is the
>technical issue.  It's not a political vanity.  If we were talking
>about, oh, say, the "talk" or "finger" protocols, I'd feel differently...
>
>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 Mar 17 17:24:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNMX-0007fd-OO
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:24:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNMW-0007zY-Fd
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:24:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNJS-000Ifg-0J
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:20:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKNJR-000IfD-Gk
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:20:49 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2HMKaKa017519;
	Fri, 17 Mar 2006 14:20:36 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYYMN9>; Fri, 17 Mar 2006 14:20:36 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FB8@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Eliot Lear'" <lear@cisco.com>,
        "McDonald, Ira"
	 <imcdonald@sharplabs.com>
Cc: "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011]
Date: Fri, 17 Mar 2006 14:20:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b


Eliot Lear wrote:
> 
> 
> Ira,
> > If Netconf is not a _ubiquitous_ general replacement for SNMP
> > and other legacy configuration protocols for ALL network
> > elements, then it's not a critical system service - period.
> >   
> SNMP didn't start as a ubiquitous replacement for anything.  It's a
> mistake to make this decision based on popularity.  The question in my
> opinion is ONLY a matter of who can bind the port and what 
> impact it can
> have.  Now, arguably one could argue that if you get your process
> initiation order correct, this isn't a problem.  On the other 
> hand, if a
> process can be killed, then the problem recurs.  This to me is the
> technical issue.  It's not a political vanity.  If we were talking
> about, oh, say, the "talk" or "finger" protocols, I'd feel 
> differently...

Security through low-numbered ports is non-existent - this is old
thinking that certainly isn't reflected in many operating systems.
Security of local processes is NOT based on port numbers.

I stand by my 'political vanity issue' comment.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

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



From owner-netconf@ops.ietf.org Fri Mar 17 17:28:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNR5-0008Pb-07
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:28:43 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNR3-000863-Ik
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:28:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNO0-000J31-Jo
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:25:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [209.124.89.132] (helo=uncasville.krupczak.org)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rdk@krupczak.org>)
	id 1FKNNz-000J2h-O7
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:25:31 +0000
Received: by uncasville.krupczak.org (Postfix, from userid 6169)
	id 092DD3845B; Fri, 17 Mar 2006 17:25:30 -0500 (EST)
Date: Fri, 17 Mar 2006 17:25:30 -0500
From: Bobby Krupczak <rdk@krupczak.org>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
Message-ID: <20060317222530.GA14159@uncasville.krupczak.org>
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
User-Agent: Mutt/1.4i
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hi!

> I'm intrigued by the concern that netconf should be assigned a Unix
> privileged port. 
> Does this mean that someone has or is developing a netconf data
> model to configure Unix hosts or applications?  Are there other
> reasons for running a netconf server on a Unix host?

I have been following netconf with the idea of borrowing much of it
for management/monitoring/configuring of operating-systems and
applications.  [I was originally drawn to netconf because of the
potential for event propagation.]

It dont think it needs to have a privileged port for either platforms
(e.g. windows or unix) to play that roll since (hopefully)
non-administrator/non-root users should not be able to change
configuration without the apporopriate underlying permissions.

Also, is the privileged port space becoming scarce?

Bobby

--
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 Mar 17 17:41:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNdL-0003ZB-D2
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:41:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNdL-0008FY-3e
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:41:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNZY-000Jsj-ES
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:37:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKNZX-000JsW-Si
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:37:27 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-2.cisco.com with ESMTP; 17 Mar 2006 14:37:28 -0800
X-IronPort-AV: i="4.03,106,1141632000"; 
   d="scan'208"; a="315630563:sNHT25512660"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2HMbR7T009349;
	Fri, 17 Mar 2006 14:37:27 -0800 (PST)
Received: from [171.71.201.9] (dhcp-171-71-201-9.cisco.com [171.71.201.9])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2HMcgfk026292;
	Fri, 17 Mar 2006 14:38:42 -0800
Message-ID: <441B3A28.6040005@cisco.com>
Date: Fri, 17 Mar 2006 14:37:28 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed  Standar
 d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FB6@mailsrvnt02.enet.sharplabs.com> <441B2E6E.90701@cisco.com> <7.0.1.0.0.20060317170613.0329d9b8@stevecrocker.com>
In-Reply-To: <7.0.1.0.0.20060317170613.0329d9b8@stevecrocker.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=952; t=1142635122; x=1143067322;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Evaluation=3A=20draft-ietf-netconf-ssh-05.txt=20to=20Proposed=20
	=20Standar=0A=20d=20[I06-051127-0011]
	|To:=22Joel=20M.=20Halpern=22=20<joel@stevecrocker.com>;
	X=v=3Dmtcc.com=3B=20h=3D9KYRUoswyx0ogsidguIgaj1GZGo=3D; b=BKByGDCnI+e/rliAecMBpIdKtlnfIWY89JmJOsZWFiBT0xCoTFIrY/CoFSNRVRL9ttsdYyQl
	0pL2wGK1D38ld+3fJ3n243OKO7IwJ6sRXSp277nlOKuCuYCNDE8Ikf7zTOrrjZxwQXVaRJ0nW2q
	ys5tGl+ytRys5GmRtvkGAalU=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

Joel,
> (As far as I can tell, the distinction between <1024 and >1024 ought
> to be removed.  There is nothing the IETF is defining that benefits
> from that distinct.  that abolition is enhanced if we stop trying to
> make special use of <1024 port.  If that were my only reason, or even
> the most important reason, I wouldn't bother sending this.)
I think your parenthetical comment is perhaps the one worth discussing. 
I don't think we would care if we were talking about a finger server,
which sits on port 79 or a UNIX talk server, which seemingly on its own
gobbles up more ports than NETCONF.  So far as I can tell, the only
difference is for those operating systems that want to provide a small
amount of protection against non-privileged process access.  Arguably
that's an implementation issue and really ought not be the subject of
standardization.

Given that it exists, when SHOULD something be assigned <1024?

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 Mar 17 17:45:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNhH-000745-0O
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:45:27 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNhF-0008J9-M0
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 17:45:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNdW-000KDu-IR
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:41:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKNdV-000KDh-K7
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:41:33 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2HMfWQ3003039
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 17:41:32 -0500
Received: (qmail 11967 invoked from network); 17 Mar 2006 22:41:31 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr4.mgt.bos.netsol.com with SMTP; 17 Mar 2006 22:41:31 -0000
Message-ID: <441B3B34.2000101@andybierman.com>
Date: Fri, 17 Mar 2006 14:41:56 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Eliot Lear'" <lear@cisco.com>, "'Steve Moulton'" <moulton@snmp.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
  d [I06-051127-0011]
References: <CFEE79A465B35C4385389BA5866BEDF00C7FB8@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FB8@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

McDonald, Ira wrote:
> Eliot Lear wrote:
>   
>> Ira,
>>     
>>> If Netconf is not a _ubiquitous_ general replacement for SNMP
>>> and other legacy configuration protocols for ALL network
>>> elements, then it's not a critical system service - period.
>>>   
>>>       
>> SNMP didn't start as a ubiquitous replacement for anything.  It's a
>> mistake to make this decision based on popularity.  The question in my
>> opinion is ONLY a matter of who can bind the port and what 
>> impact it can
>> have.  Now, arguably one could argue that if you get your process
>> initiation order correct, this isn't a problem.  On the other 
>> hand, if a
>> process can be killed, then the problem recurs.  This to me is the
>> technical issue.  It's not a political vanity.  If we were talking
>> about, oh, say, the "talk" or "finger" protocols, I'd feel 
>> differently...
>>     
>
> Security through low-numbered ports is non-existent - this is old
> thinking that certainly isn't reflected in many operating systems.
> Security of local processes is NOT based on port numbers.
>
> I stand by my 'political vanity issue' comment.
>   

I agree with Eliot.
This is a technical issue for unix implementations.
Even if a root process starts up on the netconf port,
it is less secure if this port number is not a system port.

Instead of gaining access as 'root' to masquerade as the
netconf agent, I just have to make the real agent crash,
then rebind to the >1024 port as a plain user.  This is weaker security
then forcing a hacker to gain access as 'root' before doing damage.

I don't think your argument that NETCONF "as of today"
is not widely used, and so is not  "well known" is irrelevant.
Few (if any) protocols are in wide use before they are assigned port 
numbers by IANA. 

Since it doesn't matter to you what the port number is,
but it does matter to a unix developer, why not put it in
the system range?  Since the "system range" is pointless
in your view, what does it matter if we use up 3 of the 320 or so
remaining numbers?

As Eliot pointed out,  what activities do you foresee more
privileged than device configuration, which should get the
remaining 30% of the system numbers?




> Cheers,
> - Ira
>   

Andy


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



From owner-netconf@ops.ietf.org Fri Mar 17 18:00:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKNvy-0003qO-LP
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 18:00:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKNvx-0000E2-Bp
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 18:00:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKNq7-000LDj-3F
	for netconf-data@psg.com; Fri, 17 Mar 2006 22:54:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKNq6-000LDV-9A
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 22:54:34 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2HMsXhB023345
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 17:54:33 -0500
Received: (qmail 24292 invoked from network); 17 Mar 2006 22:54:32 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 17 Mar 2006 22:54:32 -0000
Message-ID: <441B3E43.9070104@andybierman.com>
Date: Fri, 17 Mar 2006 14:54:59 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
In-Reply-To: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

Randy Presuhn wrote:
> Hi -
>
> I'm intrigued by the concern that netconf should be assigned a Unix privileged port.
> Does this mean that someone has or is developing a netconf data model to configure
> Unix hosts or applications?  Are there other reasons for running a netconf server
> on a Unix host?
>   

Perhaps somebody is already implementing a "NETCONF to Unix Config file" 
gateway,
running on Fedora4.  Netconf for unix is a very real possibility.


> Randy
>
>   

Andy


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



From owner-netconf@ops.ietf.org Fri Mar 17 19:03:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKOuw-0007rz-1Y
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:03:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKOuu-0003K6-IP
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:03:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKOpL-000PrE-E2
	for netconf-data@psg.com; Fri, 17 Mar 2006 23:57:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKOpK-000Pqy-Pz
	for netconf@ops.ietf.org; Fri, 17 Mar 2006 23:57:50 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2HNvYkr020952;
	Fri, 17 Mar 2006 15:57:39 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYY39L>; Fri, 17 Mar 2006 15:57:35 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
        Randy Presuhn
	 <randy_presuhn@mindspring.com>
Cc: netconf <netconf@ops.ietf.org>
Subject: RE: use of netconf to configure Unix systems
Date: Fri, 17 Mar 2006 15:57:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="UTF-8"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465


Andy Bierman wrote:
> 
> 
> Randy Presuhn wrote:
> > Hi -
> >
> > I'm intrigued by the concern that netconf should be 
> assigned a Unix privileged port.
> > Does this mean that someone has or is developing a netconf 
> data model to configure
> > Unix hosts or applications?  Are there other reasons for 
> running a netconf server
> > on a Unix host?
> >   
> 
> Perhaps somebody is already implementing a "NETCONF to Unix 
> Config file" 
> gateway,
> running on Fedora4.  Netconf for unix is a very real possibility.
>

Hi Andy,

I can think of no conceivable reason someone would seriously
want to use Netconf for remote UNIX configuration.  For desktop
and server end systems, WBEM, WS-Management, and WSDM are the
plausible and _deployed_ solutions.  The DMTF DMI and DMTF CIM
models have been used for a decade to configure UNIX, MacOS,
Windows, and Linux systems.

Give me one technical reason that shifting from existing open
standard management protocols (that are already deployed and
already support interoperable event subscriptions and event
notifications) to Netconf would be a good idea?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

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



From owner-netconf@ops.ietf.org Fri Mar 17 19:31:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKPMD-0004QD-Lr
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:31:49 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKPMA-0003rT-8w
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:31:49 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKPHJ-0002By-JK
	for netconf-data@psg.com; Sat, 18 Mar 2006 00:26:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKPHI-0002Bn-Oq
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 00:26:44 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2I0Qh4K018213
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 19:26:43 -0500
Received: (qmail 19155 invoked from network); 18 Mar 2006 00:26:42 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 18 Mar 2006 00:26:42 -0000
Message-ID: <441B53EB.9000801@andybierman.com>
Date: Fri, 17 Mar 2006 16:27:23 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: Randy Presuhn <randy_presuhn@mindspring.com>,
        netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

McDonald, Ira wrote:
> Andy Bierman wrote:
>   
>> Randy Presuhn wrote:
>>     
>>> Hi -
>>>
>>> I'm intrigued by the concern that netconf should be 
>>>       
>> assigned a Unix privileged port.
>>     
>>> Does this mean that someone has or is developing a netconf 
>>>       
>> data model to configure
>>     
>>> Unix hosts or applications?  Are there other reasons for 
>>>       
>> running a netconf server
>>     
>>> on a Unix host?
>>>   
>>>       
>> Perhaps somebody is already implementing a "NETCONF to Unix 
>> Config file" 
>> gateway,
>> running on Fedora4.  Netconf for unix is a very real possibility.
>>
>>     
>
> Hi Andy,
>
> I can think of no conceivable reason someone would seriously
> want to use Netconf for remote UNIX configuration.  For desktop
> and server end systems, WBEM, WS-Management, and WSDM are the
> plausible and _deployed_ solutions.  The DMTF DMI and DMTF CIM
> models have been used for a decade to configure UNIX, MacOS,
> Windows, and Linux systems.
>
> Give me one technical reason that shifting from existing open
> standard management protocols (that are already deployed and
> already support interoperable event subscriptions and event
> notifications) to Netconf would be a good idea?
>   

People can experiment with whatever they want.
I still use ASCII config files to manage most linux services.
I guess I'm the only one still doing it the old-fashioned way.

> Cheers,
> - Ira
>   

Andy


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



From owner-netconf@ops.ietf.org Fri Mar 17 19:58:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKPlx-000832-R4
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:58:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKPlw-0004P7-HT
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 19:58:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKPhR-00043K-Dh
	for netconf-data@psg.com; Sat, 18 Mar 2006 00:53:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKPhQ-000438-Ml
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 00:53:44 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-2.cisco.com with ESMTP; 17 Mar 2006 16:53:44 -0800
X-IronPort-AV: i="4.03,106,1141632000"; 
   d="scan'208"; a="315693100:sNHT26292228"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2I0rhGv026130;
	Fri, 17 Mar 2006 16:53:43 -0800 (PST)
Received: from [171.71.201.9] (dhcp-171-71-201-9.cisco.com [171.71.201.9])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2I0swK6027129;
	Fri, 17 Mar 2006 16:54:58 -0800
Message-ID: <441B5A19.3080701@cisco.com>
Date: Fri, 17 Mar 2006 16:53:45 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Andy Bierman'" <ietf@andybierman.com>,
        Randy Presuhn <randy_presuhn@mindspring.com>,
        netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=814; t=1142643298; x=1143075498;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20use=20of=20netconf=20to=20configure=20Unix=20systems
	|To:=22McDonald,=20Ira=22=20<imcdonald@sharplabs.com>;
	X=v=3Dmtcc.com=3B=20h=3D/py5UhO/W8Es1liIOQhAkfAzLqo=3D; b=NDUIQRpe6Ll96nd0wNWgbWFXU4lu3+LQwYNEqxV2HhJHd9048eSRp0+8V9HfbvZjoFxm+/f9
	Y77MLV5WIHUCBWu2keB5Roweg5Tz+vXdUAsYjaEzkvGcpUV/f2I1bLe4H41nIN5hdBBeTw6fyLp
	Df9GgDLYAr2auv2AVX6g/ZNg=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

McDonald, Ira wrote:
> I can think of no conceivable reason someone would seriously
> want to use Netconf for remote UNIX configuration.  For desktop
> and server end systems, WBEM, WS-Management, and WSDM are the
> plausible and _deployed_ solutions.  The DMTF DMI and DMTF CIM
> models have been used for a decade to configure UNIX, MacOS,
> Windows, and Linux systems.
>   
I think you are looking at the problem as though every UNIX device is a
classical general computing device.  That is really not the case, as
Linksys & Juniper can attest.  Also, it's very early to say exactly how
popular netconf will be and on what platforms it will extend.

Finally I do wish you would answer the question that was asked several
times: if NETCONF is not a good use of well known ports, what is?

Eliot

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



From owner-netconf@ops.ietf.org Fri Mar 17 20:27:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKQDn-0002sX-Tp
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 20:27:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKQDm-0005ZZ-JO
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 20:27:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKQ8Y-0005rU-8K
	for netconf-data@psg.com; Sat, 18 Mar 2006 01:21:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	RCVD_IN_SORBS_WEB autolearn=no version=3.1.0
Received: from [207.69.195.72] (helo=pop-sarus.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKQ8X-0005rI-IZ
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 01:21:45 +0000
Received: from user-2ivepo2.dialup.mindspring.com ([165.247.103.2] helo=JMHLap3.stevecrocker.com)
	by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
	id 1FKQ8V-00055f-00; Fri, 17 Mar 2006 20:21:43 -0500
Message-Id: <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 17 Mar 2006 20:21:40 -0500
To: Eliot Lear <lear@cisco.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: use of netconf to configure Unix systems
Cc: netconf <netconf@ops.ietf.org>
In-Reply-To: <441B5A19.3080701@cisco.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
 <441B5A19.3080701@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

I believe that the correct, current, answer to your question is "nothing."
Netconf is clearly not a better use of those ports than a large 
number of things that have been assigned higher numbered ports.
Hence, I think Netconf should live in the same space as everyone else.
The 1024 port space was reserved based on a certain model of the 
world.  That model no longer obtains.

There is arguably even a good reason that Netconf should not be 
using, by default, a reserved port.  I can easily imagine 
experimental router implementations where the control logic (and even 
the router and router config logic) are living in user space.  They 
are not running as priviledged processes.  They could support 
Netconf, and the standard port, if that port were not in the kernel 
set.  But could not use the normal Netconf port if it was in the system space.

Using a <1024 port buys us nothing.
Not using one is more appropriate, and may even be useful.

Yours,
Joel M. Halpern

At 07:53 PM 3/17/2006, Eliot Lear wrote:
>Finally I do wish you would answer the question that was asked several
>times: if NETCONF is not a good use of well known ports, what is?


--
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 Mar 17 20:49:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKQZO-0005A1-BV
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 20:49:30 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKQZO-0005vT-1W
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 20:49:30 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKQUR-0007JZ-NQ
	for netconf-data@psg.com; Sat, 18 Mar 2006 01:44:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKQUQ-0007JN-Ps
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 01:44:22 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2I1iLDT001616
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 20:44:21 -0500
Received: (qmail 24540 invoked from network); 18 Mar 2006 01:44:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 18 Mar 2006 01:44:21 -0000
Message-ID: <441B6629.80606@andybierman.com>
Date: Fri, 17 Mar 2006 17:45:13 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
CC: Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com> <441B5A19.3080701@cisco.com> <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com>
In-Reply-To: <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

Joel M. Halpern wrote:
> I believe that the correct, current, answer to your question is 
> "nothing."
> Netconf is clearly not a better use of those ports than a large number 
> of things that have been assigned higher numbered ports.
> Hence, I think Netconf should live in the same space as everyone else.
> The 1024 port space was reserved based on a certain model of the 
> world.  That model no longer obtains.
>
> There is arguably even a good reason that Netconf should not be using, 
> by default, a reserved port.  I can easily imagine experimental router 
> implementations where the control logic (and even the router and 
> router config logic) are living in user space.  They are not running 
> as priviledged processes.  They could support Netconf, and the 
> standard port, if that port were not in the kernel set.  But could not 
> use the normal Netconf port if it was in the system space.
>
> Using a <1024 port buys us nothing.

Your previous paragraph clearly contradicts this statement.
I am interested in current practice for operational systems,
not experimental systems that might exist in the future.
Current practice is to make it harder for users to attach processes
to system port numbers that higher port numbers.


> Not using one is more appropriate, and may even be useful.

I disagree -- current practice by network operators is contrary
to this conclusion. 

The logic that no protocol should ever use the <1024 range again
instantly makes the "Registered Port" range a more scarce resource
for no apparent reason.


>
> Yours,
> Joel M. Halpern

Andy

>
> At 07:53 PM 3/17/2006, Eliot Lear wrote:
>> Finally I do wish you would answer the question that was asked several
>> times: if NETCONF is not a good use of well known ports, what is?
>
>
> -- 
> 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 Mar 17 21:02:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKQle-0001YG-Sy
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:02:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKQle-0006ZX-GK
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:02:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKQgG-00087M-CI
	for netconf-data@psg.com; Sat, 18 Mar 2006 01:56:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKQgF-000877-Hy
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 01:56:35 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2I1uVrd024184;
	Fri, 17 Mar 2006 17:56:31 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYYRPJ>; Fri, 17 Mar 2006 17:56:32 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FBD@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
        "Joel M. Halpern"
	 <joel@stevecrocker.com>
Cc: Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: RE: use of netconf to configure Unix systems
Date: Fri, 17 Mar 2006 17:56:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f

Hi,

Specious arguments, Andy.

The "Well Known Port" range has 1,024 slots and 70% consumed.

The "Registered Port" range has over 48,000 slots and 12% consumed.

Most new IETF protocols have NOT been given "Well Known Port"
assignments in recent years.  The only justification for Netconf 
would be that it will be a critical system service for MOST
end and intermediate systems, intended to entirely supplant the
alternatives - such a usage profile is ludicrous in any possible
future.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Friday, March 17, 2006 8:45 PM
> To: Joel M. Halpern
> Cc: Eliot Lear; netconf
> Subject: Re: use of netconf to configure Unix systems
> 
> 
> Joel M. Halpern wrote:
> > I believe that the correct, current, answer to your question is 
> > "nothing."
> > Netconf is clearly not a better use of those ports than a 
> large number 
> > of things that have been assigned higher numbered ports.
> > Hence, I think Netconf should live in the same space as 
> everyone else.
> > The 1024 port space was reserved based on a certain model of the 
> > world.  That model no longer obtains.
> >
> > There is arguably even a good reason that Netconf should 
> not be using, 
> > by default, a reserved port.  I can easily imagine 
> experimental router 
> > implementations where the control logic (and even the router and 
> > router config logic) are living in user space.  They are 
> not running 
> > as priviledged processes.  They could support Netconf, and the 
> > standard port, if that port were not in the kernel set.  
> But could not 
> > use the normal Netconf port if it was in the system space.
> >
> > Using a <1024 port buys us nothing.
> 
> Your previous paragraph clearly contradicts this statement.
> I am interested in current practice for operational systems,
> not experimental systems that might exist in the future.
> Current practice is to make it harder for users to attach processes
> to system port numbers that higher port numbers.
> 
> 
> > Not using one is more appropriate, and may even be useful.
> 
> I disagree -- current practice by network operators is contrary
> to this conclusion. 
> 
> The logic that no protocol should ever use the <1024 range again
> instantly makes the "Registered Port" range a more scarce resource
> for no apparent reason.
> 
> 
> >
> > Yours,
> > Joel M. Halpern
> 
> Andy
> 
> >
> > At 07:53 PM 3/17/2006, Eliot Lear wrote:
> >> Finally I do wish you would answer the question that was 
> asked several
> >> times: if NETCONF is not a good use of well known ports, what is?
> >
> >
> > -- 
> > 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 Mar 17 21:07:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKQqg-00010U-OB
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:07:22 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKQqf-0006kG-8i
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:07:22 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKQmP-0008br-Lj
	for netconf-data@psg.com; Sat, 18 Mar 2006 02:02:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	RCVD_IN_SORBS_WEB autolearn=no version=3.1.0
Received: from [207.69.195.68] (helo=pop-cowbird.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKQmO-0008bc-TQ
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 02:02:56 +0000
Received: from user-2ivepo2.dialup.mindspring.com ([165.247.103.2] helo=JMHLap3.stevecrocker.com)
	by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
	id 1FKQmL-0001KT-00; Fri, 17 Mar 2006 21:02:54 -0500
Message-Id: <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 17 Mar 2006 21:02:15 -0500
To: Andy Bierman <ietf@andybierman.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: use of netconf to configure Unix systems
Cc: Eliot Lear <lear@cisco.com>,netconf <netconf@ops.ietf.org>
In-Reply-To: <441B6629.80606@andybierman.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
 <441B5A19.3080701@cisco.com>
 <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com>
 <441B6629.80606@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1

If the network operators gained anything by having Netconf running on 
ports below 1024, I would be more inclined to see that used.
As far as I can see from the discussion, there is no benefit.
And the notion of user space routers is not theoretical.  I would 
like the ForCES CE to be able to be managed using netconf.  And it is 
a specific design goal that ForCES CEs are NOT part of the kernel.
And that is just one example.

Looking at the list of assigned ports, there are an awful lot of 
things there that I can imagine would be run on a router control 
processor, and which better not have their port stolen.  (I am not 
naming protocols because the odds are that some of them are not for 
routers, and that some I am not even noticing are for routers.) It 
also looks like there are plenty of host oriented protocols that 
would need to have their ports remain available above 1024.  It sure 
looks like folks have learned to live with protocols (not just SIP 
and STUN, but many, many operationally necessary protocols) running 
above 1024.  Hence, it does not seem to me that the risk of "port 
occupation" is any more relevant for this protocol than for many, 
many other protocols.

So, is there some other reason that I have not seen for wanting to 
use a low numbered port?

Yours,
Joel

At 08:45 PM 3/17/2006, Andy Bierman wrote:
>Joel M. Halpern wrote:
>>I believe that the correct, current, answer to your question is "nothing."
>>Netconf is clearly not a better use of those ports than a large 
>>number of things that have been assigned higher numbered ports.
>>Hence, I think Netconf should live in the same space as everyone else.
>>The 1024 port space was reserved based on a certain model of the 
>>world.  That model no longer obtains.
>>
>>There is arguably even a good reason that Netconf should not be 
>>using, by default, a reserved port.  I can easily imagine 
>>experimental router implementations where the control logic (and 
>>even the router and router config logic) are living in user 
>>space.  They are not running as priviledged processes.  They could 
>>support Netconf, and the standard port, if that port were not in 
>>the kernel set.  But could not use the normal Netconf port if it 
>>was in the system space.
>>
>>Using a <1024 port buys us nothing.
>
>Your previous paragraph clearly contradicts this statement.
>I am interested in current practice for operational systems,
>not experimental systems that might exist in the future.
>Current practice is to make it harder for users to attach processes
>to system port numbers that higher port numbers.
>
>
>>Not using one is more appropriate, and may even be useful.
>
>I disagree -- current practice by network operators is contrary
>to this conclusion.
>The logic that no protocol should ever use the <1024 range again
>instantly makes the "Registered Port" range a more scarce resource
>for no apparent reason.
>
>
>>
>>Yours,
>>Joel M. Halpern
>
>Andy
>
>>
>>At 07:53 PM 3/17/2006, Eliot Lear wrote:
>>>Finally I do wish you would answer the question that was asked several
>>>times: if NETCONF is not a good use of well known ports, what is?
>>
>>
>>--
>>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 Mar 17 21:29:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKRBv-0002ZK-EJ
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:29:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKRBt-0007VO-63
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:29:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKR7g-000A2x-56
	for netconf-data@psg.com; Sat, 18 Mar 2006 02:24:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKR7f-000A2l-2s
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 02:24:55 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 18:24:55 -0800
X-IronPort-AV: i="4.03,106,1141632000"; 
   d="scan'208"; a="1786053800:sNHT31107914"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2I2Osw1022701;
	Fri, 17 Mar 2006 18:24:54 -0800 (PST)
Received: from [171.71.201.9] (dhcp-171-71-201-9.cisco.com [171.71.201.9])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2I2Q9T3027548;
	Fri, 17 Mar 2006 18:26:09 -0800
Message-ID: <441B6F78.5090301@cisco.com>
Date: Fri, 17 Mar 2006 18:24:56 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
CC: Andy Bierman <ietf@andybierman.com>, netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com> <441B5A19.3080701@cisco.com> <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com> <441B6629.80606@andybierman.com> <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
In-Reply-To: <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2741; t=1142648769; x=1143080969;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20use=20of=20netconf=20to=20configure=20Unix=20systems
	|To:=22Joel=20M.=20Halpern=22=20<joel@stevecrocker.com>;
	X=v=3Dmtcc.com=3B=20h=3DrPzZURbWLbzhQYItnBUzDdiDVlw=3D; b=iC0/0uGuLIYtzPWgvrwZTD+TkRW3tG7JgsEAIJJ5igLKXe51/OtZxqT0cUe2F2pqrnhjwzA0
	qIRObpI3DMWfP9/I5Qh12fkT/9I6sV+o4u8DCYeXIMmoLCwGf5NtSo01fVk+5TusHXdI1sOdYun
	HsoONwmEqJyRSfCDaKa+Uo7I=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Joel,

First thanks for the productive comments.  Please see below.

Joel M. Halpern wrote:
> If the network operators gained anything by having Netconf running on
> ports below 1024, I would be more inclined to see that used.
I would agree that from a network perspective it's just as easy to block
a port below 1024 as it is above.  That having been said, I was confused
by what you wrote earlier as to how a well known port would harm efforts
in this area.

> And the notion of user space routers is not theoretical.  I would like
> the ForCES CE to be able to be managed using netconf.  And it is a
> specific design goal that ForCES CEs are NOT part of the kernel.
Just to be clear, at least on UNIX, ports below 1024 are accessed in
user space, the only difference being that root must own the process at
the time the port is assigned.  Processes that do not need well known
ports really SHOULDN'T have them because dealing with root permissions
*is* a minor complication - you really do want to isolate the code that
owns that port (for instance through use of inetd).  If this doesn't
address your concern, could you please clarify?

But it also sounds like you may wish for there to be some sort of
virtualization in NETCONF, as Elwyn discussed in his review (RFC
3620?).  That might be a worthy extension to consider.
>
> Looking at the list of assigned ports, there are an awful lot of
> things there that I can imagine would be run on a router control
> processor, and which better not have their port stolen.  (I am not
> naming protocols because the odds are that some of them are not for
> routers, and that some I am not even noticing are for routers.) It
> also looks like there are plenty of host oriented protocols that would
> need to have their ports remain available above 1024.  It sure looks
> like folks have learned to live with protocols (not just SIP and STUN,
> but many, many operationally necessary protocols) running above 1024. 
> Hence, it does not seem to me that the risk of "port occupation" is
> any more relevant for this protocol than for many, many other protocols.
>
> So, is there some other reason that I have not seen for wanting to use
> a low numbered port?

Ultimately not from me because I think a better approach is to have some
sort of authorization mechanism in the bind() and listen() routines, so
I would largely agree with you that the distinction should go away. 
Given that it's here I've attempted to apply it as intended.  In my mind
it's not a router versus host thing, but simply a matter of whether you
believe there is something special about < 1024 and what criteria should
be used to assign below it.

Thanks again,

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 Mar 17 21:43:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKRPR-0001bg-UP
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:43:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKRPR-0007e1-EV
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 21:43:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKRLf-000Ayz-H3
	for netconf-data@psg.com; Sat, 18 Mar 2006 02:39:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKRLe-000Ayn-C5
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 02:39:22 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2I2dKkQ016629
	for <netconf@ops.ietf.org>; Fri, 17 Mar 2006 21:39:21 -0500
Received: (qmail 12063 invoked from network); 18 Mar 2006 02:39:20 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 18 Mar 2006 02:39:20 -0000
Message-ID: <441B7314.5080000@andybierman.com>
Date: Fri, 17 Mar 2006 18:40:20 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
CC: Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com> <441B5A19.3080701@cisco.com> <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com> <441B6629.80606@andybierman.com> <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
In-Reply-To: <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede

Joel M. Halpern wrote:
> If the network operators gained anything by having Netconf running on 
> ports below 1024, I would be more inclined to see that used.
> As far as I can see from the discussion, there is no benefit.
> And the notion of user space routers is not theoretical.  I would like 
> the ForCES CE to be able to be managed using netconf.  And it is a 
> specific design goal that ForCES CEs are NOT part of the kernel.
> And that is just one example.
>
> Looking at the list of assigned ports, there are an awful lot of 
> things there that I can imagine would be run on a router control 
> processor, and which better not have their port stolen.  (I am not 
> naming protocols because the odds are that some of them are not for 
> routers, and that some I am not even noticing are for routers.) It 
> also looks like there are plenty of host oriented protocols that would 
> need to have their ports remain available above 1024.  It sure looks 
> like folks have learned to live with protocols (not just SIP and STUN, 
> but many, many operationally necessary protocols) running above 1024.  
> Hence, it does not seem to me that the risk of "port occupation" is 
> any more relevant for this protocol than for many, many other protocols.
>
> So, is there some other reason that I have not seen for wanting to use 
> a low numbered port?

There are ways to allow users specific access to root programs (e,g,. 'su').

There is really no way to logically conclude this discussion.

You and Ira are arguing that no protocol should ever use the system port
space again, including NETCONF.  If this is IESG policy, then I guess we
are done discussing it.

Some others have said the port number doesn't really matter,
except a bit for unix implementations, and some "legacy bias" against
using higher port numbers for system services. (Large "don't care" camp)

Eliot and I are arguing that the task of configuring a networking device
(a server, not a plain host!)  is clearly a privileged task in almost all
environments, which is NETCONF's chartered purpose.  If device configuration
and control isn't a system task on a networking device, then
I don't know what is.

If there are no possible reasons for assigning system port numbers
anymore, then IANA can stop asking which range the new protocol
should be assigned, and WGs like us don't need to argue about
anymore.





>
> Yours,
> Joel


Andy

>
> At 08:45 PM 3/17/2006, Andy Bierman wrote:
>> Joel M. Halpern wrote:
>>> I believe that the correct, current, answer to your question is 
>>> "nothing."
>>> Netconf is clearly not a better use of those ports than a large 
>>> number of things that have been assigned higher numbered ports.
>>> Hence, I think Netconf should live in the same space as everyone else.
>>> The 1024 port space was reserved based on a certain model of the 
>>> world.  That model no longer obtains.
>>>
>>> There is arguably even a good reason that Netconf should not be 
>>> using, by default, a reserved port.  I can easily imagine 
>>> experimental router implementations where the control logic (and 
>>> even the router and router config logic) are living in user space.  
>>> They are not running as priviledged processes.  They could support 
>>> Netconf, and the standard port, if that port were not in the kernel 
>>> set.  But could not use the normal Netconf port if it was in the 
>>> system space.
>>>
>>> Using a <1024 port buys us nothing.
>>
>> Your previous paragraph clearly contradicts this statement.
>> I am interested in current practice for operational systems,
>> not experimental systems that might exist in the future.
>> Current practice is to make it harder for users to attach processes
>> to system port numbers that higher port numbers.
>>
>>
>>> Not using one is more appropriate, and may even be useful.
>>
>> I disagree -- current practice by network operators is contrary
>> to this conclusion.
>> The logic that no protocol should ever use the <1024 range again
>> instantly makes the "Registered Port" range a more scarce resource
>> for no apparent reason.
>>
>>
>>>
>>> Yours,
>>> Joel M. Halpern
>>
>> Andy
>>
>>>
>>> At 07:53 PM 3/17/2006, Eliot Lear wrote:
>>>> Finally I do wish you would answer the question that was asked several
>>>> times: if NETCONF is not a good use of well known ports, what is?
>>>
>>>
>>> -- 
>>> 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 Mar 17 22:12:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKRrH-00080p-3M
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 22:12:03 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKRrF-0000AO-NE
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 22:12:03 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKRmc-000D2G-H8
	for netconf-data@psg.com; Sat, 18 Mar 2006 03:07:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FKRmb-000D25-VO
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 03:07:14 +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 k2I37BX60647;
	Fri, 17 Mar 2006 19:07:11 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2I375537334;
	Fri, 17 Mar 2006 19:07:05 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2I3CJYE098019;
	Fri, 17 Mar 2006 22:12:19 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603180312.k2I3CJYE098019@idle.juniper.net>
To: "Joel M. Halpern" <joel@stevecrocker.com>
cc: Andy Bierman <ietf@andybierman.com>, Eliot Lear <lear@cisco.com>,
   netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems 
In-Reply-To: Your message of "Fri, 17 Mar 2006 21:02:15 EST."
             <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com> 
Date: Fri, 17 Mar 2006 22:12:19 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

"Joel M. Halpern" writes:
>like the ForCES CE to be able to be managed using netconf.  And it is 
>a specific design goal that ForCES CEs are NOT part of the kernel.

Use of privileged port does not require code to be part of the
kernel, just that it be root (uid 0) when the bind() call is made.
Daemons can do their bind() and then setuid() to nobody to protect
themselves from giving crackers root access.

To me, the benefit of using a privileged port is minor, but the
benefit to _any_ protocol is minor nowadays, so I don't see this
as a big issue either way.  NETCONF doesn't need a priv port, but
no other protocol can be considered more (or less ;^) deserving,
so if IANA's willing to give us three, we should be gratious enough
to accept them.  If not, it's not a big deal.

>So, is there some other reason that I have not seen for wanting to 
>use a low numbered port?

Having to be root for debugging is a pain, but one can just do some
port forwarding to get around that.

>Eliot Lear wrote:
>Given that it exists, when SHOULD something be assigned <1024?

When the protocol was designed before the onslaught of Windows.  Or
if the protocol is expected to survive past the death of Windows.
Neither applies here ;^)

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 Fri Mar 17 23:53:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKTR0-0000lF-82
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 23:53:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKTQx-0002yU-TX
	for netconf-archive@lists.ietf.org; Fri, 17 Mar 2006 23:53:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKTKq-000JzY-K8
	for netconf-data@psg.com; Sat, 18 Mar 2006 04:46:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [207.69.195.66] (helo=pop-canoe.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKTKp-000JzN-Om
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 04:46:39 +0000
Received: from user-2ivf94i.dsl.mindspring.com ([165.247.164.146] helo=JMHLap3.stevecrocker.com)
	by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
	id 1FKTKm-00041F-00; Fri, 17 Mar 2006 23:46:37 -0500
Message-Id: <7.0.1.0.0.20060317233736.0328ba28@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Fri, 17 Mar 2006 23:46:34 -0500
To: Andy Bierman <ietf@andybierman.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: use of netconf to configure Unix systems
Cc: Eliot Lear <lear@cisco.com>,netconf <netconf@ops.ietf.org>
In-Reply-To: <441B7314.5080000@andybierman.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBB@mailsrvnt02.enet.sharplabs.com>
 <441B5A19.3080701@cisco.com>
 <7.0.1.0.0.20060317201708.032d5e08@stevecrocker.com>
 <441B6629.80606@andybierman.com>
 <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com>
 <441B7314.5080000@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

minor: Ira and I are not the only people speaking up.  I was struck 
by the tone of the debate that was occurring, which is why I spoke up.

And just to clarify my own sloppiness, I realized after I wrote the 
note that "root" rather than "kernel" is what is needed for a low 
port, and that is indeed easier.  But it is MUCH better to develop 
and run applications without having to make them root, even 
briefly.  (The coupling of the various permissions within Unix is not 
our problem, but that doesn't make it desirable.)

Given that, to paraphrase Phil's comment, it doesn't make that much 
difference, it would seem more sensible to go for a higher range port number.
However, neither Ira nor I speak for the IESG.  Heck, I'm not even 
speaking as a "reviewer", just as a participant / observer in this 
working group.
I guess I just find "its appropriate to use low numbers for this" a 
bad reason.  From different perspectives, different things are 
"privileged".  I know many folks who will claim that the only really 
privileged operation is collecting money. And others.......

Yours,
Joel

PS: I would prefer not to hang this protocol up on a debate about 
whether <1024 ports should ever be given out.  That would be a waste 
of all our time.

At 09:40 PM 3/17/2006, Andy Bierman wrote:
>There are ways to allow users specific access to root programs (e,g,. 'su').
>
>There is really no way to logically conclude this discussion.
>
>You and Ira are arguing that no protocol should ever use the system port
>space again, including NETCONF.  If this is IESG policy, then I guess we
>are done discussing it.
>
>Some others have said the port number doesn't really matter,
>except a bit for unix implementations, and some "legacy bias" against
>using higher port numbers for system services. (Large "don't care" camp)
>
>Eliot and I are arguing that the task of configuring a networking device
>(a server, not a plain host!)  is clearly a privileged task in almost all
>environments, which is NETCONF's chartered purpose.  If device configuration
>and control isn't a system task on a networking device, then
>I don't know what is.
>
>If there are no possible reasons for assigning system port numbers
>anymore, then IANA can stop asking which range the new protocol
>should be assigned, and WGs like us don't need to argue about
>anymore.


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



From owner-netconf@ops.ietf.org Sat Mar 18 02:45:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKW7l-0007XA-5T
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 02:45:21 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKW7g-0008FD-Hh
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 02:45:21 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKW3R-0006o4-3m
	for netconf-data@psg.com; Sat, 18 Mar 2006 07:40:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FKW3P-0006nn-JW
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 07:40:51 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id A144A4D2B0;
	Sat, 18 Mar 2006 08:40:50 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 30839-05; Sat, 18 Mar 2006 08:40:49 +0100 (CET)
Received: from boskop.local (unknown [10.222.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id E3C854D0FF;
	Sat, 18 Mar 2006 08:40:48 +0100 (CET)
Received: by boskop.local (Postfix, from userid 501)
	id B50416350DF; Sat, 18 Mar 2006 08:40:46 +0100 (CET)
Date: Sat, 18 Mar 2006 08:40:46 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Phil Shafer <phil@juniper.net>
Cc: "Joel M. Halpern" <joel@stevecrocker.com>,
	Andy Bierman <ietf@andybierman.com>, Eliot Lear <lear@cisco.com>,
	netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
Message-ID: <20060318074046.GA1059@noname>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Phil Shafer <phil@juniper.net>,
	"Joel M. Halpern" <joel@stevecrocker.com>,
	Andy Bierman <ietf@andybierman.com>, Eliot Lear <lear@cisco.com>,
	netconf <netconf@ops.ietf.org>
References: <7.0.1.0.0.20060317205107.0329ef90@stevecrocker.com> <200603180312.k2I3CJYE098019@idle.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200603180312.k2I3CJYE098019@idle.juniper.net>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

On Fri, Mar 17, 2006 at 10:12:19PM -0500, Phil Shafer wrote:
 
> Use of privileged port does not require code to be part of the
> kernel, just that it be root (uid 0) when the bind() call is made.
> Daemons can do their bind() and then setuid() to nobody to protect
> themselves from giving crackers root access.

Several modern Unix like systems now support a more granular set of
capabilities so that the above is not quite correct. On those modern
systems, a process has to have the appropriate capabilities to bind a
priviledged port.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Sat Mar 18 02:49:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKWBM-0007yB-Uj
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 02:49:04 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKWBJ-0008Jb-Lh
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 02:49:04 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKW8E-0007Aj-IV
	for netconf-data@psg.com; Sat, 18 Mar 2006 07:45:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FKW8C-0007AM-SC
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 07:45:49 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 35CC34D3BF;
	Sat, 18 Mar 2006 08:45:48 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 30903-05; Sat, 18 Mar 2006 08:45:46 +0100 (CET)
Received: from boskop.local (unknown [10.222.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 754154D2C5;
	Sat, 18 Mar 2006 08:45:46 +0100 (CET)
Received: by boskop.local (Postfix, from userid 501)
	id 4511F635117; Sat, 18 Mar 2006 08:45:44 +0100 (CET)
Date: Sat, 18 Mar 2006 08:45:44 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
Message-ID: <20060318074544.GB1059@noname>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Randy Presuhn <randy_presuhn@mindspring.com>,
	netconf <netconf@ops.ietf.org>
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

On Fri, Mar 17, 2006 at 01:39:42PM -0800, Randy Presuhn wrote:
 
> I'm intrigued by the concern that netconf should be assigned a Unix
> privileged port.  Does this mean that someone has or is developing a
> netconf data model to configure Unix hosts or applications?  Are
> there other reasons for running a netconf server on a Unix host?

Unix is increasingly used on embedded devices and this is where I can
see a need to deploy netconf. Host systems may follow, but I doubt
deployment will start from that type of systems since host systems
already allow me to put whatever I want there to solve my
configuration problem (e.g. cfengine or other systems).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Sat Mar 18 09:18:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKcGG-0004Eq-T8
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 09:18:32 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKcGF-0003OS-IH
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 09:18:32 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKc8k-0004yr-8E
	for netconf-data@psg.com; Sat, 18 Mar 2006 14:10:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKc8b-0004xX-0r
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 14:10:37 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2IEAZDT020288
	for <netconf@ops.ietf.org>; Sat, 18 Mar 2006 09:10:35 -0500
Received: (qmail 32377 invoked from network); 18 Mar 2006 14:10:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 18 Mar 2006 14:10:35 -0000
Message-ID: <441C14DA.4060200@andybierman.com>
Date: Sat, 18 Mar 2006 06:10:34 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>,
        netconf <netconf@ops.ietf.org>,
        Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
Subject: Re: use of netconf to configure Unix systems
References: <000f01c64a0b$4de3aca0$6401a8c0@oemcomputer> <20060318074544.GB1059@noname>
In-Reply-To: <20060318074544.GB1059@noname>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Juergen Schoenwaelder wrote:
> On Fri, Mar 17, 2006 at 01:39:42PM -0800, Randy Presuhn wrote:
>  
>   
>> I'm intrigued by the concern that netconf should be assigned a Unix
>> privileged port.  Does this mean that someone has or is developing a
>> netconf data model to configure Unix hosts or applications?  Are
>> there other reasons for running a netconf server on a Unix host?
>>     
>
> Unix is increasingly used on embedded devices and this is where I can
> see a need to deploy netconf. Host systems may follow, but I doubt
> deployment will start from that type of systems since host systems
> already allow me to put whatever I want there to solve my
> configuration problem (e.g. cfengine or other systems).
>   

I agree with you mostly.

In my email that started this discussion, I really meant network services
that happen to be running on a linux box instead of a traditional NE box.
I never meant user applications.  I certainly never meant Windows.

If I am using a CM system for the NE boxes that manages a particular
service, then I would rather have it support the occasional linux box
as well, rather than use an entirely separate CM system for that platform.


> /js
>
>   
Andy


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



From owner-netconf@ops.ietf.org Sat Mar 18 11:39:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKeT3-0004Hc-Db
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 11:39:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKeT3-0007WZ-3F
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 11:39:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKeOx-000E1M-Vm
	for netconf-data@psg.com; Sat, 18 Mar 2006 16:35:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FKeOx-000E19-4K
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 16:35:39 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2IGZS9a019106;
	Sat, 18 Mar 2006 08:35:30 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDYZDLK>; Sat, 18 Mar 2006 08:35:28 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FBF@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Joel M. Halpern'" <joel@stevecrocker.com>,
        Andy Bierman
	 <ietf@andybierman.com>
Cc: Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: RE: use of netconf to configure Unix systems
Date: Sat, 18 Mar 2006 08:35:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

Hi Joel,

+1

If Netconf really wants a "Well Known Port", then OK, let's
move on.

But it really is distressing that the IESG takes no active
part (apparently) in setting and enforcing policies for the
use of the remainder of this scarce resource.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Joel M. Halpern
> Sent: Friday, March 17, 2006 11:47 PM
> To: Andy Bierman
> Cc: Eliot Lear; netconf
> Subject: Re: use of netconf to configure Unix systems
> 
> 
> minor: Ira and I are not the only people speaking up.  I was struck 
> by the tone of the debate that was occurring, which is why I spoke up.
> 
> And just to clarify my own sloppiness, I realized after I wrote the 
> note that "root" rather than "kernel" is what is needed for a low 
> port, and that is indeed easier.  But it is MUCH better to develop 
> and run applications without having to make them root, even 
> briefly.  (The coupling of the various permissions within Unix is not 
> our problem, but that doesn't make it desirable.)
> 
> Given that, to paraphrase Phil's comment, it doesn't make that much 
> difference, it would seem more sensible to go for a higher 
> range port number.
> However, neither Ira nor I speak for the IESG.  Heck, I'm not even 
> speaking as a "reviewer", just as a participant / observer in this 
> working group.
> I guess I just find "its appropriate to use low numbers for this" a 
> bad reason.  From different perspectives, different things are 
> "privileged".  I know many folks who will claim that the only really 
> privileged operation is collecting money. And others.......
> 
> Yours,
> Joel
> 
> PS: I would prefer not to hang this protocol up on a debate about 
> whether <1024 ports should ever be given out.  That would be a waste 
> of all our time.
> 
> At 09:40 PM 3/17/2006, Andy Bierman wrote:
> >There are ways to allow users specific access to root 
> programs (e,g,. 'su').
> >
> >There is really no way to logically conclude this discussion.
> >
> >You and Ira are arguing that no protocol should ever use the 
> system port
> >space again, including NETCONF.  If this is IESG policy, 
> then I guess we
> >are done discussing it.
> >
> >Some others have said the port number doesn't really matter,
> >except a bit for unix implementations, and some "legacy bias" against
> >using higher port numbers for system services. (Large "don't 
> care" camp)
> >
> >Eliot and I are arguing that the task of configuring a 
> networking device
> >(a server, not a plain host!)  is clearly a privileged task 
> in almost all
> >environments, which is NETCONF's chartered purpose.  If 
> device configuration
> >and control isn't a system task on a networking device, then
> >I don't know what is.
> >
> >If there are no possible reasons for assigning system port numbers
> >anymore, then IANA can stop asking which range the new protocol
> >should be assigned, and WGs like us don't need to argue about
> >anymore.
> 
> 
> --
> 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 Sat Mar 18 12:43:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKfSR-0003lq-EN
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 12:43:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKfSR-00018S-4O
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 12:43:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKfNL-000HbF-Mm
	for netconf-data@psg.com; Sat, 18 Mar 2006 17:38:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FKfNL-000Hb4-7I
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 17:38:03 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by test-iport-1.cisco.com with ESMTP; 18 Mar 2006 09:38:02 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2IHc2Gv016253;
	Sat, 18 Mar 2006 09:38:02 -0800 (PST)
Received: from [192.168.3.94] (sjc-vpn7-279.cisco.com [10.21.145.23])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2IHdEpl029828;
	Sat, 18 Mar 2006 09:39:14 -0800
Message-ID: <441C457D.5080900@cisco.com>
Date: Sat, 18 Mar 2006 09:38:05 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>
CC: IANA <iana@iana.org>, netconf <netconf@ops.ietf.org>,
        Lisa Dusseault <lisa@osafoundation.org>
Subject: Guidance needed on well known ports
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2297; t=1142703555; x=1143135755;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Guidance=20needed=20on=20well=20known=20ports
	|To:IETF=20Discussion=20<ietf@ietf.org>;
	X=v=3Dmtcc.com=3B=20h=3Dyu9SmknkZpbPA3IWPyDQ9keTZJk=3D; b=CbHFrFxgVLjdDPAnXesmXDthWgmMvjRoCASF2uk88+P4dbTNHpMguxvdYoT2YjikjhiTRiaY
	BGGCNWniUHak5gPNxgi9vG/uay5Bw7EDp3ztixb/SMhDUMAUjyjg1IE8B5QYIUoR2c9UDUMpGHJ
	lPZlkL98LNBwXqOET9BYJq+U=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Hello all,

In trudging along with the NETCONF specs we hit a bump when the IANA
asked what type of ports we would like, whether they should be well
known ports or not.  The working group has churned for a while on this
and while almost everyone agrees it's a minor thing, it seems we need
some guidance on when well known ports should be used.

On the one hand, NETCONF cannot at this time claim to be widely
implemented and so it's not all that well known.  By this argument it
should be assigned a port > 1024.  On the other hand, few protocols out
of the box are well known, and it would seem foolish to allocate new
ports when a protocol becomes well known.

The argument has been made that ports < 1024 are privileged and hence
these ports should be reserved for sensitive system services, and that
configuration services fit within that definition.  On the other hand,
this seems archaic and more in the realm of OS implementations as to
what process can bind to a port.

A third argument could be made that the decision should be based on
whether the community believes the protocol is "important" enough to
assign a well known port.  This vague notion may be appropriate but it
is something that is difficult for a spec author or even a working group
to decide.

This therefore leads to two questions for the community:

   1. Are well known ports archaic?  If so, can we request that the IANA
      do away with the distinction?
   2. If they are not archaic, under what circumstances should they be
      allocated?

My own opinion:

They are archaic and the distinction should be dropped.  Many operating
systems do not make the distinction (particularly special purpose ones)
and those that do would be better off providing a finer grain control
over what processes can bind to ports.

If you disagree then I claim that the decision to allocate a well known
port should be based on the need of an operating system to protect that
service against user interference a/o denial of service, since the only
benefit of a well known port is that non-privileged processes may not be
able to bind to ports below 1024.  Therefore it follows that device
management services deserve well known ports, and NETCONF fits the bill.

Comments?

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 Sat Mar 18 13:03:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKflr-0008Q0-C4
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 13:03:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKflq-0001io-TY
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 13:03:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKfi9-000IvC-R0
	for netconf-data@psg.com; Sat, 18 Mar 2006 17:59:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FKfi6-000Iuo-OF
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 17:59:30 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2IHxShB020580
	for <netconf@ops.ietf.org>; Sat, 18 Mar 2006 12:59:29 -0500
Received: (qmail 21273 invoked from network); 18 Mar 2006 17:59:28 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 18 Mar 2006 17:59:28 -0000
Message-ID: <441C4A7E.2000409@andybierman.com>
Date: Sat, 18 Mar 2006 09:59:26 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Joel M. Halpern'" <joel@stevecrocker.com>, Eliot Lear <lear@cisco.com>,
        netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBF@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FBF@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78

McDonald, Ira wrote:
> Hi Joel,
>
> +1
>
> If Netconf really wants a "Well Known Port", then OK, let's
> move on.
>
> But it really is distressing that the IESG takes no active
> part (apparently) in setting and enforcing policies for the
> use of the remainder of this scarce resource.
>   

A) I have asked the ADs for advice.
     If we have no consensus, then do we have "rough consensus"?
     Using the Olympics system (throw out the high and low scores),
     the rough consensus is "don't really care".
     But, if the WG can show sufficient justification, then system port 
numbers
     can be assigned. 

B) scarce resource
     If there is no point to EVER assigning any protocol to this range 
anymore,
     then it's no longer a resource, scarce or otherwise.

Either the assignment range matters, in which case I believe there is 
sufficient
justification to ask for well known port numbers for NETCONF, or the
assignment range doesn't matter, and therefore all new static ports are
registered ports.  I can live with either decision, but I would prefer
an actual IESG decision in this matter.

If I posed the question to operators as "Would it matter to you if SSH was
initially assigned a registered port number instead of a well-known port 
number?"
I wonder if I would get the same answer as for NETCONF. (Yes --  "huh?" ;-)

This does need to be resolved soon.


> Cheers,
> - Ira
>
>   


Andy

> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
>
>   
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>> Behalf Of Joel M. Halpern
>> Sent: Friday, March 17, 2006 11:47 PM
>> To: Andy Bierman
>> Cc: Eliot Lear; netconf
>> Subject: Re: use of netconf to configure Unix systems
>>
>>
>> minor: Ira and I are not the only people speaking up.  I was struck 
>> by the tone of the debate that was occurring, which is why I spoke up.
>>
>> And just to clarify my own sloppiness, I realized after I wrote the 
>> note that "root" rather than "kernel" is what is needed for a low 
>> port, and that is indeed easier.  But it is MUCH better to develop 
>> and run applications without having to make them root, even 
>> briefly.  (The coupling of the various permissions within Unix is not 
>> our problem, but that doesn't make it desirable.)
>>
>> Given that, to paraphrase Phil's comment, it doesn't make that much 
>> difference, it would seem more sensible to go for a higher 
>> range port number.
>> However, neither Ira nor I speak for the IESG.  Heck, I'm not even 
>> speaking as a "reviewer", just as a participant / observer in this 
>> working group.
>> I guess I just find "its appropriate to use low numbers for this" a 
>> bad reason.  From different perspectives, different things are 
>> "privileged".  I know many folks who will claim that the only really 
>> privileged operation is collecting money. And others.......
>>
>> Yours,
>> Joel
>>
>> PS: I would prefer not to hang this protocol up on a debate about 
>> whether <1024 ports should ever be given out.  That would be a waste 
>> of all our time.
>>
>> At 09:40 PM 3/17/2006, Andy Bierman wrote:
>>     
>>> There are ways to allow users specific access to root 
>>>       
>> programs (e,g,. 'su').
>>     
>>> There is really no way to logically conclude this discussion.
>>>
>>> You and Ira are arguing that no protocol should ever use the 
>>>       
>> system port
>>     
>>> space again, including NETCONF.  If this is IESG policy, 
>>>       
>> then I guess we
>>     
>>> are done discussing it.
>>>
>>> Some others have said the port number doesn't really matter,
>>> except a bit for unix implementations, and some "legacy bias" against
>>> using higher port numbers for system services. (Large "don't 
>>>       
>> care" camp)
>>     
>>> Eliot and I are arguing that the task of configuring a 
>>>       
>> networking device
>>     
>>> (a server, not a plain host!)  is clearly a privileged task 
>>>       
>> in almost all
>>     
>>> environments, which is NETCONF's chartered purpose.  If 
>>>       
>> device configuration
>>     
>>> and control isn't a system task on a networking device, then
>>> I don't know what is.
>>>
>>> If there are no possible reasons for assigning system port numbers
>>> anymore, then IANA can stop asking which range the new protocol
>>> should be assigned, and WGs like us don't need to argue about
>>> anymore.
>>>       
>> --
>> 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 Sat Mar 18 16:08:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKiej-00078t-BU
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 16:08:13 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKiei-0007oo-0x
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 16:08:13 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKiVt-00058X-SV
	for netconf-data@psg.com; Sat, 18 Mar 2006 20:59:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,RCVD_IN_SORBS_WEB autolearn=no version=3.1.0
Received: from [207.69.195.72] (helo=pop-sarus.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKiVt-00057p-60
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 20:59:05 +0000
Received: from user-2ivepia.dialup.mindspring.com ([165.247.102.74] helo=JMHLap3.stevecrocker.com)
	by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
	id 1FKiVg-0000yo-00; Sat, 18 Mar 2006 15:58:53 -0500
Message-Id: <7.0.1.0.0.20060318155456.0328ff88@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sat, 18 Mar 2006 15:58:48 -0500
To: "Christian Huitema" <huitema@windows.microsoft.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: RE: Guidance needed on well known ports
Cc: iana@iana.org,netconf@ops.ietf.org,ietf@ietf.org
In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup
 .windeploy.ntdev.microsoft.com>
References: <20060318142117.26d5ecb3.smb@cs.columbia.edu>
 <70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

I would not that starting dynamic ports above 1024 or even above 4096 
is not sufficient.  There are already services with assigned ports 
higher than that.  And it keeps growing.  The IANA list of well-known 
ports is quite long.

If we could go back and start over, something like dynamic DNS and 
SRV records would get us out of the mess.  But that is not a viable choice.

Yes, whenever possible one starts services before applications which 
grab dynamic port numbers.  Unfortunately, that sometimes does not work.

All that aside, the IANA has a distinction (based on history) between 
ports below 1024 and those above.  And whne asking for a port number 
assignment, one specifies which range one wants.  I had least can not 
find a coherent strategy for what should be on one side or the other 
of that boundary.

Yours,
Joel

At 03:41 PM 3/18/2006, Christian Huitema wrote:
> > A more interesting question is this: what are the odds that a user
> > process will accidentally grab the port number before the system
> > process gets to it?  The notion of a "privileged" port number is
> > certainly preposterous; that said, putting services in a range that
> > ordinary applications tend not to use has its merits.
>
>There are two issues there, accidental collision between a dynamic port
>and a service port, and "voluntary" collision between applications
>trying to open the same port.
>
>The practical solution to the first problem are to start services and
>grab ports as part of the boot sequence, i.e. before user processes
>start, and start dynamic allocations at some high number (e.g. larger
>than 1024 or larger than 4096 or some admin defined value depending on
>system version and configuration). If there is a reserved range, then it
>is easy to start dynamic allocation outside the range.
>
>Starting services quickly also helps with the "voluntary collisions"
>between system services and applications, but is not foolproof. In any
>case, it does not help with collisions between applications, e.g. two
>applications trying to use the same port. What does help there is an
>easily accessible registration system, so application developers can
>easily "do the right thing", i.e. reserve a port and avoid collisions.
>Note the emphasis on "easily accessible": if there are too many hoops to
>jump through, the developers will likely just pick a number at random.
>
>-- Christian Huitema
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


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



From owner-netconf@ops.ietf.org Sat Mar 18 16:20:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKiqr-000329-21
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 16:20:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKiqp-0008Lh-Oo
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 16:20:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKin1-0006Hr-2S
	for netconf-data@psg.com; Sat, 18 Mar 2006 21:16:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FKin0-0006He-Et
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 21:16:46 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ILG73e025595
	for <netconf@ops.ietf.org>; Sat, 18 Mar 2006 16:16:07 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2IL0iYj017518
	for <netconf@ops.ietf.org>; Sat, 18 Mar 2006 16:00:45 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Guidance needed on well known ports
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Sat, 18 Mar 2006 23:16:42 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A322871@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZKzvgluLtnwRjVT+aA2EKI2pAtCQAAhJyA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>,
        "Christian Huitema" <huitema@windows.microsoft.com>
Cc: <iana@iana.org>, <ietf@ietf.org>, <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab


> All that aside, the IANA has a distinction (based on history)=20
> between ports below 1024 and those above.  And whne asking=20
> for a port number assignment, one specifies which range one=20
> wants.  I had least can not find a coherent strategy for what=20
> should be on one side or the other of that boundary.
>=20
> Yours,
> Joel
>=20

Do we need one?=20

Or maybe all this distinction is historical?

Dan


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



From owner-netconf@ops.ietf.org Sat Mar 18 18:35:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKkxH-00056J-PB
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 18:35:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKkxH-0003tU-FW
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 18:35:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKktF-000EJe-OP
	for netconf-data@psg.com; Sat, 18 Mar 2006 23:31:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,RCVD_IN_SORBS_WEB autolearn=no version=3.1.0
Received: from [207.69.195.67] (helo=pop-tawny.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FKktF-000EJQ-1O
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 23:31:21 +0000
Received: from user-2ivepia.dialup.mindspring.com ([165.247.102.74] helo=JMHLap3.stevecrocker.com)
	by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10)
	id 1FKkt6-0007Z9-00; Sat, 18 Mar 2006 18:31:13 -0500
Message-Id: <7.0.1.0.0.20060318182729.032f2488@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sat, 18 Mar 2006 18:31:05 -0500
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: RE: Guidance needed on well known ports
Cc: ietf@ietf.org,lear@cisco.com,netconf@ops.ietf.org
In-Reply-To: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.
 ad.vrsn.com>
References: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

While in general I would like to see this approach taken, this 
particular case is a perfect example of where I think one can not 
reasonably do that.  The protocol is for the purpose of configuring a 
router.  The router that needs to be configured could easily be 
between the network engineer and the DNS server.  The protocol can 
not rationally depend upon DNS (no matter how much I like the 
elegance of removing ports, using dynamic port numbers, and using dynamic DNS.)
Yes, we could invent a better way to make things work.  And maybe we should.
But Netconf should not be held up waiting for that to be developed.
Until we develop such a beast, we have to use port numbers.
Given that constraint, what guidelines ought to be used for whether a 
protocol gets a port number above or below 1024?

Yours,
Joel

At 05:09 PM 3/18/2006, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
>         micalg=SHA1; boundary="----=_NextPart_000_0011_01C64AAE.C23D25B0"
>
>The whole idea of fixed ports is broken.
>
>The idea that there are only 1024 or even 65535 Internet applications is
>broken.
>
>The Internet has a signalling layer, the DNS. Applications should use it.
>The SRV record provides an infinitely extensible mechanism for advertising
>ports.
>
>Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be
>well advised to pay careful attention to that restriction. SRV ports work
>just fine behind a NAT.
>
>
>IANA should be told to close the well known ports registry. Applications
>should use DNS SRV records for service location.
>
>
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


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



From owner-netconf@ops.ietf.org Sat Mar 18 21:55:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo59-0004kw-Cn
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo56-00020h-VD
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKnz4-000P4Y-7j
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:49:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [213.165.64.20] (helo=mail.gmx.net)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <peter@peter-dambier.de>)
	id 1FKmDW-000Jab-TF
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 00:56:23 +0000
Received: (qmail invoked by alias); 19 Mar 2006 00:56:20 -0000
Received: from p54A7D93A.dip.t-dialin.net (EHLO peter-dambier.de) [84.167.217.58]
  by mail.gmx.net (mp039) with SMTP; 19 Mar 2006 01:56:20 +0100
X-Authenticated: #8956597
Message-ID: <441CAC2A.6010408@peter-dambier.de>
Date: Sun, 19 Mar 2006 01:56:10 +0100
From: Peter Dambier <peter@peter-dambier.de>
Reply-To:  peter@peter-dambier.de
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  ietf@ietf.org
CC:  iana@iana.org,  netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
References: <20060318142117.26d5ecb3.smb@cs.columbia.edu>	<70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <20060318155453.cedb01b7.smb@cs.columbia.edu>
In-Reply-To: <20060318155453.cedb01b7.smb@cs.columbia.edu>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168

Steven M. Bellovin wrote:
> On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
> <huitema@windows.microsoft.com> wrote:
> 
>>If there is a reserved range, then it
>>is easy to start dynamic allocation outside the range.
> 
> 
> Yes -- this is my point.  I don't care about Unix-style privileged
> ports (and have never liked them anyway), but putting most services
> outside the well-known dynamic range is a good idea.

Yes, I agree, http should never have been assigned port 80. Randomly
looking for ports would make a lot more fun.

Maybe it is archaic, that all operating systems treat ports below
1024 special. But still they do. A normal user cannot gain access
to these ports.

Windows?

Is just a randomly changeing mess of dynamic link libraries that is
permanently modified by applications, viruses and the so called
operating system proper. The api is kept a trade secret.

VM, MVS, BS2000, VMS, all flavours of Unix including Minix, MAC OS-X,
BSD and Linux treat ports below 1024 special.

Special ports are required by servers running on real operating
systems. A windows client might be the user of such a port but
not the server. Or do you want to install a "trunk monkey" on
every host who takes care of an emerging error window and gives
the mouse a push?

How about a portmapper. It works with NIS and NFS. Yes the
port mapper needs a reserved port too, but that is already
allocated. Portmapper is a security hole but so is a randomly
changeing mess of DLLs.

> 
>>Starting services quickly also helps with the "voluntary collisions"
>>between system services and applications, but is not foolproof. In any
>>case, it does not help with collisions between applications, e.g. two
>>applications trying to use the same port. What does help there is an
>>easily accessible registration system, so application developers can
>>easily "do the right thing", i.e. reserve a port and avoid collisions.
>>Note the emphasis on "easily accessible": if there are too many hoops to
>>jump through, the developers will likely just pick a number at random.
>>

The portmapper is such a registration system.

I guess the port 42 nameserver was very early allocated and it still
works nicely for me but that could not prevent a collision with the
peculiar use of port 42 by windows.

> 
> Right, though it's a delicate dancce.

I agree, and please keep http on port 80 :)

> 
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

Cheers
Peter nd Karin
-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/




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



From owner-netconf@ops.ietf.org Sat Mar 18 21:55:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo59-0004l8-GZ
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo57-00020i-34
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKnyf-000P2c-6l
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:49:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
Received: from [147.28.0.16] (helo=machshav.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <smb@cs.columbia.edu>)
	id 1FKiRq-0004os-K0
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 20:54:54 +0000
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 28DCEFB2D6;
	Sat, 18 Mar 2006 15:54:54 -0500 (EST)
Received: by berkshire.machshav.com (Postfix, from userid 54047)
	id 1010C3C036E; Sat, 18 Mar 2006 15:54:53 -0500 (EST)
Date: Sat, 18 Mar 2006 15:54:53 -0500
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: lear@cisco.com, ietf@ietf.org, iana@iana.org,
	lisa@osafoundation.org, netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
Message-Id: <20060318155453.cedb01b7.smb@cs.columbia.edu>
In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
References: <20060318142117.26d5ecb3.smb@cs.columbia.edu>
	<70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
Organization: Columbia University
X-Mailer: Sylpheed version 2.2.1 (GTK+ 2.8.11; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22

On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
<huitema@windows.microsoft.com> wrote:
> If there is a reserved range, then it
> is easy to start dynamic allocation outside the range.

Yes -- this is my point.  I don't care about Unix-style privileged
ports (and have never liked them anyway), but putting most services
outside the well-known dynamic range is a good idea.
> 
> Starting services quickly also helps with the "voluntary collisions"
> between system services and applications, but is not foolproof. In any
> case, it does not help with collisions between applications, e.g. two
> applications trying to use the same port. What does help there is an
> easily accessible registration system, so application developers can
> easily "do the right thing", i.e. reserve a port and avoid collisions.
> Note the emphasis on "easily accessible": if there are too many hoops to
> jump through, the developers will likely just pick a number at random.
> 
Right, though it's a delicate dancce.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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



From owner-netconf@ops.ietf.org Sat Mar 18 21:55:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo5A-0004lP-9s
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo57-00020l-Np
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKnxj-000P0T-RV
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:48:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [131.107.3.125] (helo=mail1.microsoft.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <huitema@windows.microsoft.com>)
	id 1FKgPS-000M7K-WB
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 18:44:19 +0000
Received: from mail2.microsoft.com ([157.54.63.12]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);
	 Sat, 18 Mar 2006 10:44:18 -0800
Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 10:44:18 -0800
Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 10:44:17 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 10:44:17 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 10:44:16 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Guidance needed on well known ports
Date: Sat, 18 Mar 2006 10:44:13 -0800
Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640A1F36@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <441C457D.5080900@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZKsuzpXd2hokW4SGKeFqf+UVLrqAAB947Q
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Eliot Lear" <lear@cisco.com>,
	"IETF Discussion" <ietf@ietf.org>
Cc: "IANA" <iana@iana.org>,
	"Lisa Dusseault" <lisa@osafoundation.org>,
	"netconf" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 18 Mar 2006 18:44:16.0076 (UTC) FILETIME=[F54298C0:01C64ABB]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

>    1. Are well known ports archaic?  If so, can we request that the
IANA
>       do away with the distinction?

I don't know whether I would use the word "archaic", but the distinction
between < 1024 and >=3D 1024 is certainly Unix-specific. In the Windows
operating systems, the port range 1-1023 is not special. Some Windows OS
services use low port numbers, but not all. UPNP, for example, uses
ports 1900 and 2500; the RPC applications use dynamic port numbers.


>    2. If they are not archaic, under what circumstances should they be
>       allocated?

I have no problem with the current system.

-- Christian Huitema



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



From owner-netconf@ops.ietf.org Sat Mar 18 21:55:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo5C-0004n3-B1
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo58-00020n-Lt
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKnys-000P3W-QO
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:49:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0
Received: from [65.205.251.75] (helo=robin.verisign.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <pbaker@verisign.com>)
	id 1FKjcU-0009VE-UO
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 22:09:59 +0000
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34])
	by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k2IM9mg5011551;
	Sat, 18 Mar 2006 14:09:49 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 14:09:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Guidance needed on well known ports
Date: Sat, 18 Mar 2006 14:09:47 -0800
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0011_01C64AAE.C23D25B0"
Message-ID: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZKwU/Qo74tZFzATFWceMULjBW7IAACX6yAAAM0khA=
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: <iana@iana.org>, <netconf@ops.ietf.org>, <ietf@ietf.org>, <lear@cisco.com>,
        <lisa@osafoundation.org>
X-OriginalArrivalTime: 18 Mar 2006 22:09:48.0367 (UTC) FILETIME=[ABE0DDF0:01C64AD8]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C64AAE.C23D25B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The whole idea of fixed ports is broken.

The idea that there are only 1024 or even 65535 Internet applications is
broken. 

The Internet has a signalling layer, the DNS. Applications should use it.
The SRV record provides an infinitely extensible mechanism for advertising
ports.

Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be
well advised to pay careful attention to that restriction. SRV ports work
just fine behind a NAT.


IANA should be told to close the well known ports registry. Applications
should use DNS SRV records for service location.




------=_NextPart_000_0011_01C64AAE.C23D25B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw
ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE
AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV
BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V
0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T
Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID
AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB
BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid
MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7
D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh
leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF
ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv
cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1
OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl
cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl
cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX
Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1
huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA
AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f
BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v
dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB
BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY
rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF
Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3
DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT
M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG
A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy
MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT
M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG
A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5
wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv
1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA
mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX
rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC
A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL
E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP
bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+
4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC
AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB
hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud
HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3
DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9
juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa
zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN
BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs
YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw
RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1
kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6
cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud
EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw
DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr
oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF
AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw
Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb
6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI
hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy
IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI
VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr
ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF
Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq
di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud
HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj
aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh
a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT
aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu
IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF
BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU
uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA
HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB
MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs
b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTgyMjA5NDdaMCMGCSqGSIb3DQEJBDEWBBQA
0mg7Ie2niul6Cerq9Au8jDDzJzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa
MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK
BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E
pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg
Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYDORbizYQwI6wppKNF69kTtskOT
cnnliuXn3XDo2IPyV4aFntgsPV0uM7pXx7Dez/trBgOdY116MJxQjLvmdiPWrpN0dYGb3D7AYTrY
ZIUIoMD/Rgl7e84ZP/a1mzadUHgX74RHy0o9J7H2FrYbil0e3sFX+d4SzablPCOI01pOmQAAAAAA
AA==

------=_NextPart_000_0011_01C64AAE.C23D25B0--



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



From owner-netconf@ops.ietf.org Sat Mar 18 21:55:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo5G-0004ol-KQ
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo5E-00021J-W3
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:55:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKnyT-000P28-Th
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:48:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [131.107.3.125] (helo=mail1.microsoft.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <huitema@windows.microsoft.com>)
	id 1FKiFl-000437-Jk
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 20:42:25 +0000
Received: from mail2.microsoft.com ([157.54.63.12]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);
	 Sat, 18 Mar 2006 12:42:25 -0800
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 12:42:24 -0800
Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 12:42:24 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 12:42:23 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 18 Mar 2006 12:42:22 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Guidance needed on well known ports
Date: Sat, 18 Mar 2006 12:41:25 -0800
Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640A1F44@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <20060318142117.26d5ecb3.smb@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZKwU/Qo74tZFzATFWceMULjBW7IAACX6yA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: <lear@cisco.com>,
	<ietf@ietf.org>,
	<iana@iana.org>,
	<lisa@osafoundation.org>,
	<netconf@ops.ietf.org>
X-OriginalArrivalTime: 18 Mar 2006 20:42:22.0616 (UTC) FILETIME=[752AC980:01C64ACC]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

> A more interesting question is this: what are the odds that a user
> process will accidentally grab the port number before the system
> process gets to it?  The notion of a "privileged" port number is
> certainly preposterous; that said, putting services in a range that
> ordinary applications tend not to use has its merits.

There are two issues there, accidental collision between a dynamic port
and a service port, and "voluntary" collision between applications
trying to open the same port.=20

The practical solution to the first problem are to start services and
grab ports as part of the boot sequence, i.e. before user processes
start, and start dynamic allocations at some high number (e.g. larger
than 1024 or larger than 4096 or some admin defined value depending on
system version and configuration). If there is a reserved range, then it
is easy to start dynamic allocation outside the range.

Starting services quickly also helps with the "voluntary collisions"
between system services and applications, but is not foolproof. In any
case, it does not help with collisions between applications, e.g. two
applications trying to use the same port. What does help there is an
easily accessible registration system, so application developers can
easily "do the right thing", i.e. reserve a port and avoid collisions.
Note the emphasis on "easily accessible": if there are too many hoops to
jump through, the developers will likely just pick a number at random.

-- Christian Huitema




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



From owner-netconf@ops.ietf.org Sat Mar 18 21:56:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKo5T-0004t2-2l
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:56:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKo5S-00021Y-Pq
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 21:56:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKny3-000P19-Q1
	for netconf-data@psg.com; Sun, 19 Mar 2006 02:48:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
Received: from [147.28.0.16] (helo=machshav.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <smb@cs.columbia.edu>)
	id 1FKgzH-000OqD-9R
	for netconf@ops.ietf.org; Sat, 18 Mar 2006 19:21:19 +0000
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 0B159FB2C4;
	Sat, 18 Mar 2006 14:21:19 -0500 (EST)
Received: by berkshire.machshav.com (Postfix, from userid 54047)
	id C48883C036E; Sat, 18 Mar 2006 14:21:17 -0500 (EST)
Date: Sat, 18 Mar 2006 14:21:17 -0500
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: lear@cisco.com, ietf@ietf.org, iana@iana.org,
	lisa@osafoundation.org, netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
Message-Id: <20060318142117.26d5ecb3.smb@cs.columbia.edu>
In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640A1F36@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
References: <441C457D.5080900@cisco.com>
	<70C6EFCDFC8AAD418EF7063CD132D0640A1F36@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
Organization: Columbia University
X-Mailer: Sylpheed version 2.2.1 (GTK+ 2.8.11; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

On Sat, 18 Mar 2006 10:44:13 -0800, "Christian Huitema"
<huitema@windows.microsoft.com> wrote:

> >    1. Are well known ports archaic?  If so, can we request that the
> IANA
> >       do away with the distinction?
> 
> I don't know whether I would use the word "archaic", but the distinction
> between < 1024 and >= 1024 is certainly Unix-specific. In the Windows
> operating systems, the port range 1-1023 is not special. Some Windows OS
> services use low port numbers, but not all. UPNP, for example, uses
> ports 1900 and 2500; the RPC applications use dynamic port numbers.

A more interesting question is this: what are the odds that a user
process will accidentally grab the port number before the system
process gets to it?  The notion of a "privileged" port number is
certainly preposterous; that said, putting services in a range that
ordinary applications tend not to use has its merits.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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



From owner-netconf@ops.ietf.org Sat Mar 18 23:30:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKpZB-0007YW-CR
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 23:30:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKpZA-0004yF-32
	for netconf-archive@lists.ietf.org; Sat, 18 Mar 2006 23:30:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKpTW-00042y-5o
	for netconf-data@psg.com; Sun, 19 Mar 2006 04:25:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE 
	autolearn=no version=3.1.0
Received: from [158.38.152.233] (helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <harald@alvestrand.no>)
	id 1FKpTT-00042B-LY
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 04:25:03 +0000
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id D1FA62596CD;
	Sun, 19 Mar 2006 05:23:17 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
 by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 18918-04; Sun, 19 Mar 2006 05:23:13 +0100 (CET)
Received: from [130.129.129.255] (unknown [130.129.129.255])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B9515259748;
	Sun, 19 Mar 2006 05:23:09 +0100 (CET)
Message-ID: <441CDD00.60704@alvestrand.no>
Date: Sun, 19 Mar 2006 05:24:32 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
Cc: IETF Discussion <ietf@ietf.org>, IANA <iana@iana.org>,
	netconf <netconf@ops.ietf.org>,
	Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Guidance needed on well known ports
References: <441C457D.5080900@cisco.com>
In-Reply-To: <441C457D.5080900@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

>
> This therefore leads to two questions for the community:
>
>    1. Are well known ports archaic?  If so, can we request that the IANA
>       do away with the distinction?
>    2. If they are not archaic, under what circumstances should they be
>       allocated?
My opinion:

they are archaic and should be dropped. A number is a number, and the 
Unix "protection" policy has led directly to security exploits because 
processes were running as root because they "had to" in order to open a 
low port number.

That said - we need advice on, and probably a distinction between, 
"dynamic" ports and "ports that you get by asking for them".
OSes may also want to attach specific ACLs to specific ports on specific 
systems - but that's outside of what the IETF has traditionally set 
standards for.

My short term advice to netconf:

Flip a coin. Heads, go for a system port. Tails, go for a well known 
port. It's more important to get past the issue than what you decide.

My two cents.

                  Harald



--
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 Mar 19 00:50:05 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKqnl-000860-GA
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 00:50:05 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKqnk-0007VV-63
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 00:50:05 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKqi3-0002yw-2y
	for netconf-data@psg.com; Sun, 19 Mar 2006 05:44:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.161] (helo=ihemail1.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FKqi2-0002yj-C7
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 05:44:10 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2J5hvY2017408;
	Sat, 18 Mar 2006 23:43:57 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <G3YW6LQ3>; Sun, 19 Mar 2006 06:43:55 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E2117@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
        "'Steve Moulton'"
	 <moulton@snmp.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Andy Bierman <ietf@andybierman.com>
Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar
	 d [I06-051127-0011] 
Date: Sun, 19 Mar 2006 06:43:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

> 
> Netconf is at best a 'niche' protocol at present, because:
> 
> (a) Netconf currently has no standard data models
> 
> (b) Netconf currently is intended for use only with routers and
>     other intermediate network elements
> 
> (c) Netconf operations have fuzzy semantics, due to the lack of any
>     standard data models (e.g., "merge this blob with that blob")
> 
> Therefore, Netconf in not plausibly a critical system service.
> 
> An IANA-assigned "Registered Port" (greater than 1024) is appropriate.
> 
> The argument that user processes may pre-bind the Netconf port applies
> equally to an IANA-assigned "Well Known Port" (less than 1024).
> 
> I encourage the IETF ADs to intervene here and provide direction.
> 

The direction is that:

- The IESG is OK if the WG wants system ports if they have some 
  reasonable argument to request so. The stronger the argument,
  the better.  But a reasonable argument is OK.
- I think the arguments I have seen pro and against sofar make me
  tend to agree with selecting <1024. They seem at least reasonable.
  (I am in the air right now, so I can only comment as to what I have seen
  up till now).
- I have seen arguments for using ports above 1024 too. 
  they are OK but I do not find them as convincing (yet) as the ones
  in favor fo <1024.
- I have not seen arguments that point out a fatal problem if we
  assign below 1024.
- I find it important that people who have implented (or are implementing)
  or those who plan to deploy now or within a year are speaking up. Their
  view counts heavily as far as I am concerned.

Hope this helps,
Bert (speaking as AD)

> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

--
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 Mar 19 06:48:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKwOA-0002cd-NL
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 06:48:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKwO8-0007Ha-CD
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 06:48:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKwDq-000CWJ-MI
	for netconf-data@psg.com; Sun, 19 Mar 2006 11:37:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [160.36.56.221] (helo=ka.cs.utk.edu)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <moore@cs.utk.edu>)
	id 1FKnMm-000NBY-Cw
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 02:10:00 +0000
Received: from localhost (ka [127.0.0.1])
	by ka.cs.utk.edu (Postfix) with ESMTP id E2C1523520;
	Sat, 18 Mar 2006 21:09:57 -0500 (EST)
Received: from ka.cs.utk.edu ([127.0.0.1])
 by localhost (ka [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 30994-03; Sat, 18 Mar 2006 21:09:54 -0500 (EST)
Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182])
	by ka.cs.utk.edu (Postfix) with ESMTP id 3A25123514;
	Sat, 18 Mar 2006 21:09:53 -0500 (EST)
Message-ID: <441CBD6F.6070505@cs.utk.edu>
Date: Sat, 18 Mar 2006 21:09:51 -0500
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
CC: Christian Huitema <huitema@windows.microsoft.com>, 
 "Steven M. Bellovin" <smb@cs.columbia.edu>,
  lisa@osafoundation.org,  iana@iana.org,  ietf@ietf.org,  lear@cisco.com, 
 netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
References: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
In-Reply-To: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

> The whole idea of fixed ports is broken.
> 
> The idea that there are only 1024 or even 65535 Internet applications is
> broken. 

agree with you so far.

> The Internet has a signalling layer, the DNS. Applications should use it.

strongly disagree.  DNS is a huge mess.  It is slow and unreliable.  In 
practice it is often inconsistent both from one query location to 
another and with reality.

only the host knows which application is listening on which port.  if 
there is going to be a layer of indirection between service name and 
service selector, it's extremely bad design to put that layer of 
indirection external to the host that's providing the service.  (now if 
you want to argue that an architecture really needs to support clusters 
of hosts all providing the same service, I'd agree, but DNS is still not 
a good way to do this.)

> The SRV record provides an infinitely extensible mechanism for advertising
> ports.

yes, and is not backward compatible with most applications.  also, for 
some reason, few new applications want to use it.

> Fixed ports do not work behind NAT. 

irrelevant.  lots of things do not work behind NAT.  NATs are inherently 
broken and cannot be fixed.  they are an architectural dead end.





--
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 Mar 19 06:48:05 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKwOD-0002dG-TL
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 06:48:05 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKwOC-0007Hf-KE
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 06:48:05 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FKwDy-000CWj-N7
	for netconf-data@psg.com; Sun, 19 Mar 2006 11:37:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [128.9.64.64] (helo=vapor.isi.edu)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <touch@ISI.EDU>)
	id 1FKteJ-0004V6-7A
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 08:52:31 +0000
Received: from [128.9.176.73] ([128.9.176.73])
	by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2J8pUw29936;
	Sun, 19 Mar 2006 00:51:30 -0800 (PST)
Message-ID: <441D1B8B.4060502@isi.edu>
Date: Sun, 19 Mar 2006 00:51:23 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
CC: Christian Huitema <huitema@windows.microsoft.com>,
   "Steven M. Bellovin" <smb@cs.columbia.edu>, lisa@osafoundation.org,
   iana@iana.org, ietf@ietf.org, lear@cisco.com, netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
References: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
In-Reply-To: <198A730C2044DE4A96749D13E167AD3797D6B1@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228



Hallam-Baker, Phillip wrote:
> The whole idea of fixed ports is broken.
...
> The Internet has a signalling layer, the DNS. Applications should use it.
> The SRV record provides an infinitely extensible mechanism for advertising
> ports.

And with what port would I reach this magical DNS that would provide the
SRV record for the DNS itself?

> Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be
> well advised to pay careful attention to that restriction. SRV ports work
> just fine behind a NAT.

Except that many NATs also intercept DNS requests and redirect them to
their own servers, for their own purposes, which can interfere with SRV
records (by design).

The only thing that works fine behind a NAT is what the NAT vendor wants
to work fine. Everything else is up for grabs.

Joe



--
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 Mar 19 12:36:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL1p6-0004jp-9R
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 12:36:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL1p4-0002ld-PT
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 12:36:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FL1jM-0009zk-Lk
	for netconf-data@psg.com; Sun, 19 Mar 2006 17:30:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [217.12.11.63] (helo=smtp009.mail.ukl.yahoo.com)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <vincent.cridlig@loria.fr>)
	id 1FL1jL-0009zO-EY
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 17:30:15 +0000
Received: (qmail 16981 invoked from network); 19 Mar 2006 17:30:12 -0000
Received: from unknown (HELO ?192.168.0.2?) (cridligv@212.195.132.152 with plain)
  by smtp009.mail.ukl.yahoo.com with SMTP; 19 Mar 2006 17:30:11 -0000
Message-ID: <441D95D3.1090603@loria.fr>
Date: Sun, 19 Mar 2006 18:33:07 +0100
From: Cridlig Vincent <vincent.cridlig@loria.fr>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: Problem of XML validation
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

Hi,

This is to report a possible issue in the Netconf XML schema. I try to 
validate a simple get-config message but I get some errors.
I use the Netconf schema and some sample messages from draft 12.
I tested two "standard" XML schema validator implementations:
- the one from the C library libxml2
- the one from the Java library JAXP.
Twice, I got the result that the <filter> element should be empty.

I think the problem comes from the following complexType. It is the 
exact definition of an empty element.
See http://www.w3schools.com/schema/schema_complex_empty.asp

<xs:complexType name="filterInlineType">
  <xs:complexContent>
    <xs:restriction base="xs:anyType">
      <xs:attribute name="type" type="FilterType" default="subtree"/>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

I changed it to the following :

<xs:complexType name="filterInlineType">
  <xs:complexContent>
    <xs:restriction base="xs:anyType">
      <xs:sequence>
        <xs:any processContents="skip"/>
      </xs:sequence>
      <xs:attribute name="type" type="FilterType" default="subtree"/>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

I put processContents="skip" to not validate the content, especially because a subtree filter may be correct but not xml valid.
But now the problem is that it does not allow text content, only elements (like top). This is a problem for xpath capabilities.
I don't know how to solve it.

Does somebody experiment the same problems ?

Best regards,
Vincent



	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com


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



From owner-netconf@ops.ietf.org Sun Mar 19 15:09:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL4Dk-0007aD-Es
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 15:09:48 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL4Di-0008V2-UQ
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 15:09:48 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FL49e-000K3d-Ms
	for netconf-data@psg.com; Sun, 19 Mar 2006 20:05:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FL49d-000K3P-9Y
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 20:05:33 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 765E04D3BF;
	Sun, 19 Mar 2006 21:05:32 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 32706-08; Sun, 19 Mar 2006 21:05:30 +0100 (CET)
Received: from boskop.local (unknown [10.222.1.4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id AED7A4D340;
	Sun, 19 Mar 2006 21:05:30 +0100 (CET)
Received: by boskop.local (Postfix, from userid 501)
	id BA5276355E1; Sun, 19 Mar 2006 21:05:28 +0100 (CET)
Date: Sun, 19 Mar 2006 21:05:28 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "McDonald, Ira" <imcdonald@sharplabs.com>,
	"'Joel M. Halpern'" <joel@stevecrocker.com>,
	Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: Re: use of netconf to configure Unix systems
Message-ID: <20060319200528.GF1286@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"McDonald, Ira" <imcdonald@sharplabs.com>,
	"'Joel M. Halpern'" <joel@stevecrocker.com>,
	Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
References: <CFEE79A465B35C4385389BA5866BEDF00C7FBF@mailsrvnt02.enet.sharplabs.com> <441C4A7E.2000409@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <441C4A7E.2000409@andybierman.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

On Sat, Mar 18, 2006 at 09:59:26AM -0800, Andy Bierman wrote:
 
> Either the assignment range matters, in which case I believe there
> is sufficient justification to ask for well known port numbers for
> NETCONF, or the assignment range doesn't matter, and therefore all
> new static ports are registered ports.  I can live with either
> decision, but I would prefer an actual IESG decision in this matter.

I have no strong opinion. In principle, I would prefer a port < 1024
(since I am biased to Unix like systems ;-). The only thing that
scares me is that we would have to request three TCP ports, which I
find a bit costly given the fact that it is unclear whether some of
the transport mappings will see much deployment.

What about the following solution:

a) A port number < 1024 is assigned to the NETCONF/SSH transport
   mapping since this is the default mapping everybody has to support.

b) Two port numbers > 1024 are assigned to he BEEP and SOAP mapping,
   which are both optional transport mappings.

Sure, this solution is at odds with the argument for having a port <
1024 in the first place. But it keeps some economy with using special
port numbers.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Sun Mar 19 17:02:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL5yc-0000aT-4z
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 17:02:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL5ya-0004Kr-RK
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 17:02:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FL5tk-0001Ef-J0
	for netconf-data@psg.com; Sun, 19 Mar 2006 21:57:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.163] (helo=ihemail2.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FL5tj-0001ET-Pr
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 21:57:15 +0000
Received: from ihemail1.lucent.com (h192-11-222-161.lucent.com [192.11.222.161])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2JLvB4f023590;
	Sun, 19 Mar 2006 15:57:12 -0600 (CST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2JLv9tF011734;
	Sun, 19 Mar 2006 15:57:10 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <G3YW6QQG>; Sun, 19 Mar 2006 22:57:07 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E22FA@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
        "'Joel M. Halpern'"
	 <joel@stevecrocker.com>,
        Andy Bierman <ietf@andybierman.com>
Cc: Eliot Lear <lear@cisco.com>, netconf <netconf@ops.ietf.org>
Subject: RE: use of netconf to configure Unix systems
Date: Sun, 19 Mar 2006 22:56:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

w.r.t.

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of McDonald, Ira
> Sent: Saturday, March 18, 2006 10:35
> To: 'Joel M. Halpern'; Andy Bierman
> Cc: Eliot Lear; netconf
> Subject: RE: use of netconf to configure Unix systems
> 
> 
> Hi Joel,
> 
> +1
> 
> If Netconf really wants a "Well Known Port", then OK, let's
> move on.
> 
> But it really is distressing that the IESG takes no active
> part (apparently) in setting and enforcing policies for the
> use of the remainder of this scarce resource.
> 

The IESG does take part in that we have stated that we want some
plausable arguments if you want a port <1024. 
So the answer: we trew a coin is not acceptable.

Bert 

--
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 Mar 19 17:43:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL6c9-0003Ja-Ar
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 17:43:09 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL6c7-000695-T0
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 17:43:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FL6Y3-0003iT-HU
	for netconf-data@psg.com; Sun, 19 Mar 2006 22:38:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0
Received: from [65.205.251.75] (helo=robin.verisign.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <pbaker@verisign.com>)
	id 1FL4c4-000LkO-GE
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 20:34:56 +0000
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34])
	by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k2JKYcVG018507;
	Sun, 19 Mar 2006 12:34:38 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Sun, 19 Mar 2006 12:34:37 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Guidance needed on well known ports
Date: Sun, 19 Mar 2006 12:34:36 -0800
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0000_01C64B6A.A0E3FB70"
Message-ID: <198A730C2044DE4A96749D13E167AD3797D6B7@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZLMm465LqnurmYTci+ySKKM+YcLAAYY1QA
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "Joe Touch" <touch@ISI.EDU>
Cc: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Steven M. Bellovin" <smb@cs.columbia.edu>, <lisa@osafoundation.org>,
        <iana@iana.org>, <ietf@ietf.org>, <lear@cisco.com>,
        <netconf@ops.ietf.org>
X-OriginalArrivalTime: 19 Mar 2006 20:34:37.0948 (UTC) FILETIME=[8A9DD3C0:01C64B94]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C64B6A.A0E3FB70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


> From: Joe Touch [mailto:touch@ISI.EDU] 

> And with what port would I reach this magical DNS that would 
> provide the SRV record for the DNS itself?

You use fixed ports for the bootstrap process and only for the bootstrap
process.



> > Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 
> > would be well advised to pay careful attention to that restriction. 
> > SRV ports work just fine behind a NAT.
> 
> Except that many NATs also intercept DNS requests and 
> redirect them to their own servers, for their own purposes, 
> which can interfere with SRV records (by design).

People who do this are rarely trying to break things. T


> The only thing that works fine behind a NAT is what the NAT 
> vendor wants to work fine. Everything else is up for grabs.

The NAT vendors would like their systems to work as well as possible. If
there had been less hostility to the idea and less determination to ensure
IPv4 actually broke thus forcing deployment of IPv6 this could have worked.

------=_NextPart_000_0000_01C64B6A.A0E3FB70
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw
ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE
AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV
BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V
0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T
Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID
AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB
BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid
MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7
D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh
leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF
ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv
cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1
OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl
cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl
cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX
Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1
huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA
AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f
BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v
dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB
BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY
rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF
Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3
DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT
M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG
A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy
MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT
M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG
A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5
wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv
1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA
mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX
rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC
A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL
E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP
bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+
4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC
AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB
hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud
HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3
DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9
juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa
zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN
BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs
YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw
RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1
kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6
cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud
EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw
DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr
oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF
AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw
Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb
6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI
hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy
IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI
VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr
ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF
Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq
di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud
HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj
aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh
a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT
aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu
IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF
BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU
uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA
HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB
MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs
b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTkyMDM0MzZaMCMGCSqGSIb3DQEJBDEWBBTz
KQWoEKWYT98TqPbJBgTTeuntuTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa
MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK
BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E
pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg
Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAJCxbVfFV3boBXRWgIq9ZkCIEq
Pb3wEiz7NSCD7Esr3+1qiQszGDfStPl6hN+h7SzWcMwpjRrGwc07/RjUsm75/IGjFpUt+2CJOQ+S
0JuFKMGzwClauTgYsluReFKo3j3c3f2pilp8dXzopXCyw/Z8Wq8N5RjIXjarAjtsQHGPhQAAAAAA
AA==

------=_NextPart_000_0000_01C64B6A.A0E3FB70--



--
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 Mar 19 20:57:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL9e9-0005il-6w
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 20:57:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL9e7-00047d-TK
	for netconf-archive@lists.ietf.org; Sun, 19 Mar 2006 20:57:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FL9Vg-000GmM-Cf
	for netconf-data@psg.com; Mon, 20 Mar 2006 01:48:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <brc@zurich.ibm.com>)
	id 1FL6JU-0002qn-7p
	for netconf@ops.ietf.org; Sun, 19 Mar 2006 22:23:52 +0000
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k2JMNoTJ054798
	for <netconf@ops.ietf.org>; Sun, 19 Mar 2006 22:23:50 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2JMOCuo223234
	for <netconf@ops.ietf.org>; Sun, 19 Mar 2006 22:24:12 GMT
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k2JMNnmI005185
	for <netconf@ops.ietf.org>; Sun, 19 Mar 2006 22:23:49 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k2JMNmGf005180;
	Sun, 19 Mar 2006 22:23:48 GMT
Received: from zurich.ibm.com (sig-9-146-220-162.de.ibm.com [9.146.220.162])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA38036;
	Sun, 19 Mar 2006 23:23:46 +0100
Message-ID: <441DD9F1.1060804@zurich.ibm.com>
Date: Sun, 19 Mar 2006 23:23:45 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: IETF Discussion <ietf@ietf.org>, IANA <iana@iana.org>,
        Lisa Dusseault <lisa@osafoundation.org>,
        netconf <netconf@ops.ietf.org>
Subject: Re: Guidance needed on well known ports
References: <441C457D.5080900@cisco.com>
In-Reply-To: <441C457D.5080900@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

Regardless of what the community consensus is on:

>    1. Are well known ports archaic?

I want to comment that on this:

>  If so, can we request that the IANA
>       do away with the distinction?

The IETF decides, and the IANA will then be responsible for implementing the decision.

    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 Mar 20 05:56:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLI3l-0006U8-LA
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 05:56:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLI3k-0005UX-7O
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 05:56:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLHwZ-000Gdu-ES
	for netconf-data@psg.com; Mon, 20 Mar 2006 10:48:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FLHwY-000Gdd-IB
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 10:48:58 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C0F64F0003
	for <netconf@ops.ietf.org>; Mon, 20 Mar 2006 11:48:57 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 20 Mar 2006 11:48:57 +0100
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 20 Mar 2006 11:48:57 +0100
Message-ID: <441E8898.8060408@ericsson.com>
Date: Mon, 20 Mar 2006 11:48:56 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: netconf <netconf@ops.ietf.org>
Subject: Re: Guidance needed on well known ports
References: <441C457D.5080900@cisco.com> <441CDD00.60704@alvestrand.no>
In-Reply-To: <441CDD00.60704@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Mar 2006 10:48:57.0083 (UTC) FILETIME=[E3711CB0:01C64C0B]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

We seem to agree that the choice of port range is not the most important item for Netconf. 
So anything is OK but decide fast. Maybe the chairman can just decide this or have a vote 
till today midnight.
Balazs

Harald Alvestrand wrote:
> 
> My short term advice to netconf:
> 
> Flip a coin. Heads, go for a system port. Tails, go for a well known 
> port. It's more important to get past the issue than what you decide.
> 
> My two cents.
> 
>                  Harald
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Mon Mar 20 06:00:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLI7L-0001bJ-JG
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 06:00:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLI7L-0005fd-3Q
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 06:00:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLI2G-000H2v-BO
	for netconf-data@psg.com; Mon, 20 Mar 2006 10:54:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FLI2F-000H2j-Bt
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 10:54:51 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 826A6DDF;
	Mon, 20 Mar 2006 11:54:50 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 20 Mar 2006 11:54:50 +0100
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 20 Mar 2006 11:54:50 +0100
Message-ID: <441E89F9.2070509@ericsson.com>
Date: Mon, 20 Mar 2006 11:54:49 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Informal Issue summary for Netconf Notification
References: <713043CE8B8E1348AF3C546DBE02C1B407684242@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407684242@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Mar 2006 10:54:50.0065 (UTC) FILETIME=[B5D5E410:01C64C0C]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81

Hello Sharon,
I think some guidelines about this question should be included in the notifications draft 
so people understand the situation the possibilities and the consequences. We can argue 
whether they should be in the main part or an Annex.

Balazs

Sharon Chisholm wrote:
> hi
> 
> Well, I would say it isn't a gating problem, because people can choose
> to use separate sessions if they think the command will take a long
> time. It's a reasonable workaround since I don't think configuration
> connections would be as long lived.
> 
> The problem could be solved via some sort of fragmentation mechanism for
> large commands, but I don't think we need it yet. Retrieving active
> alarm list is an interesting case where you would want them to be on the
> session, but we have an event-replay mechanism where this isn't a
> problem.
> 
> If resources are tight and they really only want one connection, then
> multiple channel support seems to be the better solution.
> 
> Sharon
> 
> -----Original Message-----
> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] 
> Sent: Friday, March 17, 2006 10:54 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Subject: Re: Informal Issue summary for Netconf Notification
> 
> 
> Sharon,
> Someone voiced the concern that if we have only a single channel and use
> the same Netconf 
> connection for both configuration and notifications then a big response
> to a <get> 
> operation might block notifications for considerable time.
> What is the solution?
> - You don't think this is a problem
> - it is recommended to use separate Netconf connections
> - multi-channel
> - the problem is not a real problem because ???
> - else
> 
> regards Balazs
> 
> Sharon Chisholm wrote:
>> 3)	Multiple-channel support: seem to have consensus to defer
>>
>   > Sharon Chisholm
>> Nortel
>> Ottawa, Ontario
>> Canada
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> 
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Mon Mar 20 07:53:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLJtA-0001qB-Lq
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 07:53:36 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLJt8-0000Ea-Lf
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 07:53:36 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLJnW-000NyZ-OL
	for netconf-data@psg.com; Mon, 20 Mar 2006 12:47:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [64.40.109.249] (helo=newqwak1.roomlinx.com)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <touch@isi.edu>)
	id 1FLCWo-0001fW-0h
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 05:02:02 +0000
Received: (qmail 27288 invoked by uid 513); 20 Mar 2006 04:56:38 -0000
Received: from touch@isi.edu by qwak.roomlinx.com by uid 502 with qmail-scanner-1.22 
 (clamdscan: 0.74. spamassassin: 2.63.  Clear:RC:1(12.156.238.2):. 
 Processed in 0.038618 secs); 20 Mar 2006 04:56:38 -0000
Received: from unknown (HELO ?10.84.137.44?) (12.156.238.2)
  by newqwak1.roomlinx.com with SMTP; 20 Mar 2006 04:56:38 -0000
Message-ID: <441E372C.5080502@isi.edu>
Date: Sun, 19 Mar 2006 21:01:32 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To:  iana@iana.org,  ietf@ietf.org,  netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
References: <198A730C2044DE4A96749D13E167AD3797D6B7@MOU1WNEXMB04.vcorp.ad.vrsn.com>
In-Reply-To: <198A730C2044DE4A96749D13E167AD3797D6B7@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336



Hallam-Baker, Phillip wrote:
>> From: Joe Touch [mailto:touch@ISI.EDU] 
> 
>> And with what port would I reach this magical DNS that would 
>> provide the SRV record for the DNS itself?
> 
> You use fixed ports for the bootstrap process and only for the bootstrap
> process.

Which means that the DNS port needs to be well-known or fixed in advance.

Some other issues to be considered:

	- this change would make the DNS required for proper Internet
	operation, whereas it is currently optional (i.e., only for
	finding the IP address).]

	- hosts may run services but not have control over their own
	DNS entry (or SRV records)

	- firewalling based on ports would no longer be useful
	(one could argue it should not be, but that's a different issue)

>>> Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 
>>> would be well advised to pay careful attention to that restriction. 
>>> SRV ports work just fine behind a NAT.
>> Except that many NATs also intercept DNS requests and 
>> redirect them to their own servers, for their own purposes, 
>> which can interfere with SRV records (by design).
> 
> People who do this are rarely trying to break things.

They don't *try* to break things, but then tend to. ;-)

As to 'by design', they're not so much trying to break as to 'help'
(usually for their own purposes).

Joe



--
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 Mar 20 08:57:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLKsr-0005s5-5m
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 08:57:21 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLKsp-0002pC-Rj
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 08:57:21 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLKoU-0002Ku-JC
	for netconf-data@psg.com; Mon, 20 Mar 2006 13:52:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FLKoS-0002KV-21
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 13:52:48 +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 k2KDq8X77650;
	Mon, 20 Mar 2006 05:52:08 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2KDq3547703;
	Mon, 20 Mar 2006 05:52:03 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2KDvGYE005342;
	Mon, 20 Mar 2006 08:57:16 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603201357.k2KDvGYE005342@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: Sharon Chisholm <schishol@nortel.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Informal Issue summary for Netconf Notification 
In-Reply-To: Your message of "Mon, 20 Mar 2006 11:54:49 +0100."
             <441E89F9.2070509@ericsson.com> 
Date: Mon, 20 Mar 2006 08:57:16 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

Balazs Lengyel writes:
>I think some guidelines about this question should be included in the notifications draft 
>so people understand the situation the possibilities and the consequences.

I just keep thinking about the times I need notifications while I'm
doing a non-instantaneous RPC, such as <commit-config>.  Having to
wait til the operation is done to see that my new igp config melted
my network might be a bad thing.

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 Mar 20 09:19:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLLEd-0001m9-4Y
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 09:19:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLLEb-0003aI-Pg
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 09:19:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLLAx-0003rC-Io
	for netconf-data@psg.com; Mon, 20 Mar 2006 14:16:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FLLAw-0003qz-Mp
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 14:16:02 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2KEG1hB014775
	for <netconf@ops.ietf.org>; Mon, 20 Mar 2006 09:16:01 -0500
Received: (qmail 27992 invoked from network); 20 Mar 2006 14:16:00 -0000
Received: from unknown (HELO ?130.129.132.197?) (130.129.132.197)
  by omr3.mgt.bos.netsol.com with SMTP; 20 Mar 2006 14:16:00 -0000
Message-ID: <441EB921.6020005@andybierman.com>
Date: Mon, 20 Mar 2006 06:16:01 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Informal Issue summary for Netconf Notification
References: <200603201357.k2KDvGYE005342@idle.juniper.net>
In-Reply-To: <200603201357.k2KDvGYE005342@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

Phil Shafer wrote:
> Balazs Lengyel writes:
>   
>> I think some guidelines about this question should be included in the notifications draft 
>> so people understand the situation the possibilities and the consequences.
>>     
>
> I just keep thinking about the times I need notifications while I'm
> doing a non-instantaneous RPC, such as <commit-config>.  Having to
> wait til the operation is done to see that my new igp config melted
> my network might be a bad thing.
>   

One big concern I have with the Notification draft is whether the 
inherent complexity
is warranted for the specific task at hand.   The first thing I notice 
is that there
aren't any deployed solutions which send notifications and operations on the
same connection. 

I find very little established operational validity in the idea that 
this is even
a "nice to have" feature, let alone mandatory functionality.
The cost of an additional connection for notifications is trivial.
The notion that this "shared session" mechanism somehow obviates the 
need to do
event correlation is also flawed.   A well-designed manager needs
to account for notifications that its own direct actions did not cause
(e.g., the notion that of all the notifications that get generated after 
a <commit> are
related to that <commit> may be  incorrect).


Andy


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


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



From owner-netconf@ops.ietf.org Mon Mar 20 12:07:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLNqU-0006dG-92
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:07:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLNqP-000246-Su
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:07:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLNgy-0001i7-LM
	for netconf-data@psg.com; Mon, 20 Mar 2006 16:57:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FLNgx-0001hw-QS
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 16:57:16 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2KGqqA08445
	for <netconf@ops.ietf.org>; Mon, 20 Mar 2006 11:52:52 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Offline Netconf Notification Session - Dallas
Date: Mon, 20 Mar 2006 11:57:06 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4076F60B6@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Offline Netconf Notification Session - Dallas
Thread-Index: AcZMP1IHX7lYw0KMQbyvpEXlJhNeqg==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "netconf" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

hi

Anyone interested in getting together here in Dallas to discuss further
the Netconf Event Notification draft, please let me know.

I thought we could go through the issues list - not the one I sent, but
the longer one that Andy came presented in this morning's meeting - and
capture some pros and cons to each of the options. Open A is the
implementation from the draft and option B would be various hypothetical
design alternatives that have been raised.

Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

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



From owner-netconf@ops.ietf.org Mon Mar 20 12:14:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLNxa-0004nj-4e
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:14:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLNxY-0002I4-P6
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:14:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLNtd-0002Zn-9S
	for netconf-data@psg.com; Mon, 20 Mar 2006 17:10:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FLNtc-0002Za-Cc
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 17:10:20 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2KHAI4K011365
	for <netconf@ops.ietf.org>; Mon, 20 Mar 2006 12:10:18 -0500
Received: (qmail 12128 invoked from network); 20 Mar 2006 17:06:52 -0000
Received: from unknown (HELO ?130.129.132.197?) (130.129.132.197)
  by omr2.mgt.bos.netsol.com with SMTP; 20 Mar 2006 17:06:52 -0000
Message-ID: <441EE12D.7050408@andybierman.com>
Date: Mon, 20 Mar 2006 09:06:53 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: netconf <netconf@ops.ietf.org>
Subject: NETCONF Port Decision
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

Hi,

The WG met this morning and discussed the port assignments for the protocol.
The clear consensus in the room was that the WG should ask for well known
ports instead of registered ports.

If anyone wishes to strongly object to this decision,
then please send an email to the WG  mailing list by 12:00AM EST 3/22/06
demonstrating a "fatal flaw" in this decision.  (E.g.., why assigning
a well-known port instead of a registered port will harm the Internet).

The WG will ask for 4 ports:
   - NETCONF over SSH
   - NETCONF over BEEP
   - NETCONF over SOAP over BEEP
   - NETCONF over SOAP over HTTPS


Andy


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



From owner-netconf@ops.ietf.org Mon Mar 20 12:48:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLOUh-0002AG-GI
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:48:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLOUg-0003fD-6T
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:48:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLOQV-0004gq-Id
	for netconf-data@psg.com; Mon, 20 Mar 2006 17:44:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FLOQU-0004gf-To
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 17:44:18 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2KHiGbY010900;
	Mon, 20 Mar 2006 09:44:16 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDY59WC>; Mon, 20 Mar 2006 09:44:16 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FC4@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Andy Bierman'" <ietf@andybierman.com>, netconf <netconf@ops.ietf.org>
Subject: RE: NETCONF Port Decision
Date: Mon, 20 Mar 2006 09:44:07 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d

Hi Andy,

No objection, but clear WG concensus is NOT sufficient.
Bert Wijnen specifically asked for a technical justification
of the working group's decision - NOT just a decision.

[Also - small process thing - decisions in IETF WG's and on
their concensus happen _only_ on mailing lists, not in any
face-to-face meetings, per IETF Standards Process.]

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Monday, March 20, 2006 12:07 PM
> To: netconf
> Subject: NETCONF Port Decision
> 
> 
> Hi,
> 
> The WG met this morning and discussed the port assignments 
> for the protocol.
> The clear consensus in the room was that the WG should ask 
> for well known
> ports instead of registered ports.
> 
> If anyone wishes to strongly object to this decision,
> then please send an email to the WG  mailing list by 12:00AM 
> EST 3/22/06
> demonstrating a "fatal flaw" in this decision.  (E.g.., why assigning
> a well-known port instead of a registered port will harm the 
> Internet).
> 
> The WG will ask for 4 ports:
>    - NETCONF over SSH
>    - NETCONF over BEEP
>    - NETCONF over SOAP over BEEP
>    - NETCONF over SOAP over HTTPS
> 
> 
> Andy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.2.5/284 - Release 
> Date: 3/17/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006
 

--
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 Mar 20 12:57:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLOcs-00062E-HO
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:57:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLOcs-0003u3-8n
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 12:57:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLOZu-0005SG-BS
	for netconf-data@psg.com; Mon, 20 Mar 2006 17:54:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FLOZt-0005S4-Rk
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 17:54:01 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2KHrkQS011259;
	Mon, 20 Mar 2006 09:53:46 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HCDY597W>; Mon, 20 Mar 2006 09:53:47 -0800
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7FC7@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Joe Touch'" <touch@isi.edu>, iana@iana.org, ietf@ietf.org,
        netconf@ops.ietf.org
Subject: RE: Guidance needed on well known ports
Date: Mon, 20 Mar 2006 09:53:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

Joe Touch wrote on Monday 20 March 2006:
> 
> Hallam-Baker, Phillip wrote:
> >> From: Joe Touch [mailto:touch@ISI.EDU] 
> > 
> >> And with what port would I reach this magical DNS that would 
> >> provide the SRV record for the DNS itself?
> > 
> > You use fixed ports for the bootstrap process and only for 
> the bootstrap
> > process.
> 
> Which means that the DNS port needs to be well-known or fixed 
> in advance.
> 
> Some other issues to be considered:
> 
> 	- this change would make the DNS required for proper Internet
> 	operation, whereas it is currently optional (i.e., only for
> 	finding the IP address).]
> 

Zeroconf (which is widely deployed for ad-hoc networking and
SOHO networks) depends entirely on the premise that there is
NO available/configured DNS service.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006
 

--
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 Mar 20 15:27:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLQyK-0000p6-U7
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 15:27:24 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLQyK-0001yO-Hk
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 15:27:24 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLQrD-0007iH-5g
	for netconf-data@psg.com; Mon, 20 Mar 2006 20:20:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.161] (helo=ihemail1.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FLQrC-0007hr-Ch
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 20:20:02 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2KKJxID012709;
	Mon, 20 Mar 2006 14:20:00 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <G3YW71X6>; Mon, 20 Mar 2006 21:19:58 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509988199@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
        "'Andy Bierman'"
	 <ietf@andybierman.com>,
        netconf <netconf@ops.ietf.org>
Subject: RE: NETCONF Port Decision
Date: Mon, 20 Mar 2006 21:19:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86

Inline

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of McDonald, Ira
> Sent: Monday, March 20, 2006 11:44
> To: 'Andy Bierman'; netconf
> Subject: RE: NETCONF Port Decision
> 
> 
> Hi Andy,
> 
> No objection, but clear WG concensus is NOT sufficient.
> Bert Wijnen specifically asked for a technical justification
> of the working group's decision - NOT just a decision.
> 
My understaninding is that the WG chairs will be making asummary
of the arguments in favor of port <1024.

> [Also - small process thing - decisions in IETF WG's and on
> their concensus happen _only_ on mailing lists, not in any
> face-to-face meetings, per IETF Standards Process.]
> 

And that is exactly why Andy is veryfying this on the WG list
(to my understanding). 

Thanks,
Bert
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org 
[mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Monday, March 20, 2006 12:07 PM
> To: netconf
> Subject: NETCONF Port Decision
> 
> 
> Hi,
> 
> The WG met this morning and discussed the port assignments 
> for the protocol.
> The clear consensus in the room was that the WG should ask 
> for well known
> ports instead of registered ports.
> 
> If anyone wishes to strongly object to this decision,
> then please send an email to the WG  mailing list by 12:00AM 
> EST 3/22/06
> demonstrating a "fatal flaw" in this decision.  (E.g.., why assigning
> a well-known port instead of a registered port will harm the 
> Internet).
> 
> The WG will ask for 4 ports:
>    - NETCONF over SSH
>    - NETCONF over BEEP
>    - NETCONF over SOAP over BEEP
>    - NETCONF over SOAP over HTTPS
> 
> 
> Andy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.2.5/284 - Release 
> Date: 3/17/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006
 

--
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 Mar 20 15:58:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLRRw-0000ex-Pi
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 15:58:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLRRv-0003Hl-F8
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 15:58:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLRNq-000AD7-2B
	for netconf-data@psg.com; Mon, 20 Mar 2006 20:53:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FLRNp-000ACw-6N
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 20:53:45 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2KKrhQ3024947
	for <netconf@ops.ietf.org>; Mon, 20 Mar 2006 15:53:44 -0500
Received: (qmail 10646 invoked from network); 20 Mar 2006 20:53:43 -0000
Received: from unknown (HELO ?130.129.132.197?) (130.129.132.197)
  by omr4.mgt.bos.netsol.com with SMTP; 20 Mar 2006 20:53:43 -0000
Message-ID: <441F1657.2050207@andybierman.com>
Date: Mon, 20 Mar 2006 12:53:43 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: netconf <netconf@ops.ietf.org>
Subject: Re: NETCONF Port Decision
References: <CFEE79A465B35C4385389BA5866BEDF00C7FC4@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7FC4@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

McDonald, Ira wrote:
> Hi Andy,
>
> No objection, but clear WG concensus is NOT sufficient.
> Bert Wijnen specifically asked for a technical justification
> of the working group's decision - NOT just a decision.
>
>   

I didn't list the factors in this mail.
The main justification is that NETCONF is designed
to replace CLI over SSH, which is run on a system port,
and considered to be a task that is only performed by privileged users.



> [Also - small process thing - decisions in IETF WG's and on
> their concensus happen _only_ on mailing lists, not in any
> face-to-face meetings, per IETF Standards Process.]
>   
> Cheers,
> - Ira
>   

Andy



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



From owner-netconf@ops.ietf.org Mon Mar 20 16:21:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLRoh-0005AH-4e
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 16:21:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLRof-0004M0-Gx
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 16:21:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLRk1-000Bd6-Ur
	for netconf-data@psg.com; Mon, 20 Mar 2006 21:16:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [64.40.101.249] (helo=www.icesoft.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ted.goddard@icesoft.com>)
	id 1FLRjy-000Bcr-5b
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 21:16:38 +0000
Received: from [10.18.39.60] ([64.141.118.170])
	by www.icesoft.com (Kerio MailServer 6.1.2)
	(using TLSv1/SSLv3 with cipher RC4-SHA (128 bits));
	Mon, 20 Mar 2006 13:16:34 -0800
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <441EE12D.7050408@andybierman.com>
References: <441EE12D.7050408@andybierman.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <951B6FFA-0715-4D71-A50E-D41CEFACE369@icesoft.com>
Content-Transfer-Encoding: 7bit
From: Ted Goddard <ted.goddard@icesoft.com>
Subject: Re: NETCONF Port Decision
Date: Mon, 20 Mar 2006 14:16:32 -0700
To: Andy Bierman <ietf@andybierman.com>,
 netconf <netconf@ops.ietf.org>
X-Mailer: Apple Mail (2.746.2)
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8


One of the original concerns with NETCONF/SOAP/HTTP and
NETCONF/SOAP/HTTPS was that the traffic might default to port 80
and 443, thereby making it extremely difficult for a firewall to
distinguish between device management (NETCONF) and other less
sensitive uses of HTTP and HTTPS.  The same concern applies to
using a generic assigned port for SOAP over HTTP (and SOAP over BEEP)
as this makes it difficult for a firewall to distinguish between
NETCONF traffic and SOAP traffic belonging to other applications.

An assigned port for NETCONF over SOAP over HTTPS answers
the first part of this concern.

NETCONF over SOAP over HTTP (not HTTPS) is an insecure configuration
and is therefore not reasonably given special status for firewalls
(why open your firewall for an insecure protocol).  Hence an
assigned port is not required for this case.

NETCONF over SOAP over BEEP can make use of TLS upgrade, hence
NETCONF over SOAP over BEEP requires only one assigned port.

This leaves us with one port for NETCONF over SOAP over HTTPS and
one port for NETCONF over SOAP over BEEP, exactly as requested.

Ted.

On 20-Mar-06, at 10:06 AM, Andy Bierman wrote:

> Hi,
>
> The WG met this morning and discussed the port assignments for the  
> protocol.
> The clear consensus in the room was that the WG should ask for well  
> known
> ports instead of registered ports.
>
> If anyone wishes to strongly object to this decision,
> then please send an email to the WG  mailing list by 12:00AM EST  
> 3/22/06
> demonstrating a "fatal flaw" in this decision.  (E.g.., why assigning
> a well-known port instead of a registered port will harm the  
> Internet).
>
> The WG will ask for 4 ports:
>   - NETCONF over SSH
>   - NETCONF over BEEP
>   - NETCONF over SOAP over BEEP
>   - NETCONF over SOAP over HTTPS
>
>
> Andy
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Mar 20 19:25:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLUhB-0005u2-7C
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 19:25:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLUh9-0004A0-TO
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 19:25:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLUcC-000L8k-D6
	for netconf-data@psg.com; Tue, 21 Mar 2006 00:20:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [160.36.56.39] (helo=shu.cs.utk.edu)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <moore@cs.utk.edu>)
	id 1FLKDb-000Pq3-4R
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 13:14:43 +0000
Received: from localhost (shu [127.0.0.1])
	by shu.cs.utk.edu (Postfix) with ESMTP id 8A2B713B4A;
	Mon, 20 Mar 2006 08:14:41 -0500 (EST)
Received: from shu.cs.utk.edu ([127.0.0.1])
 by localhost (shu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 13465-04; Mon, 20 Mar 2006 08:14:40 -0500 (EST)
Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182])
	by shu.cs.utk.edu (Postfix) with ESMTP id A88D513B49;
	Mon, 20 Mar 2006 08:14:39 -0500 (EST)
Message-ID: <441EAABE.6040904@cs.utk.edu>
Date: Mon, 20 Mar 2006 08:14:38 -0500
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
CC: Joe Touch <touch@isi.edu>,  iana@iana.org,  ietf@ietf.org, 
 netconf@ops.ietf.org
Subject: Re: Guidance needed on well known ports
References: <198A730C2044DE4A96749D13E167AD375A2C21@MOU1WNEXMB04.vcorp.ad.vrsn.com>
In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2C21@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

> Dns is essential already.

false.  but even to the extent that this is true, this is a bug, not a 
feature.

> Firewalls can cope

but new applications can't.


Keith




--
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 Mar 20 19:26:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLUhK-0005yL-OI
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 19:26:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLUhK-0004AM-8g
	for netconf-archive@lists.ietf.org; Mon, 20 Mar 2006 19:26:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FLUbx-000L84-7x
	for netconf-data@psg.com; Tue, 21 Mar 2006 00:20:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=ham 
	version=3.1.0
Received: from [65.205.251.75] (helo=robin.verisign.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <pbaker@verisign.com>)
	id 1FLJbT-000NFK-2Q
	for netconf@ops.ietf.org; Mon, 20 Mar 2006 12:35:19 +0000
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33])
	by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k2KCZBM3015210;
	Mon, 20 Mar 2006 04:35:11 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 20 Mar 2006 04:35:11 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64C1A.BAB2F0A2"
Subject: Re: Guidance needed on well known ports
Date: Mon, 20 Mar 2006 04:35:11 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD375A2C21@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Guidance needed on well known ports
Thread-Index: AcZL24TkxIIlWIVgQxG+x2nQ5GV1JwAPzXfr
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "Joe Touch" <touch@isi.edu>, <iana@iana.org>, <ietf@ietf.org>,
        <netconf@ops.ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 12:35:11.0377 (UTC) FILETIME=[BAD13010:01C64C1A]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64C1A.BAB2F0A2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dns is essential already.

Firewalls can cope

 -----Original Message-----
From: 	Joe Touch [mailto:touch@isi.edu]
Sent:	Sun Mar 19 21:02:42 2006
To:	iana@iana.org; ietf@ietf.org; netconf@ops.ietf.org
Subject:	Re: Guidance needed on well known ports



Hallam-Baker, Phillip wrote:
>> From: Joe Touch [mailto:touch@ISI.EDU]=20
>=20
>> And with what port would I reach this magical DNS that would=20
>> provide the SRV record for the DNS itself?
>=20
> You use fixed ports for the bootstrap process and only for the =
bootstrap
> process.

Which means that the DNS port needs to be well-known or fixed in =
advance.

Some other issues to be considered:

	- this change would make the DNS required for proper Internet
	operation, whereas it is currently optional (i.e., only for
	finding the IP address).]

	- hosts may run services but not have control over their own
	DNS entry (or SRV records)

	- firewalling based on ports would no longer be useful
	(one could argue it should not be, but that's a different issue)

>>> Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6=20
>>> would be well advised to pay careful attention to that restriction.=20
>>> SRV ports work just fine behind a NAT.
>> Except that many NATs also intercept DNS requests and=20
>> redirect them to their own servers, for their own purposes,=20
>> which can interfere with SRV records (by design).
>=20
> People who do this are rarely trying to break things.

They don't *try* to break things, but then tend to. ;-)

As to 'by design', they're not so much trying to break as to 'help'
(usually for their own purposes).

Joe

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


------_=_NextPart_001_01C64C1A.BAB2F0A2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: Guidance needed on well known ports</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Dns is essential already.<BR>
<BR>
Firewalls can cope<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Joe Touch [<A =
HREF=3D"mailto:touch@isi.edu">mailto:touch@isi.edu</A>]<BR>
Sent:&nbsp;&nbsp; Sun Mar 19 21:02:42 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; iana@iana.org; ietf@ietf.org; =
netconf@ops.ietf.org<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Guidance needed =
on well known ports<BR>
<BR>
<BR>
<BR>
Hallam-Baker, Phillip wrote:<BR>
&gt;&gt; From: Joe Touch [<A =
HREF=3D"mailto:touch@ISI.EDU">mailto:touch@ISI.EDU</A>]<BR>
&gt;<BR>
&gt;&gt; And with what port would I reach this magical DNS that =
would<BR>
&gt;&gt; provide the SRV record for the DNS itself?<BR>
&gt;<BR>
&gt; You use fixed ports for the bootstrap process and only for the =
bootstrap<BR>
&gt; process.<BR>
<BR>
Which means that the DNS port needs to be well-known or fixed in =
advance.<BR>
<BR>
Some other issues to be considered:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - this change would make the =
DNS required for proper Internet<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operation, whereas it is =
currently optional (i.e., only for<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; finding the IP address).]<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - hosts may run services but =
not have control over their own<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNS entry (or SRV =
records)<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - firewalling based on ports =
would no longer be useful<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (one could argue it should =
not be, but that's a different issue)<BR>
<BR>
&gt;&gt;&gt; Fixed ports do not work behind NAT. Anyone who wants to =
deploy IPv6<BR>
&gt;&gt;&gt; would be well advised to pay careful attention to that =
restriction.<BR>
&gt;&gt;&gt; SRV ports work just fine behind a NAT.<BR>
&gt;&gt; Except that many NATs also intercept DNS requests and<BR>
&gt;&gt; redirect them to their own servers, for their own purposes,<BR>
&gt;&gt; which can interfere with SRV records (by design).<BR>
&gt;<BR>
&gt; People who do this are rarely trying to break things.<BR>
<BR>
They don't *try* to break things, but then tend to. ;-)<BR>
<BR>
As to 'by design', they're not so much trying to break as to 'help'<BR>
(usually for their own purposes).<BR>
<BR>
Joe<BR>
<BR>
_______________________________________________<BR>
Ietf mailing list<BR>
Ietf@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/ietf">https://www1.ietf.or=
g/mailman/listinfo/ietf</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C64C1A.BAB2F0A2--



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



From owner-netconf@ops.ietf.org Wed Mar 22 09:46:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM4bA-0006WR-76
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 09:46:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FM4b8-00028m-Td
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 09:46:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FM4UF-0004Pf-TZ
	for netconf-data@psg.com; Wed, 22 Mar 2006 14:38:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FM4UF-0004PT-1W
	for netconf@ops.ietf.org; Wed, 22 Mar 2006 14:38:59 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2MEcuX22726
	for <netconf@ops.ietf.org>; Wed, 22 Mar 2006 09:38:56 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Offline Netconf Notification Session - Dallas
Date: Wed, 22 Mar 2006 09:38:52 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4077CC049@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Offline Netconf Notification Session - Dallas
Thread-Index: AcZMP1IHX7lYw0KMQbyvpEXlJhNeqgBfiF8Q
From: "Sharon Chisholm" <schishol@nortel.com>
To: "netconf" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

hi

We shall meet tomorrow at 9am at the message board if additional people
are interested.

Thanks,

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Chisholm, Sharon [CAR:ZZ00:EXCH]
Sent: Monday, March 20, 2006 11:57 AM
To: netconf
Subject: Offline Netconf Notification Session - Dallas


hi

Anyone interested in getting together here in Dallas to discuss further
the Netconf Event Notification draft, please let me know.

I thought we could go through the issues list - not the one I sent, but
the longer one that Andy came presented in this morning's meeting - and
capture some pros and cons to each of the options. Open A is the
implementation from the draft and option B would be various hypothetical
design alternatives that have been raised.

Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

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


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



From owner-netconf@ops.ietf.org Wed Mar 22 23:04:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMH3i-0002Qf-L1
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:04:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMH3g-0004QR-4a
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:04:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMGwj-0006Hl-FA
	for netconf-data@psg.com; Thu, 23 Mar 2006 03:57:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMGwi-0006HQ-Bk
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 03:57:12 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2N3vADT030534
	for <netconf@ops.ietf.org>; Wed, 22 Mar 2006 22:57:11 -0500
Received: (qmail 15476 invoked from network); 23 Mar 2006 03:57:10 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr5.mgt.bos.netsol.com with SMTP; 23 Mar 2006 03:57:10 -0000
Message-ID: <44221C95.5050406@andybierman.com>
Date: Wed, 22 Mar 2006 19:57:09 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Notification Message Processing Model
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Hi,

I am trying to understand how the protocol will have
to be modified to support notifications and RPCs on
the same channel-less connection.

The document will have to define all possible interactions
between RPC and notifications in the architecture, regardless
of whether 1 or 2 connections are used.  However, if a shared
connection is used, then all possible message processing
interactions within the same session also needs to be defined.

Some example issues to consider:

1) agent message priority (<rpc-reply> vs. <notification>).
   It is possible that messages of both type need to be queued
   for output in the agent.  Who wins if both are waiting?
   (Hint: operationally, both answers could be wrong.)

2) The sword cuts both ways.
   We could have really big notifications, not just a
   really big <rpc-reply>.  This can seriously impair
   the use of the session for time-sensitive RPC operations
   (like fire-fighting a virus attack by making a configuration
   change to a firewall, router interface ACL entry, etc.).
  
3) lack of an <abort> command.
   The manager cannot shut up the agent if it is spewing a reply
   or a notification, except by closing the connection.
   We took this command out of the protocol when we took out
   channels.  We took out channels because of unwarranted inherent
   complexity.

4) notification amplification
   Multiple notification subscriptions per session means that
   there are potentially N copies of every notification that
   get generated by the agent per session, where N is the number
   of subscriptions. This makes the impact of issues (2) and (3)
   even worse.

5) notification rate control
   The content-filtering is not a rate control mechanism,
   despite that appearance in the draft. (Just the opposite -- see (4))
   The document will need to define adequate rate control
   and notification queueing mechanisms (better than FIFO logjam).

6) meltdown avoidance and repair
   It is very likely the NE device will be generating lots of
   event notifications when things go bad in a hurry, just as
   the operator is trying to reconfigure the device to make the
   root cause of the notification flood go away.  The document
   needs to define mechanisms to detect and prevent this type of
   scenario.



Andy



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



From owner-netconf@ops.ietf.org Wed Mar 22 23:11:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMHAT-0005vr-5f
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:11:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMHAR-0004ko-Pi
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:11:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMH2T-0006d1-8l
	for netconf-data@psg.com; Thu, 23 Mar 2006 04:03:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMH2R-0006cp-Ma
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 04:03:07 +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 k2N436X32238;
	Wed, 22 Mar 2006 20:03:06 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2N430560314;
	Wed, 22 Mar 2006 20:03:00 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2N48EYE018830;
	Wed, 22 Mar 2006 23:08:14 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603230408.k2N48EYE018830@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Wed, 22 Mar 2006 19:57:09 PST."
             <44221C95.5050406@andybierman.com> 
Date: Wed, 22 Mar 2006 23:08:14 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

Andy Bierman writes:
>3) lack of an <abort> command.
>   The manager cannot shut up the agent if it is spewing a reply
>   or a notification, except by closing the connection.
>   We took this command out of the protocol when we took out
>   channels.  We took out channels because of unwarranted inherent
>   complexity.

Any chance of getting <abort/> back in?

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 Wed Mar 22 23:25:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMHOE-0008DM-UC
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:25:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMHOD-0005LL-JD
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:25:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMHJk-0007Zl-K1
	for netconf-data@psg.com; Thu, 23 Mar 2006 04:21:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMHJj-0007ZS-Py
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 04:21:00 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2N4KwQ3001342
	for <netconf@ops.ietf.org>; Wed, 22 Mar 2006 23:20:58 -0500
Received: (qmail 11423 invoked from network); 23 Mar 2006 04:20:58 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr4.mgt.bos.netsol.com with SMTP; 23 Mar 2006 04:20:58 -0000
Message-ID: <44222228.5070004@andybierman.com>
Date: Wed, 22 Mar 2006 20:20:56 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603230408.k2N48EYE018830@idle.juniper.net>
In-Reply-To: <200603230408.k2N48EYE018830@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

Phil Shafer wrote:
> Andy Bierman writes:
>   
>> 3) lack of an <abort> command.
>>   The manager cannot shut up the agent if it is spewing a reply
>>   or a notification, except by closing the connection.
>>   We took this command out of the protocol when we took out
>>   channels.  We took out channels because of unwarranted inherent
>>   complexity.
>>     
>
> Any chance of getting <abort/> back in?
>   

Not if any of the 4 completed documents have to be
modified in any way to support it.

That is, assuming the WG even wants it, which doesn't
seem to be the case.


> Thanks,
>  Phil
>
>   

Andy



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



From owner-netconf@ops.ietf.org Wed Mar 22 23:43:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMHfQ-00049A-Ez
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:43:24 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMHfP-0006Qt-66
	for netconf-archive@lists.ietf.org; Wed, 22 Mar 2006 23:43:24 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMHbX-0008Xj-Rh
	for netconf-data@psg.com; Thu, 23 Mar 2006 04:39:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FMHbX-0008XW-9I
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 04:39:23 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 20:39:23 -0800
X-IronPort-AV: i="4.03,121,1141632000"; 
   d="scan'208"; a="317111761:sNHT28503952"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2N4dMw1009980;
	Wed, 22 Mar 2006 20:39:22 -0800 (PST)
Received: from [204.96.114.105] (rcdn-vpn-cluster-1-123.cisco.com [10.89.16.123])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2N4eGUn003035;
	Wed, 22 Mar 2006 20:40:17 -0800
Message-ID: <44222677.6040401@cisco.com>
Date: Wed, 22 Mar 2006 22:39:19 -0600
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Phil Shafer <phil@juniper.net>, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603230408.k2N48EYE018830@idle.juniper.net> <44222228.5070004@andybierman.com>
In-Reply-To: <44222228.5070004@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=86; t=1143088818; x=1143521018;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Notification=20Message=20Processing=20Model
	|To:Andy=20Bierman=20<ietf@andybierman.com>;
	X=v=3Dmtcc.com=3B=20h=3DT39ti+AZ8r8Anoj3ZbHDq9NC+Lk=3D; b=GbfIDMrotXlTbstQCf5Wyn8pprLRbK1gqLAVpa+hYv6dOex5e91GTuIwJHMPCCW74U2ygi6j
	WxVCJteMVqj8Q6lNuiKrhHZHzzzhweFk/lO8XUeoUC0bt8990q1mYtzFnaOWQYz4AKZcgmlD1Ed
	vyqqhVKJ3FRwdcqjG9Y0y3rA=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009

If it's needed, this would be the sort of thing a capability might express.

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 Thu Mar 23 08:47:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMQAG-0004qZ-Iq
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 08:47:48 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMQAE-0002lJ-7s
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 08:47:48 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMQ1I-00064l-Bf
	for netconf-data@psg.com; Thu, 23 Mar 2006 13:38:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMQ1H-00064W-AB
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 13:38:31 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NDcTkQ020593
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 08:38:30 -0500
Received: (qmail 31144 invoked by uid 78); 23 Mar 2006 13:38:29 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 23 Mar 2006 13:38:29 -0000
Message-ID: <4422A4C9.2020803@andybierman.com>
Date: Thu, 23 Mar 2006 05:38:17 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: Phil Shafer <phil@juniper.net>, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603230408.k2N48EYE018830@idle.juniper.net> <44222228.5070004@andybierman.com> <44222677.6040401@cisco.com>
In-Reply-To: <44222677.6040401@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

Eliot Lear wrote:
> If it's needed, this would be the sort of thing a capability might express.
>   

IMO, we have enough optional functionality already.
The permutations the manager needs to deal with should be considered here.

Also, you cannot use a capability to contradict normative text.
You can only use it to add normative text.

> Eliot
>   

Andy




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



From owner-netconf@ops.ietf.org Thu Mar 23 09:45:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMR4X-0006Sn-JK
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 09:45:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMR4X-0005Ri-5h
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 09:45:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMQyU-0000UX-3T
	for netconf-data@psg.com; Thu, 23 Mar 2006 14:39:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FMQyS-0000TM-LB
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 14:39:40 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2NEdbm01474
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 09:39:37 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model
Date: Thu, 23 Mar 2006 09:39:21 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40782E440@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZOLx1EvTJUmO29QAqwkk1A5OtIpwAVZzeA
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8

hi

I think we have already said that when it makes operational sense to
perform your asynchronous commands on a separate connections, then
operators/managers will likely choose to do so. Some of these cases are
interesting for when the operator/manager does not anticipate the impact
of operations they are performing and puts things on the same connection
that perhaps shouldn't have been.

From my perspective, the operations that I expect to be on the same
connection are those related to notifications I receive. Learning about
the state of the system when I start managing it, perhaps asking
follow-up questions to the information received in the notification.

<Andy>
1) agent message priority (<rpc-reply> vs. <notification>).
   It is possible that messages of both type need to be queued
   for output in the agent.  Who wins if both are waiting?
   (Hint: operationally, both answers could be wrong.)
</Andy>

I'm not sure we need to specify. Is first in first out not sufficient?
As you have hinted, there are problems and benefits to all approaches. I
see the most interest in priority-based queuing based on the importance
of the individual notification, not generally by whether it is a
notification or something else.


<Andy>
2) The sword cuts both ways.
   We could have really big notifications, not just a
   really big <rpc-reply>.  This can seriously impair
   the use of the session for time-sensitive RPC operations
   (like fire-fighting a virus attack by making a configuration
   change to a firewall, router interface ACL entry, etc.).
</Andy>

I believe the event class will predict in a lot of cases how big the
notification will be.

<Andy> =20
3) lack of an <abort> command.
   The manager cannot shut up the agent if it is spewing a reply
   or a notification, except by closing the connection.
   We took this command out of the protocol when we took out
   channels.  We took out channels because of unwarranted inherent
   complexity.
</Andy>

At least with the current design, you can send a <cancel-subscription>
command between notifications.

<Andy>
4) notification amplification
   Multiple notification subscriptions per session means that
   there are potentially N copies of every notification that
   get generated by the agent per session, where N is the number
   of subscriptions. This makes the impact of issues (2) and (3)
   even worse.
</Andy>

I'm not sure this is really an issue. I imagine perhaps a 30%
duplication rate among multiple subscriptions when they are used. I
can't imagine why someone would create N identical subscriptions as it
is more work for the operator/manager too. They will be used when they
provide value and I believe this is more the case when there is much
smaller amounts of overlap.

<Andy>
5) notification rate control
   The content-filtering is not a rate control mechanism,
   despite that appearance in the draft. (Just the opposite -- see (4))
   The document will need to define adequate rate control
   and notification queueing mechanisms (better than FIFO logjam).
</Andy>

Rate throttling is always a problem. I didn't think we included much
about it in the draft, so I'm not sure what you referring to. Filtering
would help somewhat since there are some notifications that will never
get sent so don't need to throttled, but obviously it remains an issue.
Rate throttling is not a minor topic, so we will have to decide how far
down that road we want to go. An understanding of the relationship
between sequence numbers and throttling is helpful and I can't remember
if we included that in the draft. It is easy enough to add that piece.


<Andy>
6) meltdown avoidance and repair
   It is very likely the NE device will be generating lots of
   event notifications when things go bad in a hurry, just as
   the operator is trying to reconfigure the device to make the
   root cause of the notification flood go away.  The document
   needs to define mechanisms to detect and prevent this type of
   scenario.
</Andy>

This is where throttling would help. Prioritized throttling is better
then just flow control, but again, we would have to decide how far down
this road we wish to explore.

Sharon



--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Thu Mar 23 11:00:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMSEE-0005oJ-C4
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 11:00:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMSEC-0001Ac-W0
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 11:00:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMS7X-0000V2-RU
	for netconf-data@psg.com; Thu, 23 Mar 2006 15:53:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FMS7W-0000Uf-DV
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 15:53:06 +0000
Received: from [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b] (unknown [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id E0CB7E60EB;
	Thu, 23 Mar 2006 15:53:05 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <4422C460.8060809@isc.org>
Date: Thu, 23 Mar 2006 16:53:04 +0100
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <44221C95.5050406@andybierman.com>
In-Reply-To: <44221C95.5050406@andybierman.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Bierman wrote:
> 
> I am trying to understand how the protocol will have
> to be modified to support notifications and RPCs on
> the same channel-less connection.

Rather than go into specific details, I would rather say that:

- - Putting notifications and RPCs on the same channel adds complexity to
the server.

- - It also adds complexity to the client (but really only to clients that
want it).

- - It would be nice to live without the complexity if we can.

I *think* this is pretty much what Andy Bierman has been saying.

As I see it, a client can usually multiplex two channels into one very
easily. Can someone explain a case where this is not true? (One case
presented in the working group where this may not be true is for clients
that are managing tens of thousands of devices. However, I think both
SSH and BEEP allow multiple channels on a single TCP connection, so we
should probably consider the "massive management" case a non-problem.)

Also, can someone give a specific example where putting notification and
RPCs on the same channel would be simpler than creating a new channel?

Apologies if this has already been given and I missed it!

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEIsRgMsfZxBO4kbQRAsrvAKC7DswY53262nWpXak/qsFnkl9HjACfYkm2
PpxTL6l87W8w/M+IW3MS7Lc=
=Xp+M
-----END PGP SIGNATURE-----

--
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 Mar 23 11:58:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMT8g-0006XL-N8
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 11:58:22 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMT8g-0003Nh-DO
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 11:58:22 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMT3Y-0007HI-Fp
	for netconf-data@psg.com; Thu, 23 Mar 2006 16:53:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMT3X-0007Gk-Hu
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 16:53:03 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NGr1vW030906
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 11:53:02 -0500
Received: (qmail 1076 invoked from network); 23 Mar 2006 16:53:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 23 Mar 2006 16:53:01 -0000
Message-ID: <4422D26C.3030805@andybierman.com>
Date: Thu, 23 Mar 2006 08:53:00 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: shane_kerr@isc.org
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <44221C95.5050406@andybierman.com> <4422C460.8060809@isc.org>
In-Reply-To: <4422C460.8060809@isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c

Shane Kerr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andy Bierman wrote:
>   
>> I am trying to understand how the protocol will have
>> to be modified to support notifications and RPCs on
>> the same channel-less connection.
>>     
>
> Rather than go into specific details, I would rather say that:
>
> - - Putting notifications and RPCs on the same channel adds complexity to
> the server.
>
> - - It also adds complexity to the client (but really only to clients that
> want it).
>
> - - It would be nice to live without the complexity if we can.
>
> I *think* this is pretty much what Andy Bierman has been saying.
>
>   

Exactly.
I've been taught the whole art of Engineering is
having just enough complexity, but no more.
(A concept totally foreign to the IETF.)


> As I see it, a client can usually multiplex two channels into one very
> easily. Can someone explain a case where this is not true? (One case
> presented in the working group where this may not be true is for clients
> that are managing tens of thousands of devices. However, I think both
> SSH and BEEP allow multiple channels on a single TCP connection, so we
> should probably consider the "massive management" case a non-problem.)
>
> Also, can someone give a specific example where putting notification and
> RPCs on the same channel would be simpler than creating a new channel?
>
> Apologies if this has already been given and I missed it!
>   

No -- you missed nothing.
I have thought about it as much as I can.
I can't come up with any use cases in which a robust
event management system would be simpler because
operations and notifications were mixed on the same channel.

I have only found bad things that can happen to your OPS
if you did this.  No real benefits at all.  I'd love to hear
why management stations need this feature.

> - --
> Shane
>   

Andy



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



From owner-netconf@ops.ietf.org Thu Mar 23 13:24:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMUUH-00021J-UG
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 13:24:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMUUH-00071Q-F5
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 13:24:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMUK8-0005AY-HU
	for netconf-data@psg.com; Thu, 23 Mar 2006 18:14:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FMUK7-0005A5-Bj
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 18:14:15 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by test-iport-1.cisco.com with ESMTP; 23 Mar 2006 10:14:15 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2NIEE7X023675;
	Thu, 23 Mar 2006 10:14:15 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 23 Mar 2006 10:14:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model
Date: Thu, 23 Mar 2006 10:14:13 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB0193B075@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZOLi3VnyumFg76Q22IiQSEgcaxGgAccNyQ
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 23 Mar 2006 18:14:14.0976 (UTC) FILETIME=[97C94C00:01C64EA5]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243


From an operational standpoint it makes much more sense to have
dedicated connections or channels for commands/control & notifications.
When using SSH it is an operational/resource constraint decision whether
or not a full dedicated SSH session is used for commands & notifications
or a single session with multiple channels is utilized.
A notifications session/channel needs to allow the transfer of commands
(i.e. rpcs and notifications mixed) because for example (just one, there
are others) a management application dedicated to
monitoring/troubleshooting may need to retrieve additional information
in response to a received fault-notification. I think that in this
situations it is ok to simply interleave messages.=20

Now, given the above, someone may decide to use a single session for
both rpcs and notifications. This is a lose-lose situation as you point
out below. One thing that could be done if need be is to allow
configuration of priorities (prioritize rpcs over notifications or
viceversa but that's about it) & things run to completion.=20

See additional comments in-line
Hector


      =20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, March 22, 2006 8:57 PM
> To: Netconf (E-mail)
> Subject: Notification Message Processing Model
>=20
> Hi,
>=20
> I am trying to understand how the protocol will have to be=20
> modified to support notifications and RPCs on the same=20
> channel-less connection.
>=20
> The document will have to define all possible interactions=20
> between RPC and notifications in the architecture, regardless=20
> of whether 1 or 2 connections are used.  However, if a shared=20
> connection is used, then all possible message processing=20
> interactions within the same session also needs to be defined.
>=20
> Some example issues to consider:
>=20
> 1) agent message priority (<rpc-reply> vs. <notification>).
>    It is possible that messages of both type need to be queued
>    for output in the agent.  Who wins if both are waiting?
>    (Hint: operationally, both answers could be wrong.)

Sure, no right answer here. But as I said above the implementation could
allow prioritization of rpcs or notifications at the user's convinence.=20

>=20
> 2) The sword cuts both ways.
>    We could have really big notifications, not just a
>    really big <rpc-reply>.  This can seriously impair
>    the use of the session for time-sensitive RPC operations
>    (like fire-fighting a virus attack by making a configuration
>    change to a firewall, router interface ACL entry, etc.).

Yes. But IMO this is an operational matter. The protocol cannot solve
bad operational planning (at least not w/o much not needed complexity).
The operator(s) responsible for managing the network are likely aware of
this or could be made aware and should choose to have dedicated
sessions/channels.=20

>  =20
> 3) lack of an <abort> command.
>    The manager cannot shut up the agent if it is spewing a reply
>    or a notification, except by closing the connection.
>    We took this command out of the protocol when we took out
>    channels.  We took out channels because of unwarranted inherent
>    complexity.

I think an abort command would've been useful regardless of whether or
not you have
mixed rpcs and notifications.=20

>=20
> 4) notification amplification
>    Multiple notification subscriptions per session means that
>    there are potentially N copies of every notification that
>    get generated by the agent per session, where N is the number
>    of subscriptions. This makes the impact of issues (2) and (3)
>    even worse.

Yes, sure but again this comes back to operations as I commented in 2.
The document could have some operational guidelines/recommendations on
this.=20

>=20
> 5) notification rate control
>    The content-filtering is not a rate control mechanism,
>    despite that appearance in the draft. (Just the opposite=20
> -- see (4))
>    The document will need to define adequate rate control
>    and notification queueing mechanisms (better than FIFO logjam).

OK

>=20
> 6) meltdown avoidance and repair
>    It is very likely the NE device will be generating lots of
>    event notifications when things go bad in a hurry, just as
>    the operator is trying to reconfigure the device to make the
>    root cause of the notification flood go away.  The document
>    needs to define mechanisms to detect and prevent this type of
>    scenario.
>=20
OK
>=20
>=20
> Andy
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Thu Mar 23 13:52:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMUuo-0007lw-2S
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 13:52:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMUum-00081X-Q6
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 13:52:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMUpl-0009x4-4C
	for netconf-data@psg.com; Thu, 23 Mar 2006 18:46:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMUpi-0009wp-KK
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 18:46:54 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2NIko1Z061716;
	Thu, 23 Mar 2006 10:46:50 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2NIko506207;
	Thu, 23 Mar 2006 10:46:50 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2NIq3YE021374;
	Thu, 23 Mar 2006 13:52:03 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603231852.k2NIq3YE021374@idle.juniper.net>
To: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
cc: "Andy Bierman" <ietf@andybierman.com>,
   "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Thu, 23 Mar 2006 10:14:13 PST."
             <6E21698722408147BEA594E073E2B0AB0193B075@xmb-sjc-223.amer.cisco.com> 
Date: Thu, 23 Mar 2006 13:52:03 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

"Hector Trevino \(htrevino\)" writes:
>Now, given the above, someone may decide to use a single session for
>both rpcs and notifications. This is a lose-lose situation as you point
>out below.

If it's a lose-lose, why allow it?

>One thing that could be done if need be is to allow
>configuration of priorities (prioritize rpcs over notifications or
>viceversa but that's about it) & things run to completion. 

This seems like adding more complexity to handle the additional
complexity of a complex solution.

A long-lived RPC running on a distinct channel is trivial and is
allowed within the existing netconf spec for no additional
protocol-level work.  Just make a capability that defines your RPCs
and you are golden.

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 23 14:07:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMV9N-0002xR-Gg
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 14:07:13 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMV9N-0000Pi-5m
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 14:07:13 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMV4X-000Bpx-CY
	for netconf-data@psg.com; Thu, 23 Mar 2006 19:02:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FMV4U-000BpK-7Z
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 19:02:10 +0000
Received: from sj-core-3.cisco.com ([171.68.223.137])
  by sj-iport-4.cisco.com with ESMTP; 23 Mar 2006 11:02:11 -0800
X-IronPort-AV: i="4.03,123,1141632000"; 
   d="scan'208"; a="1787696847:sNHT32365128"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2NJ291n010665;
	Thu, 23 Mar 2006 11:02:09 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 23 Mar 2006 11:02:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model 
Date: Thu, 23 Mar 2006 11:02:04 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB0193B0B7@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model 
Thread-Index: AcZOqi6qOdmGyV8aS8aFXREoojBuoAAAHLXw
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Phil Shafer" <phil@juniper.net>
Cc: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 23 Mar 2006 19:02:05.0990 (UTC) FILETIME=[470B4460:01C64EAC]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c

=20

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]=20
> Sent: Thursday, March 23, 2006 11:52 AM
> To: Hector Trevino (htrevino)
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: Notification Message Processing Model=20
>=20
> "Hector Trevino \(htrevino\)" writes:
> >Now, given the above, someone may decide to use a single session for=20
> >both rpcs and notifications. This is a lose-lose situation=20
> as you point=20
> >out below.
>=20
> If it's a lose-lose, why allow it?

HT: I think dedicated sessions/channles should be used. But we can't
disallow the use of mixed rpcs and notifications because there're
situations in which you may need to issue rpcs on a notification
session/channel (as per my example). I say it is a lose-lose situation
because if someone decides to use a single session for both then chances
are the operational needs will not be satisfied w/o adding much
complexity.=20

>=20
> >One thing that could be done if need be is to allow configuration of=20
> >priorities (prioritize rpcs over notifications or viceversa=20
> but that's=20
> >about it) & things run to completion.
>=20
> This seems like adding more complexity to handle the=20
> additional complexity of a complex solution.
>=20
> A long-lived RPC running on a distinct channel is trivial and=20
> is allowed within the existing netconf spec for no additional=20
> protocol-level work.  Just make a capability that defines=20
> your RPCs and you are golden.

HT: Yes, agree w/you. Simply was saying that if we need to do something
then it needs to be relatively simple. But my preference to avoid any
additional work & complexity.=20
>=20
> Thanks,
>  Phil
>=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 Thu Mar 23 14:42:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMVhk-0007Bu-7t
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 14:42:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMVhi-0001p6-Rv
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 14:42:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMVdO-000IWq-M0
	for netconf-data@psg.com; Thu, 23 Mar 2006 19:38:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FMVdL-000IWQ-V0
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 19:38:11 +0000
Received: from [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b] (unknown [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id 529F5E6104;
	Thu, 23 Mar 2006 19:38:06 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <4422F91D.7040605@isc.org>
Date: Thu, 23 Mar 2006 20:38:05 +0100
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <6E21698722408147BEA594E073E2B0AB0193B075@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB0193B075@xmb-sjc-223.amer.cisco.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hector Trevino (htrevino) wrote:
>>From an operational standpoint it makes much more sense to have
> dedicated connections or channels for commands/control & notifications.
> When using SSH it is an operational/resource constraint decision whether
> or not a full dedicated SSH session is used for commands & notifications
> or a single session with multiple channels is utilized.
> A notifications session/channel needs to allow the transfer of commands
> (i.e. rpcs and notifications mixed) because for example (just one, there
> are others) a management application dedicated to
> monitoring/troubleshooting may need to retrieve additional information
> in response to a received fault-notification. I think that in this
> situations it is ok to simply interleave messages. 

Why not perform the query to retrieve additional information on a
separate channel?

As a client developer, it would be simplier. You avoid the case:

server -> client
  event A
client -> server
  RPC asking for more info about event A
server -> client
  event B (sent before RPC began)

The client has to either handle the event asynchronously, or save it in
some buffer somewhere (or perhaps ignore it).

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEIvkdMsfZxBO4kbQRAg+fAJ9bKEopxrJIMU+YMsh/juEjC3BtrACffiWe
aeAdc9InfNEOwE+b/MDZiF0=
=Pq7j
-----END PGP SIGNATURE-----

--
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 Mar 23 15:04:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMW2u-00086f-4b
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:36 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMW2t-0003BT-LE
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:36 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMVwv-000MBf-TD
	for netconf-data@psg.com; Thu, 23 Mar 2006 19:58:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMVwv-000MBF-2L
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 19:58:25 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NJwNQ3022039
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 14:58:24 -0500
Received: (qmail 6766 invoked from network); 23 Mar 2006 19:58:23 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr4.mgt.bos.netsol.com with SMTP; 23 Mar 2006 19:58:23 -0000
Message-ID: <4422FDDE.5030607@andybierman.com>
Date: Thu, 23 Mar 2006 11:58:22 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603231852.k2NIq3YE021374@idle.juniper.net>
In-Reply-To: <200603231852.k2NIq3YE021374@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b

Phil Shafer wrote:
> "Hector Trevino \(htrevino\)" writes:
>   
>> Now, given the above, someone may decide to use a single session for
>> both rpcs and notifications. This is a lose-lose situation as you point
>> out below.
>>     
>
> If it's a lose-lose, why allow it?
>
>   
>> One thing that could be done if need be is to allow
>> configuration of priorities (prioritize rpcs over notifications or
>> viceversa but that's about it) & things run to completion. 
>>     
>
> This seems like adding more complexity to handle the additional
> complexity of a complex solution.
>
> A long-lived RPC running on a distinct channel is trivial and is
> allowed within the existing netconf spec for no additional
> protocol-level work.  Just make a capability that defines your RPCs
> and you are golden.
>   

Here is a variant of your proposal that gets rid of the partial
XML document problem.

New Capability:

   :notification-mode

Architecture changes:

   An active NETCONF session has two modes:

   rpc-mode: The session is being used for RPC operations.
   The manager can send <rpc> or <stop-notifications/>.
   The agent can send <rpc-reply>.

   notification-mode: The session is being used for notifications.
   The manager can send <start-notifications> or <stop-notifications/>.
   The agent can send <notification> and <rpc-reply>.

   Initial mode: rpc

Protocol changes:

  New RPC method (i.e., from manager to agent):
 
   <start-notifications>

     Parameters:

        (parameter details TBA -- to-be-argued)

      If the agent is in 'rpc' mode, and the parameters are
      acceptable, then a positive response is returned and the
      agent will enter notification mode. 

      If the agent is already in notification mode, and the agent
      will allow the new parameter set values (if different than
      the current values), then the agent will return a positive
      response and start using the new parameter values.  If the
      new parameter values are the same as the current values,
      then a positive response is returned.

      Otherwise a negative response is returned.

      While in notification mode, all <rpc> requests will be returned
      with negative response <rpc-reply> messages.  In this mode the
      manager should expect to receive <notification> messages that
      meet the selection criteria specified in the 'xxx' parameters,
      generated as various events occur within the agent.

    Positive Response:
 
      <ok/>

    Negative response:

     If the agent cannot honor the requested the request for any
     reason a <rpc-error> response will be generated.

 
  <stop-notifications>

      If the agent is in rpc mode it will simply return a positive
      response and stay in rpc mode.

      If the agent is in notification mode it will finish sending
      any <notification> message in progress to maintain a well-formed
      XML message stream, and then terminate notification mode, and
      switch to rpc mode.

      Regardless of the current mode, the agent will return a positive
      response.

   Parameters:

      none

   Positive Response:

      <ok/>

   Negative Response:

      none


> Thanks,
>  Phil
>   


Andy



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



From owner-netconf@ops.ietf.org Thu Mar 23 15:04:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMW2y-000873-Ju
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:40 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMW2x-0003Bb-A7
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:40 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMVwg-000M8y-S3
	for netconf-data@psg.com; Thu, 23 Mar 2006 19:58:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMVwg-000M8l-2K
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 19:58:10 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NJw8ts010494
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 14:58:08 -0500
Received: (qmail 24991 invoked from network); 23 Mar 2006 19:58:08 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 23 Mar 2006 19:58:08 -0000
Message-ID: <4422FDCF.2020800@andybierman.com>
Date: Thu, 23 Mar 2006 11:58:07 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: Phil Shafer <phil@juniper.net>, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <6E21698722408147BEA594E073E2B0AB0193B0B7@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB0193B0B7@xmb-sjc-223.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22

 >...
>> If it's a lose-lose, why allow it?
>>     
>
> HT: I think dedicated sessions/channles should be used. But we can't
> disallow the use of mixed rpcs and notifications because there're
> situations in which you may need to issue rpcs on a notification
> session/channel (as per my example). I say it is a lose-lose situation
> because if someone decides to use a single session for both then chances
> are the operational needs will not be satisfied w/o adding much
> complexity. 
>
>   

I don't see an example. Please explain in more detail.

>>  Phil
>>     


Andy



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



From owner-netconf@ops.ietf.org Thu Mar 23 15:16:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMWEi-0005XI-0w
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:16:48 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMWEh-0003pt-B3
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:16:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMW9R-000Neg-3Y
	for netconf-data@psg.com; Thu, 23 Mar 2006 20:11:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FMW9Q-000NeV-6V
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 20:11:20 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-2.cisco.com with ESMTP; 23 Mar 2006 12:11:20 -0800
X-IronPort-AV: i="4.03,123,1141632000"; 
   d="scan'208"; a="317267706:sNHT32840904"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2NKBJGv009272;
	Thu, 23 Mar 2006 12:11:19 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 23 Mar 2006 12:11:19 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model
Date: Thu, 23 Mar 2006 12:11:18 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB0193B14A@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZOsU+VVGCuS+2RQRatrXRqA9Q6bQAAXrzg
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: <shane_kerr@isc.org>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 23 Mar 2006 20:11:19.0724 (UTC) FILETIME=[F2DCC6C0:01C64EB5]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

=20
Hi, in-line
Hector


> -----Original Message-----
> From: Shane Kerr [mailto:Shane_Kerr@isc.org]=20
> Sent: Thursday, March 23, 2006 12:38 PM
> To: Hector Trevino (htrevino)
> Cc: Netconf (E-mail)
> Subject: Re: Notification Message Processing Model
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hector Trevino (htrevino) wrote:
> >>From an operational standpoint it makes much more sense to have
> > dedicated connections or channels for commands/control &=20
> notifications.
> > When using SSH it is an operational/resource constraint decision=20
> > whether or not a full dedicated SSH session is used for commands &=20
> > notifications or a single session with multiple channels is=20
> utilized.
> > A notifications session/channel needs to allow the transfer of=20
> > commands (i.e. rpcs and notifications mixed) because for=20
> example (just=20
> > one, there are others) a management application dedicated to=20
> > monitoring/troubleshooting may need to retrieve additional=20
> information=20
> > in response to a received fault-notification. I think that in this=20
> > situations it is ok to simply interleave messages.
>=20
> Why not perform the query to retrieve additional information=20
> on a separate channel?
>=20
> As a client developer, it would be simplier. You avoid the case:
>=20
> server -> client
>   event A
> client -> server
>   RPC asking for more info about event A server -> client
>   event B (sent before RPC began)
>=20
> The client has to either handle the event asynchronously, or=20
> save it in some buffer somewhere (or perhaps ignore it).

HT: Sure, you can do that but IMO that's an operational/deployment
decision. From my perspective, I'd like provide as much deployment
flexibility as possible and minimize the complexity. Hence the example
of a possible usage.=20
=20
>=20
> - --
> Shane
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>=20
> iD8DBQFEIvkdMsfZxBO4kbQRAg+fAJ9bKEopxrJIMU+YMsh/juEjC3BtrACffiWe
> aeAdc9InfNEOwE+b/MDZiF0=3D
> =3DPq7j
> -----END PGP SIGNATURE-----
>=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 Thu Mar 23 15:23:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMWLY-0005x8-Mm
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:23:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMWLX-000480-Dn
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 15:23:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMWGL-000OGL-R2
	for netconf-data@psg.com; Thu, 23 Mar 2006 20:18:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMWGL-000OFy-6s
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 20:18:29 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2NKIR1Z062805;
	Thu, 23 Mar 2006 12:18:27 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2NKIR532811;
	Thu, 23 Mar 2006 12:18:27 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2NKNfYE022289;
	Thu, 23 Mar 2006 15:23:41 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603232023.k2NKNfYE022289@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Thu, 23 Mar 2006 11:58:22 PST."
             <4422FDDE.5030607@andybierman.com> 
Date: Thu, 23 Mar 2006 15:23:41 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Andy Bierman writes:
>   An active NETCONF session has two modes:

This introduces modality into the netconf session, which
is increasing the complexity.

Instead, we could just have a simple RPC that is long-lived:

C:  <rpc ...>
C:    <get-syslog-notifications>
C:      <level>warning</level>
C:    </get-syslog-notifications>
C:  </rpc>

The server responds with an <rpc-reply> containing an
unending series of notifications which match the criteria from
the <get-syslog-notifications> RPC:

S:  <rpc-reply ...>
S:    <notification> ... data for one notification ... </notification>
S:    <notification> ... data for another notification ... </notification>
S:    <notification> ... data for yet another notification ... </notification>
S:    <notification> ... data for one more notification ... </notification>

The notifications would continue until the channel is closed.  Or
until we resurrect the <abort/> mechanism ;^)

This is simple, direct, and uses the existing netconf framework.
If interleaving is a lose-lose, this is a win-win.

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 23 16:28:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMXLn-000394-AL
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:28:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMXLm-0007gU-0c
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:28:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMXEx-0006E6-0M
	for netconf-data@psg.com; Thu, 23 Mar 2006 21:21:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMXEw-0006Dv-6j
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 21:21:06 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NLL4kQ003018
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 16:21:04 -0500
Received: (qmail 26812 invoked by uid 78); 23 Mar 2006 21:21:03 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 23 Mar 2006 21:21:03 -0000
Message-ID: <44231134.9010908@andybierman.com>
Date: Thu, 23 Mar 2006 13:20:52 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603232023.k2NKNfYE022289@idle.juniper.net>
In-Reply-To: <200603232023.k2NKNfYE022289@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Phil Shafer wrote:
> Andy Bierman writes:
>   
>>   An active NETCONF session has two modes:
>>     
>
> This introduces modality into the netconf session, which
> is increasing the complexity.
>
> Instead, we could just have a simple RPC that is long-lived:
>
> C:  <rpc ...>
> C:    <get-syslog-notifications>
> C:      <level>warning</level>
> C:    </get-syslog-notifications>
> C:  </rpc>
>
> The server responds with an <rpc-reply> containing an
> unending series of notifications which match the criteria from
> the <get-syslog-notifications> RPC:
>
> S:  <rpc-reply ...>
> S:    <notification> ... data for one notification ... </notification>
> S:    <notification> ... data for another notification ... </notification>
> S:    <notification> ... data for yet another notification ... </notification>
> S:    <notification> ... data for one more notification ... </notification>
>
> The notifications would continue until the channel is closed.  Or
> until we resurrect the <abort/> mechanism ;^)
>
> This is simple, direct, and uses the existing netconf framework.
> If interleaving is a lose-lose, this is a win-win.
>
>   

The objection to this approach in the WG meeting was that off-the-shelf 
validation tools
will not be able to work because they will be waiting for the </rpc-reply>
before finishing the validation.  Hence the validation phase never ends.

I love your approach.
It would be simple for me to implement.
I'm not using off-the-shelf validation tools though.


> Thanks,
>  Phil
>
>   

Andy



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



From owner-netconf@ops.ietf.org Thu Mar 23 16:36:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMXTi-00029B-2i
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:36:22 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMXTf-00081Q-Pg
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:36:22 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMXQR-00073v-2D
	for netconf-data@psg.com; Thu, 23 Mar 2006 21:32:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMXQO-00073d-Fl
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 21:32:56 +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 k2NLWlX44265;
	Thu, 23 Mar 2006 13:32:47 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2NLWf549191;
	Thu, 23 Mar 2006 13:32:41 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2NLbtYE022701;
	Thu, 23 Mar 2006 16:37:55 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603232137.k2NLbtYE022701@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Thu, 23 Mar 2006 13:20:52 PST."
             <44231134.9010908@andybierman.com> 
Date: Thu, 23 Mar 2006 16:37:55 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

Andy Bierman writes:
>The objection to this approach in the WG meeting was that off-the-shelf 
>validation tools
>will not be able to work because they will be waiting for the </rpc-reply>
>before finishing the validation.  Hence the validation phase never ends.

What off-the-shelf validation tools?  The ones that understand the
<rpc-one-way> element?  If you are able to toss an <rpc-one-way>
element to your validator, you can toss a <notification> element
to one.  But given that the contents will likely just be a syslog
line, there's really no point.  It's just a line of text.  You hook
you incoming netconf channel up to a sax parser (or a pull parser)
and get ready for a stream of startElement, characters, and endElement
events.

>I love your approach.

Cool....

>It would be simple for me to implement.

Yup, it would be simple for anyone to implement.  That's
the beauty.

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 23 16:45:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMXcZ-0001YF-48
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:45:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMXcX-0008Ik-R7
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:45:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMXYl-0008Jh-3L
	for netconf-data@psg.com; Thu, 23 Mar 2006 21:41:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMXYk-0008JV-DB
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 21:41:34 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2NLfWts014912
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 16:41:32 -0500
Received: (qmail 25624 invoked from network); 23 Mar 2006 21:41:32 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr3.mgt.bos.netsol.com with SMTP; 23 Mar 2006 21:41:32 -0000
Message-ID: <4423160B.4060900@andybierman.com>
Date: Thu, 23 Mar 2006 13:41:31 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: shane_kerr@isc.org, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <6E21698722408147BEA594E073E2B0AB0193B14A@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB0193B14A@xmb-sjc-223.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

 >...
> HT: Sure, you can do that but IMO that's an operational/deployment
> decision. From my perspective, I'd like provide as much deployment
> flexibility as possible and minimize the complexity. Hence the example
> of a possible usage. 
>   

1) Flexible as possible never means simple as possible

2) I'm still unclear on this use case you mention

Andy



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



From owner-netconf@ops.ietf.org Thu Mar 23 16:50:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMXh9-0005EB-C0
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:50:15 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMXh8-0008PR-0n
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 16:50:15 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMXd0-0008fm-5t
	for netconf-data@psg.com; Thu, 23 Mar 2006 21:45:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FMXcz-0008fa-F7
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 21:45:57 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by test-iport-1.cisco.com with ESMTP; 23 Mar 2006 13:45:57 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2NLjvw1020948;
	Thu, 23 Mar 2006 13:45:57 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 23 Mar 2006 13:45:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model
Date: Thu, 23 Mar 2006 13:45:56 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB0193B1B6@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZOtBx8O6hebq5bRpyt2bQf6TTbhwADrJOQ
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Phil Shafer" <phil@juniper.net>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 23 Mar 2006 21:45:57.0042 (UTC) FILETIME=[2ACEC120:01C64EC3]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5


It was in my response to your original e-mail. Pasted below

"From an operational standpoint it makes much more sense to have
dedicated connections or channels for commands/control & notifications.
When using SSH it is an operational/resource constraint decision whether
or not a full dedicated SSH session is used for commands & notifications
or a single session with multiple channels is utilized.
A notifications session/channel needs to allow the transfer of commands
(i.e. rpcs and notifications mixed) because for example (just one, there
are others) a management application dedicated to
monitoring/troubleshooting may need to retrieve additional information
in response to a received fault-notification. I think that in this
situations it is ok to simply interleave messages. "

Hector

=20

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20
> Sent: Thursday, March 23, 2006 12:58 PM
> To: Hector Trevino (htrevino)
> Cc: Phil Shafer; Netconf (E-mail)
> Subject: Re: Notification Message Processing Model
>=20
>  >...
> >> If it's a lose-lose, why allow it?
> >>    =20
> >
> > HT: I think dedicated sessions/channles should be used. But=20
> we can't=20
> > disallow the use of mixed rpcs and notifications because there're=20
> > situations in which you may need to issue rpcs on a notification=20
> > session/channel (as per my example). I say it is a=20
> lose-lose situation=20
> > because if someone decides to use a single session for both then=20
> > chances are the operational needs will not be satisfied w/o adding=20
> > much complexity.
> >
> >  =20
>=20
> I don't see an example. Please explain in more detail.
>=20
> >>  Phil
> >>    =20
>=20
>=20
> Andy
>=20

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



From owner-netconf@ops.ietf.org Thu Mar 23 17:13:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMY3v-0001Cq-TP
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 17:13:47 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMY3u-0001QE-FH
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 17:13:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMXzC-000AmU-VU
	for netconf-data@psg.com; Thu, 23 Mar 2006 22:08:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rpe@juniper.net>)
	id 1FMXzB-000AmF-UF
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 22:08:53 +0000
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25])
  by borg.juniper.net with ESMTP; 23 Mar 2006 14:08:53 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,123,1141632000"; 
   d="scan'208"; a="538377850:sNHT28070560"
Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 23 Mar 2006 14:08:51 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Problem of XML validation
Date: Thu, 23 Mar 2006 14:08:53 -0800
Message-ID: <B9247BD312AF424B92CA4A6B997779DA010A1791@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Problem of XML validation
Thread-Index: AcZLewVgGwZACYxkR06Xl7d14QfHVgDSvJ2Q
From: "Rob Enns" <rpe@juniper.net>
To: "Cridlig Vincent" <vincent.cridlig@loria.fr>,
	<netconf@ops.ietf.org>
X-OriginalArrivalTime: 23 Mar 2006 22:08:51.0930 (UTC) FILETIME=[5E4E03A0:01C64EC6]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5

Putting the xpath expression in an attribute would work,
for example:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <!-- get the user named fred -->
         <filter type=3D"xpath" =
select=3D"top/users/user[name=3D'fred']"/>
       </get-config>
     </rpc>



The RFC-Ed updates would be:

On page 34:
OLD:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the filter element contains an XPath expression.

NEW:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the select attribute on the filter element contains an XPath
         expression.


On page 50:
OLD:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value 'xpath' may be used to indicate that
         the filter element contains an XPath expression.

NEW:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the select attribute on the filter element contains an XPath
         expression.


On page 67:
OLD:
   The :xpath capability modifies the <get> and <get-config> operations
   to accept the value "xpath" in the type attribute of the filter
   element.  When the type attribute is set to "xpath", the contents of
   the filter element will be treated as an xpath expression and used to
   filter the returned data.

NEW:
   The :xpath capability modifies the <get> and <get-config> operations
   to accept the value "xpath" in the type attribute of the filter
   element.  When the type attribute is set to "xpath", a select
   attribute MUST be present on the filter element.  The select
   attribute will be treated as an XPath expression and used to filter
   the returned data.  The filter element itself MUST be empty in this
   case.


On page 67:
OLD:
         <filter type=3D"xpath"> <!-- get the user named fred -->
           top/users/user[name=3D"fred"]
         </filter>

NEW:
         <!-- get the user named fred -->
         <filter type=3D"xpath" =
select=3D"top/users/user[name=3D'fred']"/>


On page 81:
OLD:
           <xs:attribute name=3D"type"
                         type=3D"FilterType" default=3D"subtree"/>

NEW:
           <xs:attribute name=3D"type"
                         type=3D"FilterType" default=3D"subtree"/>
           <!-- if type=3D"xpath", the xpath expression
           appears in the select element -->
           <xs:attribute name=3D"select"/>=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cridlig Vincent
> Sent: Sunday, March 19, 2006 9:33 AM
> To: netconf@ops.ietf.org
> Subject: Problem of XML validation
>=20
> Hi,
>=20
> This is to report a possible issue in the Netconf XML schema.=20
> I try to=20
> validate a simple get-config message but I get some errors.
> I use the Netconf schema and some sample messages from draft 12.
> I tested two "standard" XML schema validator implementations:
> - the one from the C library libxml2
> - the one from the Java library JAXP.
> Twice, I got the result that the <filter> element should be empty.
>=20
> I think the problem comes from the following complexType. It is the=20
> exact definition of an empty element.
> See http://www.w3schools.com/schema/schema_complex_empty.asp
>=20
> <xs:complexType name=3D"filterInlineType">
>   <xs:complexContent>
>     <xs:restriction base=3D"xs:anyType">
>       <xs:attribute name=3D"type" type=3D"FilterType" =
default=3D"subtree"/>
>     </xs:restriction>
>   </xs:complexContent>
> </xs:complexType>
>=20
> I changed it to the following :
>=20
> <xs:complexType name=3D"filterInlineType">
>   <xs:complexContent>
>     <xs:restriction base=3D"xs:anyType">
>       <xs:sequence>
>         <xs:any processContents=3D"skip"/>
>       </xs:sequence>
>       <xs:attribute name=3D"type" type=3D"FilterType" =
default=3D"subtree"/>
>     </xs:restriction>
>   </xs:complexContent>
> </xs:complexType>
>=20
> I put processContents=3D"skip" to not validate the content,=20
> especially because a subtree filter may be correct but not xml valid.
> But now the problem is that it does not allow text content,=20
> only elements (like top). This is a problem for xpath capabilities.
> I don't know how to solve it.
>=20
> Does somebody experiment the same problems ?
>=20
> Best regards,
> Vincent
>=20
>=20
>=20
> =09
>=20
> =09
> 	=09
> ______________________________________________________________
> _____________=20
> Nouveau : t=E9l=E9phonez moins cher avec Yahoo! Messenger !=20
> D=E9couvez les tarifs exceptionnels pour appeler la France et=20
> l'international.
> T=E9l=E9chargez sur http://fr.messenger.yahoo.com
>=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

--
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 Mar 23 19:15:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMZgx-00032e-DT
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 18:58:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMZgr-0007ct-QT
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 18:58:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMZcr-00025G-98
	for netconf-data@psg.com; Thu, 23 Mar 2006 23:53:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FMZcq-00024h-D1
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 23:53:56 +0000
Received: from [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b] (unknown [IPv6:2001:df8:0:128:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id 7A361E60EB
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 23:53:48 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <44233509.8070707@isc.org>
Date: Fri, 24 Mar 2006 00:53:45 +0100
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603232023.k2NKNfYE022289@idle.juniper.net> <44231134.9010908@andybierman.com>
In-Reply-To: <44231134.9010908@andybierman.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Bierman wrote:
> Phil Shafer wrote:
> 
>> Andy Bierman writes:
>>  
>>
>>>   An active NETCONF session has two modes:
>>>     
>>
>>
>> This introduces modality into the netconf session, which
>> is increasing the complexity.
>>
>> Instead, we could just have a simple RPC that is long-lived:
>>
>> C:  <rpc ...>
>> C:    <get-syslog-notifications>
>> C:      <level>warning</level>
>> C:    </get-syslog-notifications>
>> C:  </rpc>
>>
>> The server responds with an <rpc-reply> containing an
>> unending series of notifications which match the criteria from
>> the <get-syslog-notifications> RPC:
>>
>> S:  <rpc-reply ...>
>> S:    <notification> ... data for one notification ... </notification>
>> S:    <notification> ... data for another notification ...
>> </notification>
>> S:    <notification> ... data for yet another notification ...
>> </notification>
>> S:    <notification> ... data for one more notification ...
>> </notification>
>>
>> The notifications would continue until the channel is closed.  Or
>> until we resurrect the <abort/> mechanism ;^)
>>
>> This is simple, direct, and uses the existing netconf framework.
>> If interleaving is a lose-lose, this is a win-win.
>>
>>   
> 
> 
> The objection to this approach in the WG meeting was that off-the-shelf
> validation tools
> will not be able to work because they will be waiting for the </rpc-reply>
> before finishing the validation.  Hence the validation phase never ends.
> 
> I love your approach.
> It would be simple for me to implement.
> I'm not using off-the-shelf validation tools though.

I wonder why not do something like:

C:  <rpc ...>
C:    <get-syslog-notifications>
C:      <level>warning</level>
C:    </get-syslog-notifications>
C:  </rpc>
S:  <rpc-reply ...>
S:     <okay/>
S:  </rpc-reply>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
   .
   .
   .

Each notification is valid XML, self contained. Do we really need to
wrap the set for some reason?

- --
Shane

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEIzUJMsfZxBO4kbQRAib1AKDLhZdxN4OZAW5KfonZiUyFVEIKGQCfboSJ
byuRmLeOXNChjR64oFgmWq4=
=bN6H
-----END PGP SIGNATURE-----

--
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 Mar 23 19:15:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMZgx-0004oI-DW
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 18:58:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMZgv-0007ct-UT
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 18:58:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMZYg-00017w-9P
	for netconf-data@psg.com; Thu, 23 Mar 2006 23:49:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMZYf-00017j-DT
	for netconf@ops.ietf.org; Thu, 23 Mar 2006 23:49:37 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2NNnZZj000513
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 18:49:36 -0500
Received: (qmail 24903 invoked from network); 23 Mar 2006 23:49:34 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 23 Mar 2006 23:49:34 -0000
Message-ID: <4423340D.3050602@andybierman.com>
Date: Thu, 23 Mar 2006 15:49:33 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: Phil Shafer <phil@juniper.net>, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <6E21698722408147BEA594E073E2B0AB0193B1B6@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB0193B1B6@xmb-sjc-223.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Hector Trevino (htrevino) wrote:
> It was in my response to your original e-mail. Pasted below
>
> "From an operational standpoint it makes much more sense to have
> dedicated connections or channels for commands/control & notifications.
> When using SSH it is an operational/resource constraint decision whether
> or not a full dedicated SSH session is used for commands & notifications
> or a single session with multiple channels is utilized.
> A notifications session/channel needs to allow the transfer of commands
> (i.e. rpcs and notifications mixed) because for example (just one, there
> are others) a management application dedicated to
> monitoring/troubleshooting may need to retrieve additional information
> in response to a received fault-notification. I think that in this
> situations it is ok to simply interleave messages. "
>   

Okay.
This is really just part of the previously mentioned advantage that the
management station saves a netconf session per agent,
which saves memory, a TCP connection, and a tiny amount of bandwidth.

The code and documentation complexity are higher when notifications
and RPCs are mixed on the same channel.  That much is established consensus.
Whether or not the additional complexity warrants the manager resource 
savings
is not clear.


> Hector
>   

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 23 20:14:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMasS-0003X6-2Q
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 20:14:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMasQ-0004Bh-Pt
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 20:14:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMaie-000ENN-Pk
	for netconf-data@psg.com; Fri, 24 Mar 2006 01:04:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FMaid-000EN6-Sg
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 01:04:00 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2O0xWv15543
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 19:59:32 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model 
Date: Thu, 23 Mar 2006 20:03:54 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40782EFA3@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model 
Thread-Index: AcZOqwjoNU7nei4USICPPKIIvbw5JwAMz0pA
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

hi

<Phil>
A long-lived RPC running on a distinct channel is trivial and is allowed
within the existing netconf spec for no additional protocol-level work.
Just make a capability that defines your RPCs and you are golden.
</Phil>

The long-lived RPC makes the client much more complicated and prevents
you from supporting quite  a few notification-related features. It is
definitely a false economy to consider it a cheaper solution.

Sharon

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



From owner-netconf@ops.ietf.org Thu Mar 23 21:25:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMbzs-0001P4-Ac
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 21:25:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMbzr-00070K-27
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 21:25:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMbrR-000LHc-TO
	for netconf-data@psg.com; Fri, 24 Mar 2006 02:17:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMbrR-000LHP-9u
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 02:17:09 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2O2H51Z066081;
	Thu, 23 Mar 2006 18:17:05 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2O2H4512456;
	Thu, 23 Mar 2006 18:17:04 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2O2MHYE023920;
	Thu, 23 Mar 2006 21:22:18 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603240222.k2O2MHYE023920@idle.juniper.net>
To: "Sharon Chisholm" <schishol@nortel.com>
cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Thu, 23 Mar 2006 20:03:54 EST."
             <713043CE8B8E1348AF3C546DBE02C1B40782EFA3@zcarhxm2.corp.nortel.com> 
Date: Thu, 23 Mar 2006 21:22:17 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

"Sharon Chisholm" writes:
>The long-lived RPC makes the client much more complicated and prevents
>you from supporting quite  a few notification-related features.

I'm not following you.  How is the client more complex and
what features are blocked from supporting?

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 23 21:29:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMc3l-0003B8-R7
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 21:29:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMc3k-000755-Im
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 21:29:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMbyi-000Lq9-Q8
	for netconf-data@psg.com; Fri, 24 Mar 2006 02:24:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMbyi-000Lpx-AD
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 02:24:40 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2O2Oa1Z066098;
	Thu, 23 Mar 2006 18:24:36 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2O2OX514928;
	Thu, 23 Mar 2006 18:24:33 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2O2ThYE023994;
	Thu, 23 Mar 2006 21:29:47 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603240229.k2O2ThYE023994@idle.juniper.net>
To: shane_kerr@isc.org
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Fri, 24 Mar 2006 00:53:45 +0100."
             <44233509.8070707@isc.org> 
Date: Thu, 23 Mar 2006 21:29:43 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

Shane Kerr writes:
>Each notification is valid XML, self contained. Do we really need to
>wrap the set for some reason?

I see the other side.  Do we really need to break the existing RPC
mechanism for something that can be easily handled within it?  Given
that the notifications are likely to get simple syslog messages,
the requirement to be self contained is easily fulfilled.

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Thu Mar 23 22:16:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMcma-00074L-QT
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 22:16:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMcmZ-0000SZ-Fv
	for netconf-archive@lists.ietf.org; Thu, 23 Mar 2006 22:16:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMcgw-000P5m-2Q
	for netconf-data@psg.com; Fri, 24 Mar 2006 03:10:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMcgv-000P5U-81
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 03:10:21 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2O3AIkQ028121
	for <netconf@ops.ietf.org>; Thu, 23 Mar 2006 22:10:19 -0500
Received: (qmail 9712 invoked by uid 78); 24 Mar 2006 03:10:18 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by omr6.mgt.bos.netsol.com with SMTP; 24 Mar 2006 03:10:18 -0000
Message-ID: <4423630F.6030308@andybierman.com>
Date: Thu, 23 Mar 2006 19:10:07 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: shane_kerr@isc.org, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603240229.k2O2ThYE023994@idle.juniper.net>
In-Reply-To: <200603240229.k2O2ThYE023994@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

Phil Shafer wrote:
> Shane Kerr writes:
>> Each notification is valid XML, self contained. Do we really need to
>> wrap the set for some reason?
> 
> I see the other side.  Do we really need to break the existing RPC
> mechanism for something that can be easily handled within it?  Given
> that the notifications are likely to get simple syslog messages,
> the requirement to be self contained is easily fulfilled.

I believe the kind of tool that only does stand-alone full
document parsing should not be the focus of our design.
This seems to be like designing SNMP for MIB walker tools.
When that happened, it became almost all SNMP was good for.

I suspect that all the actual agent and manager implementers
will be using an event-driven parser, not a document-driven parser.

Since the WG doesn't agree on the functional requirements
for notifications, it is not surprising that there is no
agreement on the solution.  Since all Phil and I really want to do
with NETCONF notifications is deliver text or XML syslog,
this would be fine.  I'm not sure what the rest of the WG
wants to do with these things.

I hate Requirements Documents but this document has hardly
been read or reviewed by anybody in the WG.  I think we
should try to agree on what we want to do with NETCONF
notifications before going any further.  Real use cases,
based on real products, used in real networks -- not
"nice-to-have", "maybe need this someday" features.


> 
> Thanks,
>  Phil

Andy

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



From owner-netconf@ops.ietf.org Fri Mar 24 10:25:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMoA0-0005XB-Lr
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:25:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMo9z-0004JY-7P
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:25:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMo34-0004hf-UF
	for netconf-data@psg.com; Fri, 24 Mar 2006 15:17:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FMo32-0004hQ-90
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 15:17:56 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BEB594F0002
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 16:17:50 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 24 Mar 2006 16:17:50 +0100
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 24 Mar 2006 16:17:50 +0100
Message-ID: <44240D9A.9010003@ericsson.com>
Date: Fri, 24 Mar 2006 16:17:46 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <44221C95.5050406@andybierman.com> <4422C460.8060809@isc.org>
In-Reply-To: <4422C460.8060809@isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Mar 2006 15:17:50.0502 (UTC) FILETIME=[1D5C7C60:01C64F56]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

Hello,
It would be very useful if notifications could somehow reference a netconf RPC. I forsee a 
long running RPC that feeds back multiple results to the netconf manager (could be 
progress indication or something more serious). We could implement this using a set of 
notifications that contain a reference to the RPC.

I see that this can be solved without a combined rpc/notification connection but it might 
be easier putting both on the same channel.

I believe that while normal usage would be to have a separate connection for notifications 
and normal operations, but I feel we could still allow notifications on the normal 
operations channel.

Balazs

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



From owner-netconf@ops.ietf.org Fri Mar 24 10:25:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMoAQ-0006ib-1N
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:25:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMoAP-0004Ko-Fm
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:25:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMo4W-0004nW-V0
	for netconf-data@psg.com; Fri, 24 Mar 2006 15:19:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FMo4U-0004n6-6B
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 15:19:26 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 797C44F0001
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 16:19:25 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 24 Mar 2006 16:19:25 +0100
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 24 Mar 2006 16:19:25 +0100
Message-ID: <44240DF9.6000108@ericsson.com>
Date: Fri, 24 Mar 2006 16:19:21 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603240229.k2O2ThYE023994@idle.juniper.net> <4423630F.6030308@andybierman.com>
In-Reply-To: <4423630F.6030308@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Mar 2006 15:19:25.0141 (UTC) FILETIME=[55C54050:01C64F56]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Hello,
We definitely want to use notifications for alarms (something that the operator must 
handle), events (something that the operator should notice) besides log messages.

A never ending rpc-reply just seems strange/ugly to me. Having an XML element that might 
have infinite size is something I don't like.
I feel that using a never ending rpc-reply is a much bigger deviation from the original 
rpc usage then
- just saying that we don't wrap notifications in an rpc or
- using one-way message wrappers instead of the rpc

Balazs



Andy Bierman wrote:
> Phil Shafer wrote:
>> Shane Kerr writes:
>>> Each notification is valid XML, self contained. Do we really need to
>>> wrap the set for some reason?
>>
>> I see the other side.  Do we really need to break the existing RPC
>> mechanism for something that can be easily handled within it?  Given
>> that the notifications are likely to get simple syslog messages,
>> the requirement to be self contained is easily fulfilled.
> 
> I believe the kind of tool that only does stand-alone full
> document parsing should not be the focus of our design.
> This seems to be like designing SNMP for MIB walker tools.
> When that happened, it became almost all SNMP was good for.
> 
> I suspect that all the actual agent and manager implementers
> will be using an event-driven parser, not a document-driven parser.
> 
> Since the WG doesn't agree on the functional requirements
> for notifications, it is not surprising that there is no
> agreement on the solution.  Since all Phil and I really want to do
> with NETCONF notifications is deliver text or XML syslog,
> this would be fine.  I'm not sure what the rest of the WG
> wants to do with these things.
> 
> I hate Requirements Documents but this document has hardly
> been read or reviewed by anybody in the WG.  I think we
> should try to agree on what we want to do with NETCONF
> notifications before going any further.  Real use cases,
> based on real products, used in real networks -- not
> "nice-to-have", "maybe need this someday" features.
> 
> 
>>
>> Thanks,
>>  Phil
> 
> Andy
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Fri Mar 24 10:34:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMoJL-0001jH-3O
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:34:47 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMoJJ-0004mq-QT
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 10:34:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMoDC-0005di-In
	for netconf-data@psg.com; Fri, 24 Mar 2006 15:28:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMoDB-0005dS-H1
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 15:28:25 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2OFSN1Z072176;
	Fri, 24 Mar 2006 07:28:23 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2OFSN535334;
	Fri, 24 Mar 2006 07:28:23 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2OFXaYE026268;
	Fri, 24 Mar 2006 10:33:36 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603241533.k2OFXaYE026268@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Fri, 24 Mar 2006 16:19:21 +0100."
             <44240DF9.6000108@ericsson.com> 
Date: Fri, 24 Mar 2006 10:33:36 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

Balazs Lengyel writes:
>I feel that using a never ending rpc-reply is a much bigger deviation from the original 

But it's not a deviation; it's completely within the spec.  For
example, JUNOScript has a <ping> RPC.  When you perform this RPC,
the ping operation continue until the connection is terminated or
the <abort/> operation is sent.  There's another RPC called
<get-accounting-record-information> which will feed you accounting
records with the same unending paradigm.  The endless reply is
really quite useful.  Yes, it requires your client to understand
that it cannot buffer data endlessly before passing it up to
interested parties, but a <get-route-information> RPC on a box
with a million routes will do this too.

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 Fri Mar 24 11:37:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMpHS-000636-Ea
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 11:36:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMp5R-0007AA-4A
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 11:24:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMp1F-000ADG-C2
	for netconf-data@psg.com; Fri, 24 Mar 2006 16:20:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMp1E-000AD1-FB
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 16:20:08 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2OGK6vW012829
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 11:20:07 -0500
Received: (qmail 4138 invoked from network); 24 Mar 2006 16:20:05 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 24 Mar 2006 16:20:05 -0000
Message-ID: <44241C36.1030108@andybierman.com>
Date: Fri, 24 Mar 2006 08:20:06 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <200603241533.k2OFXaYE026268@idle.juniper.net>
In-Reply-To: <200603241533.k2OFXaYE026268@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6

Phil Shafer wrote:
> Balazs Lengyel writes:
>> I feel that using a never ending rpc-reply is a much bigger deviation from the original 
> 
> But it's not a deviation; it's completely within the spec.  For
> example, JUNOScript has a <ping> RPC.  When you perform this RPC,
> the ping operation continue until the connection is terminated or
> the <abort/> operation is sent.  There's another RPC called
> <get-accounting-record-information> which will feed you accounting
> records with the same unending paradigm.  The endless reply is
> really quite useful.  Yes, it requires your client to understand
> that it cannot buffer data endlessly before passing it up to
> interested parties, but a <get-route-information> RPC on a box
> with a million routes will do this too.

We already have unbounded strings in NETCONF
(not that I didn't try to get rid of all of them).
Unbounded == infinite length.  I'm not exactly sure
why XSD and the WG think this is so important,
but it's in there, so Phil's proposal wouldn't be a new
implementation burden.  For event-driven parsers,
it is not a problem at all.

Here is yet another solution variant:

---------------------------------------------------

2 New capabilities:

   :notification

OR

   :notification-mixed

Make mixed-mode (RPCs and notifications on the same channel)
a capability.  That means:

  - if the :notification capability is advertised the
     agent will process <rpc> messages (while sending <notification>
     messages) by immediately returning an <rpc-error>

  - if the :notification-mixed capability is advertised instead, the
    agent will process <rpc> messages (while sending <notification>
    messages) in the normal manner.

Neither capability is mandatory-to-implement.

Message flow:

      Manager                 Agent

      rpc/start-notif.   --->
      rpc-reply/ok       <---
      notification       <---
      notification       <---
      rpc/*              --->
      notification       <---
      rpc-reply/*        <---

This is essentially the same as the the current draft,
except the manager has to check for 2 variants of
the notification capability instead of 1, and use
that data to know if it needs 1 session or 2 sessions.

If people find the mixed mode so useful, it will
get implemented and deployed.

This gets rid of never-ending element with capabilities
instead of runtime modes, and lets implementors decide
whether they think mixing notifications and operations
on the same channel is something they want to do.


> 
> Thanks,
>  Phil

Andy

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



From owner-netconf@ops.ietf.org Fri Mar 24 13:03:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMqdj-0003GD-Nt
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:03:59 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMqdi-0004JI-9S
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:03:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMqXj-000IOH-BH
	for netconf-data@psg.com; Fri, 24 Mar 2006 17:57:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <sberl@cisco.com>)
	id 1FMqXi-000IO1-Gb
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 17:57:46 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-1.cisco.com with ESMTP; 24 Mar 2006 09:57:46 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2OHvj7T003731;
	Fri, 24 Mar 2006 09:57:45 -0800 (PST)
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 24 Mar 2006 09:57:44 -0800
Received: from 10.21.98.119 ([10.21.98.119]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ;
 Fri, 24 Mar 2006 17:57:44 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Fri, 24 Mar 2006 09:57:42 -0800
Subject: Re: Notification Message Processing Model 
From: Steve Berl <sberl@cisco.com>
To: Phil Shafer <phil@juniper.net>,
        Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Message-ID: <C0497316.10550%sberl@cisco.com>
Thread-Topic: Notification Message Processing Model 
Thread-Index: AcZPbHJWsRLzELtfEdqN7wARJNUQLA==
In-Reply-To: <200603241533.k2OFXaYE026268@idle.juniper.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 24 Mar 2006 17:57:44.0634 (UTC) FILETIME=[73E8D9A0:01C64F6C]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

The most widely implemented and deployed example of the "never ending reply
XML" is Jabber. There are dozens, if not hundreds of implementations of this
in many different implementation languages. So the argument that it would be
too hard for a manager to implement seems a bit questionable.

-steve

On 3/24/06 7:33 AM, "Phil Shafer" <phil@juniper.net> wrote:

> Balazs Lengyel writes:
>> I feel that using a never ending rpc-reply is a much bigger deviation from
>> the original 
> 
> But it's not a deviation; it's completely within the spec.  For
> example, JUNOScript has a <ping> RPC.  When you perform this RPC,
> the ping operation continue until the connection is terminated or
> the <abort/> operation is sent.  There's another RPC called
> <get-accounting-record-information> which will feed you accounting
> records with the same unending paradigm.  The endless reply is
> really quite useful.  Yes, it requires your client to understand
> that it cannot buffer data endlessly before passing it up to
> interested parties, but a <get-route-information> RPC on a box
> with a million routes will do this too.
> 
> Thanks,
>  Phil
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

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



From owner-netconf@ops.ietf.org Fri Mar 24 13:08:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMqiX-0005Bn-I4
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:08:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMqiX-0004Re-4Q
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:08:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMqcy-000Iw4-1I
	for netconf-data@psg.com; Fri, 24 Mar 2006 18:03:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <sberl@cisco.com>)
	id 1FMqcx-000Ivp-Dz
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 18:03:11 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-3.cisco.com with ESMTP; 24 Mar 2006 10:03:11 -0800
X-IronPort-AV: i="4.03,126,1141632000"; 
   d="scan'208"; a="419923286:sNHT32598080"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2OI3BGv006000;
	Fri, 24 Mar 2006 10:03:11 -0800 (PST)
Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 24 Mar 2006 10:03:10 -0800
Received: from 10.21.98.119 ([10.21.98.119]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ;
 Fri, 24 Mar 2006 18:03:10 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Fri, 24 Mar 2006 10:03:09 -0800
Subject: Re: Notification Message Processing Model
From: Steve Berl <sberl@cisco.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Message-ID: <C049745D.10555%sberl@cisco.com>
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZPbTU/c+v34rtgEdqN7wARJNUQLA==
In-Reply-To: <44240DF9.6000108@ericsson.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 24 Mar 2006 18:03:10.0899 (UTC) FILETIME=[3660F030:01C64F6D]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8

The main use that I see for notifications is for "configuration change
notifications". A netconf based client would like to know if someone else is
changing the configuration, and just what it is that has been changed. The
notification needs to include information about who made the change, when
they made the change, and exactly what they changed. Just a dumb
notification that "something changed" is not good enough. We need to send a
potentially large message describing the actual changes made. This data is
typically too large to send over a standard syslog message or SNMP trap.

-steve


On 3/24/06 7:19 AM, "Balazs Lengyel" <balazs.lengyel@ericsson.com> wrote:

> Hello,
> We definitely want to use notifications for alarms (something that the
> operator must 
> handle), events (something that the operator should notice) besides log
> messages.
> 
> A never ending rpc-reply just seems strange/ugly to me. Having an XML element
> that might 
> have infinite size is something I don't like.
> I feel that using a never ending rpc-reply is a much bigger deviation from the
> original 
> rpc usage then
> - just saying that we don't wrap notifications in an rpc or
> - using one-way message wrappers instead of the rpc
> 
> Balazs
> 
> 
> 
> Andy Bierman wrote:
>> Phil Shafer wrote:
>>> Shane Kerr writes:
>>>> Each notification is valid XML, self contained. Do we really need to
>>>> wrap the set for some reason?
>>> 
>>> I see the other side.  Do we really need to break the existing RPC
>>> mechanism for something that can be easily handled within it?  Given
>>> that the notifications are likely to get simple syslog messages,
>>> the requirement to be self contained is easily fulfilled.
>> 
>> I believe the kind of tool that only does stand-alone full
>> document parsing should not be the focus of our design.
>> This seems to be like designing SNMP for MIB walker tools.
>> When that happened, it became almost all SNMP was good for.
>> 
>> I suspect that all the actual agent and manager implementers
>> will be using an event-driven parser, not a document-driven parser.
>> 
>> Since the WG doesn't agree on the functional requirements
>> for notifications, it is not surprising that there is no
>> agreement on the solution.  Since all Phil and I really want to do
>> with NETCONF notifications is deliver text or XML syslog,
>> this would be fine.  I'm not sure what the rest of the WG
>> wants to do with these things.
>> 
>> I hate Requirements Documents but this document has hardly
>> been read or reviewed by anybody in the WG.  I think we
>> should try to agree on what we want to do with NETCONF
>> notifications before going any further.  Real use cases,
>> based on real products, used in real networks -- not
>> "nice-to-have", "maybe need this someday" features.
>> 
>> 
>>> 
>>> Thanks,
>>>  Phil
>> 
>> Andy
>> 
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <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 Mar 24 13:24:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMqxZ-0007Rb-Dx
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:24:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMqxX-00051j-4B
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 13:24:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMqsm-000KUL-EF
	for netconf-data@psg.com; Fri, 24 Mar 2006 18:19:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMqsl-000KU8-Pl
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 18:19:31 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2OIJUvW027328
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 13:19:30 -0500
Received: (qmail 19249 invoked from network); 24 Mar 2006 18:19:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 24 Mar 2006 18:19:30 -0000
Message-ID: <44243846.7020504@andybierman.com>
Date: Fri, 24 Mar 2006 10:19:50 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Steve Berl <sberl@cisco.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <C049745D.10555%sberl@cisco.com>
In-Reply-To: <C049745D.10555%sberl@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Steve Berl wrote:
> The main use that I see for notifications is for "configuration change
> notifications". A netconf based client would like to know if someone else is
> changing the configuration, and just what it is that has been changed. The
> notification needs to include information about who made the change, when
> they made the change, and exactly what they changed. Just a dumb
> notification that "something changed" is not good enough. We need to send a
> potentially large message describing the actual changes made. This data is
> typically too large to send over a standard syslog message or SNMP trap.

This makes sense.

So far I see a compelling need for 2 standard notification types:

<syslog-event> and <config-change-event>


> 
> -steve

Andy


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



From owner-netconf@ops.ietf.org Fri Mar 24 14:06:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMrcT-0002BO-9p
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 14:06:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMrcS-0006rf-0q
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 14:06:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMrXO-000OEJ-Ia
	for netconf-data@psg.com; Fri, 24 Mar 2006 19:01:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.0
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FMrXN-000OE3-P8
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 19:01:30 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2OJ1SvW031750
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 14:01:28 -0500
Received: (qmail 32099 invoked from network); 24 Mar 2006 19:01:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr2.mgt.bos.netsol.com with SMTP; 24 Mar 2006 19:01:22 -0000
Message-ID: <4424421C.2030808@andybierman.com>
Date: Fri, 24 Mar 2006 11:01:48 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: NETCONF 1.0 -- IESG Approval
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

Hi,

In case you don't know already, the IESG has approved
the 1.0 document set.   Simon and I would like to thank
the WG for all their hard work getting this done.

I would especially like to thank the document Editors,
Rob Enns, Margaret Wasserman, Eliot Lear, and Ted Goddard.
I'm not sure all these people knew how much work they
signed up for when we started the XMLCONF Design Team about
6 years ago, but they hung in there anyway.


thanks,
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 Fri Mar 24 15:29:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMsum-0007JY-C6
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 15:29:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMsul-0001PT-3d
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 15:29:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMsoj-0004LC-Eg
	for netconf-data@psg.com; Fri, 24 Mar 2006 20:23:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FMsoi-0004Kw-Q1
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 20:23:28 +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 k2OKNIX59417;
	Fri, 24 Mar 2006 12:23:22 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2OKNB595169;
	Fri, 24 Mar 2006 12:23:12 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2OKSPYE027254;
	Fri, 24 Mar 2006 15:28:25 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603242028.k2OKSPYE027254@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: NETCONF 1.0 -- IESG Approval 
In-Reply-To: Your message of "Fri, 24 Mar 2006 11:01:48 PST."
             <4424421C.2030808@andybierman.com> 
Date: Fri, 24 Mar 2006 15:28:25 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

Andy Bierman writes:
>In case you don't know already, the IESG has approved
>the 1.0 document set.   Simon and I would like to thank
>the WG for all their hard work getting this done.

<confetti/>

Congratulations to everyone and I echo Andy's thanks
for all the hard work and endurance!!

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 Fri Mar 24 16:34:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMtvO-0003um-UB
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 16:34:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMtvO-0004FI-Kv
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 16:34:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMtr3-0009tC-Pi
	for netconf-data@psg.com; Fri, 24 Mar 2006 21:29:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.0
Received: from [192.11.222.161] (helo=ihemail1.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FMtr3-0009t0-28
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 21:29:57 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2OLTr2i003718;
	Fri, 24 Mar 2006 15:29:54 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <H3GDVW7T>; Fri, 24 Mar 2006 22:29:52 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509A15600@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>
Subject: RE: NETCONF 1.0 -- IESG Approval
Date: Fri, 24 Mar 2006 22:29:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

May I as (now) EX-AD also congratulate you!
I tried very hard to get all hurdles out of the way beforfe
I stepped down. We nearly missed it. But since all people
reacted promptly and since other ADs did also help me to
try and get issues resolved, we made it!

Now... don't rest too long. Let us work on the next step(s)!

Bert


> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Friday, March 24, 2006 13:02
> To: Netconf (E-mail)
> Subject: NETCONF 1.0 -- IESG Approval
> 
> 
> Hi,
> 
> In case you don't know already, the IESG has approved
> the 1.0 document set.   Simon and I would like to thank
> the WG for all their hard work getting this done.
> 
> I would especially like to thank the document Editors,
> Rob Enns, Margaret Wasserman, Eliot Lear, and Ted Goddard.
> I'm not sure all these people knew how much work they
> signed up for when we started the XMLCONF Design Team about
> 6 years ago, but they hung in there anyway.
> 
> 
> thanks,
> 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/>
> 

--
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 Mar 24 18:59:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMwC0-0003vb-FX
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 18:59:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMwBz-0001Vf-1K
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 18:59:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMw75-000JOG-FB
	for netconf-data@psg.com; Fri, 24 Mar 2006 23:54:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FMw74-000JMx-D0
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 23:54:38 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ONrMEP024536
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 18:53:22 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2ONpRhj009509
	for <netconf@ops.ietf.org>; Fri, 24 Mar 2006 18:51:28 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: NETCONF 1.0 -- IESG Approval
Date: Sat, 25 Mar 2006 01:54:35 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F2FDB@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: NETCONF 1.0 -- IESG Approval
Thread-Index: AcZPilB+WNht2DfSRWuzdm6Tz2U5TgAEsc8A
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com>,
        "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

Congratulations to the editors, the WG chairs and the participants in
the WG. Special thanks to Bert - it is just fair that this important
protocol was approved in his last day as AD, as he supported, advised
and kept honest this effort all along. Let us continue the effort and
make NETCONF the protocol that the IP industry needs.

Dan
=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, March 24, 2006 11:30 PM
> To: Andy Bierman; Netconf (E-mail)
> Subject: RE: NETCONF 1.0 -- IESG Approval
>=20
> May I as (now) EX-AD also congratulate you!
> I tried very hard to get all hurdles out of the way beforfe I=20
> stepped down. We nearly missed it. But since all people=20
> reacted promptly and since other ADs did also help me to try=20
> and get issues resolved, we made it!
>=20
> Now... don't rest too long. Let us work on the next step(s)!
>=20
> Bert
>=20
>=20
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org]On
> > Behalf Of Andy Bierman
> > Sent: Friday, March 24, 2006 13:02
> > To: Netconf (E-mail)
> > Subject: NETCONF 1.0 -- IESG Approval
> >=20
> >=20
> > Hi,
> >=20
> > In case you don't know already, the IESG has approved
> > the 1.0 document set.   Simon and I would like to thank
> > the WG for all their hard work getting this done.
> >=20
> > I would especially like to thank the document Editors, Rob Enns,=20
> > Margaret Wasserman, Eliot Lear, and Ted Goddard.
> > I'm not sure all these people knew how much work they signed up for=20
> > when we started the XMLCONF Design Team about
> > 6 years ago, but they hung in there anyway.
> >=20
> >=20
> > thanks,
> > Andy and Simon
> >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> netconf-request@ops.ietf.org with the=20
> > 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=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Fri Mar 24 19:24:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMwZx-00006D-2K
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 19:24:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMwZv-0002nw-PF
	for netconf-archive@lists.ietf.org; Fri, 24 Mar 2006 19:24:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FMwVq-000L6D-6v
	for netconf-data@psg.com; Sat, 25 Mar 2006 00:20:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rpe@juniper.net>)
	id 1FMwVp-000L60-JN
	for netconf@ops.ietf.org; Sat, 25 Mar 2006 00:20:13 +0000
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25])
  by borg.juniper.net with ESMTP; 24 Mar 2006 16:20:14 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,127,1141632000"; 
   d="scan'208"; a="538632122:sNHT22842376"
Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 24 Mar 2006 16:20:12 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: NETCONF 1.0 -- IESG Approval
Date: Fri, 24 Mar 2006 16:19:30 -0800
Message-ID: <B9247BD312AF424B92CA4A6B997779DA010A188C@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: NETCONF 1.0 -- IESG Approval
Thread-Index: AcZPdYm5WgXs79oKQWiNQUx+HOTE2gAKdwtQ
From: "Rob Enns" <rpe@juniper.net>
To: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com>
Cc: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 25 Mar 2006 00:20:12.0654 (UTC) FILETIME=[E1FED0E0:01C64FA1]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

Way cool!

I'll add my congrats and thanks to all involved.=20

And before the music starts playing...

To Bert, thanks for your support and encouragement=20
from the XMLCONF days up to the present.=20

To Andy and Simon, thanks for pushing and prodding us along.

To the XMLCONF design team and NETCONF authors: we did it!

Rob

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Friday, March 24, 2006 11:02 AM
> To: Netconf (E-mail)
> Subject: NETCONF 1.0 -- IESG Approval
>=20
> Hi,
>=20
> In case you don't know already, the IESG has approved
> the 1.0 document set.   Simon and I would like to thank
> the WG for all their hard work getting this done.
>=20
> I would especially like to thank the document Editors,
> Rob Enns, Margaret Wasserman, Eliot Lear, and Ted Goddard.
> I'm not sure all these people knew how much work they
> signed up for when we started the XMLCONF Design Team about
> 6 years ago, but they hung in there anyway.
>=20
>=20
> thanks,
> Andy and Simon
>=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/>
>=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 Sat Mar 25 15:12:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNF7S-0006Ly-LC
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 15:12:18 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNF7R-0006T5-Bz
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 15:12:18 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNF1G-000Gl7-EP
	for netconf-data@psg.com; Sat, 25 Mar 2006 20:05:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNF1D-000Gkn-AC
	for netconf@ops.ietf.org; Sat, 25 Mar 2006 20:05:51 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2PK5oZj008425
	for <netconf@ops.ietf.org>; Sat, 25 Mar 2006 15:05:50 -0500
Received: (qmail 1237 invoked from network); 25 Mar 2006 20:05:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (24.24.133.237)
  by omr1.mgt.bos.netsol.com with SMTP; 25 Mar 2006 20:05:49 -0000
Message-ID: <4425A278.5000804@andybierman.com>
Date: Sat, 25 Mar 2006 12:05:12 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Interim attendance survey
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Hi,


I want to do a survey to measure interest in the
NETCONF Notification work.  Very few people read
the draft before the meeting, let alone reviewed it,
despite numerous pleas. 

There are 3 choices (option 4: don't care, I already know about):

1) I do not want the NETCONF notification work to continue
   and I will not attend the interim meeting.

2) I want the NETCONF notification work to continue
   but I will not be able to attend the interim meeting.

3) I want the NETCONF notification work to continue
   and I will be able to attend some or all of the 3 day interim meeting.


Possible location: Outside North America;
                   (hopefully w/ non-stop flights from all over)
                   (3 IETFs in a row in NA already)

Possible dates: 1 - 2 months before the Montreal IETF (May - June)


Please send comments to the list.


thanks,
Andy




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



From owner-netconf@ops.ietf.org Sat Mar 25 15:56:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNFoa-0004df-RW
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 15:56:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNFoa-00007D-Ex
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 15:56:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNFiK-000M34-RT
	for netconf-data@psg.com; Sat, 25 Mar 2006 20:50:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FNFiK-000M2s-22
	for netconf@ops.ietf.org; Sat, 25 Mar 2006 20:50:24 +0000
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
  by borg.juniper.net with ESMTP; 25 Mar 2006 12:50:23 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,128,1141632000"; 
   d="scan'208"; a="538804195:sNHT25186084"
Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Sat, 25 Mar 2006 12:50:23 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Message Processing Model
Date: Sat, 25 Mar 2006 12:50:22 -0800
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5014FE468@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Message Processing Model
Thread-Index: AcZO8KFfNlv6Lt/URUC4v0qFyg9OpwAsnlxg
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Phil Shafer" <phil@juniper.net>
Cc: <shane_kerr@isc.org>,
	"Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 25 Mar 2006 20:50:23.0100 (UTC) FILETIME=[BC7313C0:01C6504D]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024


Andy Bierman wrote:
> I hate Requirements Documents but this document has hardly
> been read or reviewed by anybody in the WG.  I think we
> should try to agree on what we want to do with NETCONF
> notifications before going any further.  Real use cases,
> based on real products, used in real networks -- not
> "nice-to-have", "maybe need this someday" features.

NSM is Juniper's Enterprise-class NMS/EMS having a rather
diverse set of users:  small-to-medium enterprise, large
enterprise, retail outlet chains, service providers, telcos,=20
federal, etc.

At the EMS-level, users want NSM to present management
as a suite of service-oriented applications - configuration
manager, software manager, status monitor, log analyzer,=20
troubleshooter, etc.

Architecturally, NSM is composed of service-oriented=20
components on a message bus - each having its own
logical connection to the device.  For instance, both the
configuration manager and the status monitor would
have their own NetConf session with the device to serve
their own needs.

However, both of these components desire the ability to
receive asynchronous notifications relevant to them - to
avoid polling for deltas periodically, which doesn't scale.
For instance, the configuration manager would like to be
notified when interesting parts of the config change due
to an out-of-band modification (i.e. via CLI, webUI, or
another management application).  Likewise, the status
monitor would like to be notified whenever interesting
parts of the device's state have changed beyond some
threshold.  Ideally, both of these notifications should
contain that which has changed (i.e. an XML sub-tree) to
avoid the need to poll for it with an <rpc>.

Please note that the log analyzer component, which has
its own logical connection to the device, may or may not
be interested in these same events - pending how it
has been configured.  But it definitely does not want the
events to be heirarchally-structured as it ultimately must
operate on a normalized list of fields - as customers want
the log viewer to present logs as if they are rows in a table
with a fixed number of columns... While the log analyzer
component could receive flattened xml logs, the value=20
of this over structured syslog is not clear and surely the
processing of xml would be more expensive, which would
have a negative impact on our logging rate.

The net of all this is that we would like netconf to have a
publish-subscribe interface for notifications on the same
schema that netconf itself operates on.  Each subscription
should allow for any number of schema-based interest-
expressions and notifications should be the matching xml
sub-tree that may be pruned down by another filter.  Also,
I'd like to add that we view subscriptions to be somewhat
dynamic - for instance, as the user is clicking around the
interface, the status monitor might be subscribing and=20
unsubscribing to different parts of the schema for the=20
purpose of providing real-time updates to whatever the
user is looking at.

Hope that helps - and congrats on the IESG approval!

Kent


--
Kent Watsen
NSM Architect
Juniper Networks


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



From owner-netconf@ops.ietf.org Sat Mar 25 16:38:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNGT2-0000bm-9w
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 16:38:40 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNGT1-0001gK-RD
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 16:38:40 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNGOF-000Oqy-GN
	for netconf-data@psg.com; Sat, 25 Mar 2006 21:33:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [209.173.57.84] (helo=cypress.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FMo2e-0004ea-Ec
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 15:17:32 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2OFHR0e023781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Mar 2006 15:17:27 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FMo2Z-0002lT-Fv; Fri, 24 Mar 2006 10:17:27 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
   RFC Editor <rfc-editor@rfc-editor.org>,
   netconf mailing list <netconf@ops.ietf.org>,
   netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com>
Subject: Protocol Action: 'NETCONF Configuration Protocol' to Proposed 
         Standard 
Message-Id: <E1FMo2Z-0002lT-Fv@stiedprstage1.ietf.org>
Date: Fri, 24 Mar 2006 10:17:27 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae

The IESG has approved the following documents:

- 'NETCONF Configuration Protocol '
   <draft-ietf-netconf-prot-12.txt> as a Proposed Standard
- 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) '
   <draft-ietf-netconf-ssh-06.txt> as a Proposed Standard

These documents are products of the Network Configuration Working Group. 

The IESG contact persons are Bert Wijnen and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt

Technical Summary
 
  NETCONF Configuration Protocol

  The NETCONF configuration protocol defined in this document provides
  mechanisms to install, manipulate, and delete the configuration of
  network devices.  It uses an Extensible Markup Language (XML) based
  data encoding for the configuration data as well as the protocol
  messages.  The NETCONF protocol operations are realized on top of a
  simple Remote Procedure Call (RPC) layer.

  Using the NETCONF Configuration Protocol over Secure Shell (SSH)

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

  Note:  The WG could not decide on a single transport mapping for
  NETCONF, because different types of programmers want to use the
  protocol.  Therefore, NETCONF defines three transport mappings: 
  SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement
  protocol. 

Working Group Summary
 
  The NETCONF Working Group has consensus to publish these documents
  as a Proposed Standard.  

Protocol Quality

  It is likely that there are several implementations of these
  documents in various stages of completion at this time.
  Several major equipment vendors have indicated interest in
  supporting this document, and some non-commercial
  implementations are also expected.
  An interoperability event (just prior to Paris IETF) was held
  in which 4 implementations participated and feedback was
  considered in revisions of these documents.

  Bert Wijnen reviewed these documents for the IESG.


Note to RFC Editor

I appologize for the pretty extensive changes, but this was the
only way to get this document approved before I am stepping down
as AD (thanks, Bert)

Please make the following changes:

------ for the draft-ietf-netconf-ssh-06.txt document ----------

- In section 3, page 3 (last line) and 4:

  OLD:

   SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
   script to recognize shell prompts or skip over extraneous
   information, such as a system message that is sent at shell start-up.
   However, if a subsystem cannot be used, it should be possible for a
   client to skip over any system messages that are sent at shell
   start-up by searching for a NETCONF <hello> element.  Note that this
   may not avoid problems if system messages are recieved later in the
   session.

  NEW:
   SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
   script to recognize shell prompts or skip over extraneous
   information, such as a system message that is sent at shell start-up.
   However, even when a subsystem is used, some extraneous messages may
   be printed by the user's start-up scripts.  Implementations MUST
   skip over these messages by searching for an 'xml' start directive,
   which MUST be followed by a <hello> element in the 'NETCONF' namespace.

- In section 5, page 6, line 4 in 1st para:

  OLD:

  ...and terminate the SSH session.

  NEW:

  ...and close the SSH session channel.

----- in the draft-ietf-netconf-prot-12.txt document ----------

Page 16:
OLD:
      The following <rpc-reply> illustrates the case of returning
      multiple <rpc-error> elements.

NEW: 
      The following <rpc-reply> illustrates the case of returning
      multiple <rpc-error> elements.

      Note that the data models used in the examples in this section use
      the <name> element to distinguish between multiple instances of
      the <interface> element.

On page 34:
OLD:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the filter element contains an XPath expression.

NEW:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the select attribute on the filter element contains an XPath
         expression.

Page 39, bottom:

OLD:

   Example:

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:

NEW:

   Example:

       The <edit-config> examples in this section utilize a simple
       data model, in which multiple instances of the 'interface'
       element may be present, and an instance is distinguished
       by the 'name' element within each 'interface' element.

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:



On page 50:
OLD:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value 'xpath' may be used to indicate that
         the filter element contains an XPath expression.

NEW:
         If the NETCONF peer supports the :xpath capability
         (Section 8.9), the value "xpath" may be used to indicate that
         the select attribute on the filter element contains an XPath
         expression.


On page 67:
OLD:
   The :xpath capability modifies the <get> and <get-config> operations
   to accept the value "xpath" in the type attribute of the filter
   element.  When the type attribute is set to "xpath", the contents of
   the filter element will be treated as an xpath expression and used to
   filter the returned data.

NEW:
   The :xpath capability modifies the <get> and <get-config> operations
   to accept the value "xpath" in the type attribute of the filter
   element.  When the type attribute is set to "xpath", a select
   attribute MUST be present on the filter element.  The select
   attribute will be treated as an XPath expression and used to filter
   the returned data.  The filter element itself MUST be empty in this
   case.

On page 67:
OLD:
         <filter type="xpath"> <!-- get the user named fred -->
           top/users/user[name="fred"]
         </filter>

NEW:
         <!-- get the user named fred -->
         <filter type="xpath" select="top/users/user[name='fred']"/>


On page 81:
OLD:
           <xs:attribute name="type"
                         type="FilterType" default="subtree"/>

NEW:
           <xs:attribute name="type"
                         type="FilterType" default="subtree"/>
           <!-- if type="xpath", the xpath expression
           appears in the select element -->
           <xs:attribute name="select"/> 

IANA Note

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, March 23, 2006 14:39
To: Bert Wijnen; iana@iana.org
Subject: Port request for draft-ietf-netconf-ssh-06.txt


Hi,

Please assign a port number < 1024 for the NETCONF
protocol over the Secure Shell protocol, as specified
in section 7 of this document.

thanks,
Andy




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



From owner-netconf@ops.ietf.org Sat Mar 25 16:38:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNGT3-0000cy-J1
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 16:38:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNGT3-0001gP-78
	for netconf-archive@lists.ietf.org; Sat, 25 Mar 2006 16:38:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNGOS-000Orh-9R
	for netconf-data@psg.com; Sat, 25 Mar 2006 21:33:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [209.173.53.84] (helo=willow.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FMoEA-0005j8-9H
	for netconf@ops.ietf.org; Fri, 24 Mar 2006 15:29:26 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2OFTO9W019381
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Mar 2006 15:29:24 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FMoE8-0006Dj-H4; Fri, 24 Mar 2006 10:29:24 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
   RFC Editor <rfc-editor@rfc-editor.org>,
   netconf mailing list <netconf@ops.ietf.org>,
   netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com>
Subject: Protocol Action: 'Using the Network Configuration Protocol 
         (NETCONF) Over the Simple Object Access Protocol (SOAP)' to Proposed 
         Standard 
Message-Id: <E1FMoE8-0006Dj-H4@stiedprstage1.ietf.org>
Date: Fri, 24 Mar 2006 10:29:24 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db

The IESG has approved the following document:

- 'Using the Network Configuration Protocol (NETCONF) Over the Simple Object 
   Access Protocol (SOAP) '
   <draft-ietf-netconf-soap-08.txt> as a Proposed Standard

This document is the product of the Network Configuration Working Group. 

The IESG contact persons are Bert Wijnen and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt

Technical Summary
 
   The Network Configuration Protocol (NETCONF) is applicable to a wide
   range of devices in a variety of environments.  The emergence of Web
   Services gives one such environment, and is presently characterized
   by the use of the Simple Object Access Protocol (SOAP).  NETCONF
   finds many benefits in this environment: from the re-use of existing
   standards, to ease of software development, to integration with
   deployed systems.  Herein, we describe SOAP over HTTP and SOAP over
   BEEP bindings for NETCONF.

Working Group Summary
 
   The NETCONF Working Group has consensus to publish this document
   as a Proposed Standard.  

Protocol Quality

   It is likely that there are several implementations of this
   document in various stages of completion at this time.
   Several major equipment vendors have indicated interest in
   supporting this document, and some non-commercial
   implementations are also expected.
   Bert Wijnen reviewed this document for the IESG.

Note to RFC Editor

In the IAN Considerations section, please change:
 
OLD:

   The IANA is requested to assign TCP ports for NETCONF for SOAP over
   HTTP and SOAP over BEEP.

NEW:

   The IANA is requested to assign a TCP port for NETCONF over SOAP over
   BEEP, and a TCP port for NETCONF over SOAP over HTTPS.

IANA Note

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, March 23, 2006 14:58
To: Bert Wijnen
Cc: iana@iana.org; Sam Hartman (E-mail)
Subject: Port requests for draft-ietf-netconf-soap-08.txt


Hi,

Please assign a port number < 1024 for the NETCONF
protocol over the Simple Object Access protocol,
run over the Blocks Extensible Exchange protocol
(netconf-soap-beep). 

Please assign a port number < 1024 for the NETCONF
protocol over the Simple Object Access protocol,
run over the HTTPS protocol (netconf-soap-https). 

There will be an RFC Editor note added to this
document to replace the first sentence of section 5.


OLD:

   The IANA is requested to assign TCP ports for NETCONF for SOAP over
   HTTP and SOAP over BEEP.

NEW:

   The IANA is requested to assign a TCP port for NETCONF over SOAP over
   BEEP, and a TCP port for NETCONF over SOAP over HTTPS.

thanks,
Andy




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



From owner-netconf@ops.ietf.org Sun Mar 26 02:29:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNPga-0000Pc-0L
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 02:29:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNPdi-0007Ia-Mv
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 02:26:20 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNPWr-000JeP-DD
	for netconf-data@psg.com; Sun, 26 Mar 2006 07:19:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FNPWp-000JeA-T1
	for netconf@ops.ietf.org; Sun, 26 Mar 2006 07:19:12 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 8425355D0A;
	Sun, 26 Mar 2006 09:19:10 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 24361-10; Sun, 26 Mar 2006 09:19:08 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id C84DD55D08;
	Sun, 26 Mar 2006 09:19:08 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 70AD264C69B; Sun, 26 Mar 2006 09:19:08 +0200 (CEST)
Date: Sun, 26 Mar 2006 09:19:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
Message-ID: <20060326071908.GB22420@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <4425A278.5000804@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4425A278.5000804@andybierman.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

On Sat, Mar 25, 2006 at 12:05:12PM -0800, Andy Bierman wrote:

> There are 3 choices (option 4: don't care, I already know about):
> 
> 1) I do not want the NETCONF notification work to continue
>   and I will not attend the interim meeting.
> 
> 2) I want the NETCONF notification work to continue
>   but I will not be able to attend the interim meeting.
> 
> 3) I want the NETCONF notification work to continue
>   and I will be able to attend some or all of the 3 day interim meeting.

I guess I am in 2), but I might change to 3) in case the meeting
happens to be at a very convenient place (from my biased European
perspective of course).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Sun Mar 26 14:09:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNabr-0007aD-OU
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 14:09:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNabr-0004M1-Aj
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 14:09:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNaVF-000AOk-Au
	for netconf-data@psg.com; Sun, 26 Mar 2006 19:02:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FNaVE-000AOY-Ft
	for netconf@ops.ietf.org; Sun, 26 Mar 2006 19:02:16 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2QJ1EJ4007405
	for <netconf@ops.ietf.org>; Sun, 26 Mar 2006 14:01:14 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2QIk7Yj011470
	for <netconf@ops.ietf.org>; Sun, 26 Mar 2006 13:46:08 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: Interim attendance survey
Date: Sun, 26 Mar 2006 21:02:13 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3594@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQR9BGDcA4agshRMqfysSM4MgsNQAvzLvw
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17

As a contributor I would like the NETCONF notification work to continue
and be completed in time.=20

As AD and WG Area Advisor I would like to attend the meeting. However my
schedule is completely booked all May and the first days of June, until
6/5. Yet, my participation is not of condition for the meeting
happening.=20

I prefer European venues to North-American ones.=20

Dan




=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Saturday, March 25, 2006 10:05 PM
> To: Netconf (E-mail)
> Subject: Interim attendance survey
>=20
> Hi,
>=20
>=20
> I want to do a survey to measure interest in the NETCONF=20
> Notification work.  Very few people read the draft before the=20
> meeting, let alone reviewed it, despite numerous pleas.=20
>=20
> There are 3 choices (option 4: don't care, I already know about):
>=20
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.
>=20
> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.
>=20
> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day=20
> interim meeting.
>=20
>=20
> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)
>=20
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>=20
>=20
> Please send comments to the list.
>=20
>=20
> thanks,
> Andy
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Mar 26 15:04:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNbTa-0005wD-AF
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 15:04:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNbTZ-0006Qa-Mv
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 15:04:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNbPi-000Dig-5l
	for netconf-data@psg.com; Sun, 26 Mar 2006 20:00:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNbPh-000DiD-3C
	for netconf@ops.ietf.org; Sun, 26 Mar 2006 20:00:37 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2QK0Zts026373
	for <netconf@ops.ietf.org>; Sun, 26 Mar 2006 15:00:35 -0500
Received: (qmail 15704 invoked by uid 78); 26 Mar 2006 20:00:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 26 Mar 2006 20:00:35 -0000
Message-ID: <4426F2EF.6010007@andybierman.com>
Date: Sun, 26 Mar 2006 12:00:47 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3594@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3594@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5

Romascanu, Dan (Dan) wrote:
> As a contributor I would like the NETCONF notification work to continue
> and be completed in time. 
> 
> As AD and WG Area Advisor I would like to attend the meeting. However my
> schedule is completely booked all May and the first days of June, until
> 6/5. Yet, my participation is not of condition for the meeting
> happening. 
> 
> I prefer European venues to North-American ones. 

Me too. But it's actually a policy (AFAIK) that interim meetings
take into consideration recent (and next) IETF locations and try
to be fair.  I also think we need to be practical, so I think
London would be a good location.  It might be easier with a local
host to setup the logistics (Simon and I are not located near London).

I'm not actually convinced yet this work matters enough to
the WG to be continued.  IMO, this is a "nice-to-have" feature
not a "must-have" (like a replacement for screen scraping CLI w/Expect).

For many WG members, a replacement for syslog is a "don't-need" feature.
Combine "don't-need" with "nice-to-have" and the outcome isn't very
surprising:

    -- very few people reviewed the draft
    -- very little agreement on the problem space
    -- no agreement on the solution

An interim meeting would be a last-ditch attempt to get consensus
started somewhere, before giving up.


> 
> Dan

Andy

> 
> 
> 
> 
>  
>  
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Saturday, March 25, 2006 10:05 PM
>> To: Netconf (E-mail)
>> Subject: Interim attendance survey
>>
>> Hi,
>>
>>
>> I want to do a survey to measure interest in the NETCONF 
>> Notification work.  Very few people read the draft before the 
>> meeting, let alone reviewed it, despite numerous pleas. 
>>
>> There are 3 choices (option 4: don't care, I already know about):
>>
>> 1) I do not want the NETCONF notification work to continue
>>    and I will not attend the interim meeting.
>>
>> 2) I want the NETCONF notification work to continue
>>    but I will not be able to attend the interim meeting.
>>
>> 3) I want the NETCONF notification work to continue
>>    and I will be able to attend some or all of the 3 day 
>> interim meeting.
>>
>>
>> Possible location: Outside North America;
>>                    (hopefully w/ non-stop flights from all over)
>>                    (3 IETFs in a row in NA already)
>>
>> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>>
>>
>> Please send comments to the list.
>>
>>
>> thanks,
>> Andy
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org 
>> with the word 'unsubscribe' in a single line as the message text body.
>> archive: <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 Sun Mar 26 19:52:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNfxi-0002Uq-CW
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 19:52:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNfxh-00018M-2f
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 19:52:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNfqa-0004PI-65
	for netconf-data@psg.com; Mon, 27 Mar 2006 00:44:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNfqY-0004P2-WD
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 00:44:39 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2R0iYW16452
	for <netconf@ops.ietf.org>; Sun, 26 Mar 2006 19:44:34 -0500 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Interim attendance survey
Date: Sun, 26 Mar 2006 19:44:29 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4078952EF@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQSKTBk+YBq1OPTluwGUAwkHB7BQA7uDbg
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Door number 3.

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Saturday, March 25, 2006 3:05 PM
To: Netconf (E-mail)
Subject: Interim attendance survey


Hi,


I want to do a survey to measure interest in the
NETCONF Notification work.  Very few people read
the draft before the meeting, let alone reviewed it,
despite numerous pleas.=20

There are 3 choices (option 4: don't care, I already know about):

1) I do not want the NETCONF notification work to continue
   and I will not attend the interim meeting.

2) I want the NETCONF notification work to continue
   but I will not be able to attend the interim meeting.

3) I want the NETCONF notification work to continue
   and I will be able to attend some or all of the 3 day interim
meeting.


Possible location: Outside North America;
                   (hopefully w/ non-stop flights from all over)
                   (3 IETFs in a row in NA already)

Possible dates: 1 - 2 months before the Montreal IETF (May - June)


Please send comments to the list.


thanks,
Andy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Sun Mar 26 21:26:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNhRD-0001dZ-VL
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 21:26:35 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNhRC-0004Xy-GY
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 21:26:35 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNhL1-0009Z6-EY
	for netconf-data@psg.com; Mon, 27 Mar 2006 02:20:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FNhKy-0009Yq-RT
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 02:20:08 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2R2K6wA012441;
	Sun, 26 Mar 2006 18:20:07 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2R2K6AT012433;
	Sun, 26 Mar 2006 18:20:06 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Sun, 26 Mar 2006 18:20:06 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
In-Reply-To: <4425A278.5000804@andybierman.com>
Message-ID: <Pine.LNX.4.10.10603261815330.9058-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

HI,

The topic of notifications (including filtering, loging, encoding,
distribution, etc) is one of my favorite interest areas. Without
details of where and when, I cannot commit to attending in person.
However, I would be able to listen in on an audio feed.

Regards,
/david t. perkins
On Sat, 25 Mar 2006, Andy Bierman wrote:
> Hi,
> 
> I want to do a survey to measure interest in the
> NETCONF Notification work.  Very few people read
> the draft before the meeting, let alone reviewed it,
> despite numerous pleas. 
> 
> There are 3 choices (option 4: don't care, I already know about):
> 
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.
> 
> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.
> 
> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day interim meeting.
> 
> 
> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)
> 
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> 
> 
> Please send comments to the list.
> 
> 
> thanks,
> Andy
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Sun Mar 26 22:02:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNhzv-0003zf-HB
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 22:02:27 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNhzu-0005wj-Sa
	for netconf-archive@lists.ietf.org; Sun, 26 Mar 2006 22:02:27 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNhvf-000BVp-Iw
	for netconf-data@psg.com; Mon, 27 Mar 2006 02:58:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 
	autolearn=ham version=3.1.1
Received: from [202.232.30.157] (helo=omgo.iij.ad.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ray@iijlab.net>)
	id 1FNhve-000BVb-G1
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 02:58:02 +0000
Received: OTM-MO id k2R2w1Dn012758; Mon, 27 Mar 2006 11:58:01 +0900 (JST)
Received: OTM-MIX0 id k2R2w0o0020030; Mon, 27 Mar 2006 11:58:00 +0900 (JST)
Received: from localhost (h169n190.iij.ad.jp [192.168.190.169])
	by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k2R2vsUH014284
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 11:58:00 +0900 (JST)
Date: Mon, 27 Mar 2006 11:58:00 +0900 (LMT)
Message-Id: <20060327.115800.60844819.ray@iijlab.net>
To: netconf@ops.ietf.org
Subject: Re: Interim attendance survey
From: "Ray S. Atarashi" <ray@iijlab.net>
In-Reply-To: <4425A278.5000804@andybierman.com>
References: <4425A278.5000804@andybierman.com>
X-Mailer: Mew version 4.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

Hi, 

I guess I (and some Japanese guy) can arrange the interim meeting
in Japan. How do you think to be held the interim meeting in
Japan? 

I want to attend the interim meeting, but I can't travel now. 
If the interim meeing is held in Japan, I am in 3), if not, I am
in 2).

Ray


From: Andy Bierman <ietf@andybierman.com>
> Hi,
> 
> 
> I want to do a survey to measure interest in the
> NETCONF Notification work.  Very few people read
> the draft before the meeting, let alone reviewed it,
> despite numerous pleas. 
> 
> There are 3 choices (option 4: don't care, I already know about):
> 
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.
> 
> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.
> 
> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day interim meeting.
> 
> 
> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)
> 
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> 
> 
> Please send comments to the list.
> 
> 
> thanks,
> Andy
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Mar 27 03:27:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNn4g-00021x-Um
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 03:27:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNn4X-0001d9-99
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 03:27:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNmy7-0001qE-QJ
	for netconf-data@psg.com; Mon, 27 Mar 2006 08:20:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FNmy7-0001pz-74
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 08:20:55 +0000
Received: from [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b] (unknown [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id 6ACCDE606F
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 08:20:54 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <4427A064.1020007@isc.org>
Date: Mon, 27 Mar 2006 10:20:52 +0200
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <4425A278.5000804@andybierman.com> <20060326071908.GB22420@boskop.local>
In-Reply-To: <20060326071908.GB22420@boskop.local>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

Juergen Schoenwaelder wrote:
> On Sat, Mar 25, 2006 at 12:05:12PM -0800, Andy Bierman wrote:
> 
> 
>>There are 3 choices (option 4: don't care, I already know about):
>>
>>1) I do not want the NETCONF notification work to continue
>>  and I will not attend the interim meeting.
>>
>>2) I want the NETCONF notification work to continue
>>  but I will not be able to attend the interim meeting.
>>
>>3) I want the NETCONF notification work to continue
>>  and I will be able to attend some or all of the 3 day interim meeting.
> 
> 
> I guess I am in 2), but I might change to 3) in case the meeting
> happens to be at a very convenient place (from my biased European
> perspective of course).

Me too (also in Europe).

--
Shane

p.s. http://en.wikipedia.org/wiki/Me_too

--
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 Mar 27 04:13:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNnmn-0002i8-1T
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 04:13:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNnmm-0003wg-OJ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 04:13:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNnhE-00049i-V9
	for netconf-data@psg.com; Mon, 27 Mar 2006 09:07:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 
	autolearn=ham version=3.1.1
Received: from [202.232.30.157] (helo=omgo.iij.ad.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ray@iijlab.net>)
	id 1FNnhD-00049V-1H
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 09:07:31 +0000
Received: OTM-MO id k2R97Scf013264; Mon, 27 Mar 2006 18:07:28 +0900 (JST)
Received: OTM-MIX0 id k2R97RWr016071; Mon, 27 Mar 2006 18:07:27 +0900 (JST)
Received: from localhost (h169n190.iij.ad.jp [192.168.190.169])
	by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k2R97MR1006355
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 18:07:27 +0900 (JST)
Date: Mon, 27 Mar 2006 18:07:17 +0900 (LMT)
Message-Id: <20060327.180717.109274331.ray@iijlab.net>
To: netconf@ops.ietf.org
Subject: Re: Interim attendance survey
From: "Ray S. Atarashi" <ray@iijlab.net>
In-Reply-To: <20060327.115800.60844819.ray@iijlab.net>
References: <4425A278.5000804@andybierman.com>
	<20060327.115800.60844819.ray@iijlab.net>
X-Mailer: Mew version 4.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

I mean, "Tokyo downtown area", Japan. 
The INTEROP Tokyo is held in June 5-9.

Ray

From: "Ray S. Atarashi" <ray@iijlab.net>
> Hi, 
> 
> I guess I (and some Japanese guy) can arrange the interim meeting
> in Japan. How do you think to be held the interim meeting in
> Japan? 
> 
> I want to attend the interim meeting, but I can't travel now. 
> If the interim meeing is held in Japan, I am in 3), if not, I am
> in 2).
> 
> Ray
> 
> 
> From: Andy Bierman <ietf@andybierman.com>
> > Hi,
> > 
> > 
> > I want to do a survey to measure interest in the
> > NETCONF Notification work.  Very few people read
> > the draft before the meeting, let alone reviewed it,
> > despite numerous pleas. 
> > 
> > There are 3 choices (option 4: don't care, I already know about):
> > 
> > 1) I do not want the NETCONF notification work to continue
> >    and I will not attend the interim meeting.
> > 
> > 2) I want the NETCONF notification work to continue
> >    but I will not be able to attend the interim meeting.
> > 
> > 3) I want the NETCONF notification work to continue
> >    and I will be able to attend some or all of the 3 day interim meeting.
> > 
> > 
> > Possible location: Outside North America;
> >                    (hopefully w/ non-stop flights from all over)
> >                    (3 IETFs in a row in NA already)
> > 
> > Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> > 
> > 
> > Please send comments to the list.
> > 
> > 
> > thanks,
> > Andy
> > 
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


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



From owner-netconf@ops.ietf.org Mon Mar 27 04:49:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNoMB-0006nD-Sa
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 04:49:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNoMB-0005YO-GY
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 04:49:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNoH7-0005tK-L5
	for netconf-data@psg.com; Mon, 27 Mar 2006 09:44:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 
	autolearn=ham version=3.1.1
Received: from [202.232.30.157] (helo=omgo.iij.ad.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ray@iijlab.net>)
	id 1FNoH6-0005sx-Jj
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 09:44:36 +0000
Received: OTM-MO id k2R9iZQn016754; Mon, 27 Mar 2006 18:44:35 +0900 (JST)
Received: OTM-MIX0 id k2R9iY7s000276; Mon, 27 Mar 2006 18:44:35 +0900 (JST)
Received: from localhost (h169n190.iij.ad.jp [192.168.190.169])
	by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k2R9iOot009093
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 18:44:34 +0900 (JST)
Date: Mon, 27 Mar 2006 18:44:30 +0900 (LMT)
Message-Id: <20060327.184430.22808677.ray@iijlab.net>
To: netconf@ops.ietf.org
Subject: Re: Interim attendance survey
From: "Ray S. Atarashi" <ray@iijlab.net>
In-Reply-To: <20060327.180717.109274331.ray@iijlab.net>
References: <4425A278.5000804@andybierman.com>
	<20060327.115800.60844819.ray@iijlab.net>
	<20060327.180717.109274331.ray@iijlab.net>
X-Mailer: Mew version 4.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168

Sorry, It was sketchy explanation.

My suggestion is to hold the interim meeting in Tokyo downtown
area around June 12-14. The schedule is flexible.

If you're interested, you can tour INTEROP Tokyo, held in near
Tokyo, in June 5-9. 

Ray
				
From: "Ray S. Atarashi" <ray@iijlab.net>
> I mean, "Tokyo downtown area", Japan. 
> The INTEROP Tokyo is held in June 5-9.
> 
> Ray
> 
> From: "Ray S. Atarashi" <ray@iijlab.net>
> > Hi, 
> > 
> > I guess I (and some Japanese guy) can arrange the interim meeting
> > in Japan. How do you think to be held the interim meeting in
> > Japan? 
> > 
> > I want to attend the interim meeting, but I can't travel now. 
> > If the interim meeing is held in Japan, I am in 3), if not, I am
> > in 2).
> > 
> > Ray
> > 
> > 
> > From: Andy Bierman <ietf@andybierman.com>
> > > Hi,
> > > 
> > > 
> > > I want to do a survey to measure interest in the
> > > NETCONF Notification work.  Very few people read
> > > the draft before the meeting, let alone reviewed it,
> > > despite numerous pleas. 
> > > 
> > > There are 3 choices (option 4: don't care, I already know about):
> > > 
> > > 1) I do not want the NETCONF notification work to continue
> > >    and I will not attend the interim meeting.
> > > 
> > > 2) I want the NETCONF notification work to continue
> > >    but I will not be able to attend the interim meeting.
> > > 
> > > 3) I want the NETCONF notification work to continue
> > >    and I will be able to attend some or all of the 3 day interim meeting.
> > > 
> > > 
> > > Possible location: Outside North America;
> > >                    (hopefully w/ non-stop flights from all over)
> > >                    (3 IETFs in a row in NA already)
> > > 
> > > Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> > > 
> > > 
> > > Please send comments to the list.
> > > 
> > > 
> > > thanks,
> > > Andy
> > > 
> > > 
> > > 
> > > 
> > > --
> > > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://ops.ietf.org/lists/netconf/>
> > > 
> > 
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


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



From owner-netconf@ops.ietf.org Mon Mar 27 05:46:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNpF2-0004pC-KZ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 05:46:32 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNpEy-0008GR-Uc
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 05:46:32 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNpAp-000Ash-Px
	for netconf-data@psg.com; Mon, 27 Mar 2006 10:42:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FNpAn-000AsA-Lr
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 10:42:09 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7C32EC15
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 12:42:08 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 27 Mar 2006 12:42:07 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 27 Mar 2006 12:42:07 +0200
Message-ID: <4427B36D.9000908@ericsson.com>
Date: Mon, 27 Mar 2006 11:42:05 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <4425A278.5000804@andybierman.com>
In-Reply-To: <4425A278.5000804@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Mar 2006 10:42:07.0853 (UTC) FILETIME=[1869D1D0:01C6518B]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

I need the notification stuff so I am in class 2 or 3 depending on venue budget etc. I 
also prefer Europe.
Balazs        Ericsson Hungary Ltd.

Andy Bierman wrote:
> Hi,
> 
> 
> I want to do a survey to measure interest in the
> NETCONF Notification work.  Very few people read
> the draft before the meeting, let alone reviewed it,
> despite numerous pleas.
> There are 3 choices (option 4: don't care, I already know about):
> 
> 1) I do not want the NETCONF notification work to continue
>   and I will not attend the interim meeting.
> 
> 2) I want the NETCONF notification work to continue
>   but I will not be able to attend the interim meeting.
> 
> 3) I want the NETCONF notification work to continue
>   and I will be able to attend some or all of the 3 day interim meeting.
> 
> 
> Possible location: Outside North America;
>                   (hopefully w/ non-stop flights from all over)
>                   (3 IETFs in a row in NA already)
> 
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> 
> 
> Please send comments to the list.
> 
> 
> thanks,
> Andy
> 
> 
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Mar 27 06:26:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNprO-0000I8-EQ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 06:26:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNprL-0001J4-VF
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 06:26:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNplk-000EIb-PQ
	for netconf-data@psg.com; Mon, 27 Mar 2006 11:20:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FNplj-000EI0-OO
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 11:20:19 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2RBJFLp020913
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 06:19:15 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2RB4AYj025449
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 06:04:11 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: Interim attendance survey
Date: Mon, 27 Mar 2006 13:20:16 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3957@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZRD/RdZzzgjrAWT863XAz2cG9qsQAfQj7A
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba

Andy,

As I said I am not opposed to an interim meeting. In fact I am in favor
anything that can help us make progress.=20

I would however not tightly couple holding an interim with the success
of the NETCONF notifications work, or completion of the charter and
present the interim as a 'last chance' opportunity.=20

For somebody looking from the outside the NETCONF WG may seem actually
in rather good shape.  All due milestones are completed, we have an
initial submission for the only remaining charter item - notifications
and we have still six months ahead until we need to submit a
notifications document at the required level of consensus for WGLC. This
is good in IETF terms nowadays. I am aware that this good shape is
apparent, and there is little agreement on the problem space, and too
little review of the draft that includes a proposed solution even to
determine the level of agreement. I would encourage the WG to focus on
discussing the problem space (why are we doing notifications?) and the
draft and other options for solutions more intensively on the list. Let
us see in the next couple of weeks if we can reach more convergence on
the 'why' and 'how' questions.=20

If we do have contributions about the scope and reviews of the draft and
solutions on the list we have a chance to better converge and reach
agreement. If the level of apathy stays the same, I am not sure that a
partially attended interim meeting would help.=20

Regards,

Dan


=20
=20

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20
> Sent: Sunday, March 26, 2006 10:01 PM
> To: Romascanu, Dan (Dan)
> Cc: Netconf (E-mail)
> Subject: Re: Interim attendance survey
>=20
> Romascanu, Dan (Dan) wrote:
> > As a contributor I would like the NETCONF notification work to=20
> > continue and be completed in time.
> >=20
> > As AD and WG Area Advisor I would like to attend the=20
> meeting. However=20
> > my schedule is completely booked all May and the first days=20
> of June,=20
> > until 6/5. Yet, my participation is not of condition for=20
> the meeting=20
> > happening.
> >=20
> > I prefer European venues to North-American ones.=20
>=20
> Me too. But it's actually a policy (AFAIK) that interim=20
> meetings take into consideration recent (and next) IETF=20
> locations and try to be fair.  I also think we need to be=20
> practical, so I think London would be a good location.  It=20
> might be easier with a local host to setup the logistics=20
> (Simon and I are not located near London).
>=20
> I'm not actually convinced yet this work matters enough to=20
> the WG to be continued.  IMO, this is a "nice-to-have"=20
> feature not a "must-have" (like a replacement for screen=20
> scraping CLI w/Expect).
>=20
> For many WG members, a replacement for syslog is a=20
> "don't-need" feature.
> Combine "don't-need" with "nice-to-have" and the outcome isn't very
> surprising:
>=20
>     -- very few people reviewed the draft
>     -- very little agreement on the problem space
>     -- no agreement on the solution
>=20
> An interim meeting would be a last-ditch attempt to get=20
> consensus started somewhere, before giving up.
>=20
>=20
> >=20
> > Dan
>=20
> Andy
>=20
> >=20
> >=20
> >=20
> >=20
> > =20
> > =20
> >=20
> >> -----Original Message-----
> >> From: owner-netconf@ops.ietf.org
> >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> >> Sent: Saturday, March 25, 2006 10:05 PM
> >> To: Netconf (E-mail)
> >> Subject: Interim attendance survey
> >>
> >> Hi,
> >>
> >>
> >> I want to do a survey to measure interest in the NETCONF=20
> Notification=20
> >> work.  Very few people read the draft before the meeting,=20
> let alone=20
> >> reviewed it, despite numerous pleas.
> >>
> >> There are 3 choices (option 4: don't care, I already know about):
> >>
> >> 1) I do not want the NETCONF notification work to continue
> >>    and I will not attend the interim meeting.
> >>
> >> 2) I want the NETCONF notification work to continue
> >>    but I will not be able to attend the interim meeting.
> >>
> >> 3) I want the NETCONF notification work to continue
> >>    and I will be able to attend some or all of the 3 day interim=20
> >> meeting.
> >>
> >>
> >> Possible location: Outside North America;
> >>                    (hopefully w/ non-stop flights from all over)
> >>                    (3 IETFs in a row in NA already)
> >>
> >> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> >>
> >>
> >> Please send comments to the list.
> >>
> >>
> >> thanks,
> >> Andy
> >>
> >>
> >>
> >>
> >> --
> >> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://ops.ietf.org/lists/netconf/>
> >>
> >=20
> > --
> > to unsubscribe send a message to=20
> netconf-request@ops.ietf.org with the=20
> > word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> >=20
> >=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 Mon Mar 27 07:19:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNqgz-0003EF-Ra
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 07:19:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNqgy-00048J-IH
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 07:19:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNqbo-000IIw-KP
	for netconf-data@psg.com; Mon, 27 Mar 2006 12:14:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FNqbn-000IIS-BX
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 12:14:07 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5051A1A6
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 14:14:06 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 27 Mar 2006 14:14:05 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 27 Mar 2006 14:14:05 +0200
Message-ID: <4427D70D.5030408@ericsson.com>
Date: Mon, 27 Mar 2006 14:14:05 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <C049745D.10555%sberl@cisco.com> <44243846.7020504@andybierman.com>
In-Reply-To: <44243846.7020504@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Mar 2006 12:14:05.0446 (UTC) FILETIME=[F127B260:01C65197]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

If we want to use notifications to send multiple results for an <rpc> is this considered a 
<config-change-event> or not a compelling need or ?
Balazs

Andy Bierman wrote:
> So far I see a compelling need for 2 standard notification types:
> 
> <syslog-event> and <config-change-event>
> Andy

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



From owner-netconf@ops.ietf.org Mon Mar 27 09:12:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNsSX-0001rD-Fv
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 09:12:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNsSS-0008Bs-TN
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 09:12:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNsNv-000Pdu-EO
	for netconf-data@psg.com; Mon, 27 Mar 2006 14:07:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.1
Received: from [203.178.142.162] (helo=pc1.alaxala.net)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <atarashi@alaxala.net>)
	id 1FNp6t-000AUC-KD
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 10:38:08 +0000
Received: from localhost (localhost [127.0.0.1])
	by pc1.alaxala.net (Postfix) with ESMTP id 2C423BB21;
	Mon, 27 Mar 2006 19:38:06 +0900 (JST)
Received: from pc1.alaxala.net ([127.0.0.1])
 by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 42252-09; Mon, 27 Mar 2006 19:38:00 +0900 (JST)
Received: from [192.168.0.2] (2.30.30.125.dy.iij4u.or.jp [125.30.30.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by pc1.alaxala.net (Postfix) with ESMTP id BACB2B90D;
	Mon, 27 Mar 2006 19:38:00 +0900 (JST)
Message-ID: <4427C07F.8090000@alaxala.net>
Date: Mon, 27 Mar 2006 19:37:51 +0900
From: Yoshifumi Atarashi <atarashi@alaxala.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To:  netconf@ops.ietf.org
CC: "Ray S. Atarashi" <ray@iijlab.net>, 
 Yoshifumi Atarashi <atarashi@alaxala.net>
Subject: Re: Interim attendance survey
References: <4425A278.5000804@andybierman.com>     <20060327.115800.60844819.ray@iijlab.net>     <20060327.180717.109274331.ray@iijlab.net> <20060327.184430.22808677.ray@iijlab.net>
In-Reply-To: <20060327.184430.22808677.ray@iijlab.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at alaxala.net
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027

> My suggestion is to hold the interim meeting in Tokyo downtown
> area around June 12-14. The schedule is flexible.
>
> If you're interested, you can tour INTEROP Tokyo, held in near
> Tokyo, in June 5-9. 

Interop Tokyo is biggest IT exhibition in Japan.
You can see Japnese broadband enviroment.
Probably it isn't rainy season in June 5-14.
Rainy season starting is about June 20.
You'll be able to site seeing weekend.
# http://www.h5.dion.ne.jp/~donkey/sub3.html    and so on.

we can reserve internet connected meeting room.
And we found coffee and snack sponcer. :-)
-------
  Yoshifumi Atarashi
  ALAXALA Networks, Corp.

			
> From: "Ray S. Atarashi" <ray@iijlab.net>
> 
>>I mean, "Tokyo downtown area", Japan. 
>>The INTEROP Tokyo is held in June 5-9.
>>
>>Ray
>>
>>From: "Ray S. Atarashi" <ray@iijlab.net>
>>
>>>Hi, 
>>>
>>>I guess I (and some Japanese guy) can arrange the interim meeting
>>>in Japan. How do you think to be held the interim meeting in
>>>Japan? 
>>>
>>>I want to attend the interim meeting, but I can't travel now. 
>>>If the interim meeing is held in Japan, I am in 3), if not, I am
>>>in 2).
>>>
>>>Ray
>>>
>>>
>>>From: Andy Bierman <ietf@andybierman.com>
>>>
>>>>Hi,
>>>>
>>>>
>>>>I want to do a survey to measure interest in the
>>>>NETCONF Notification work.  Very few people read
>>>>the draft before the meeting, let alone reviewed it,
>>>>despite numerous pleas. 
>>>>
>>>>There are 3 choices (option 4: don't care, I already know about):
>>>>
>>>>1) I do not want the NETCONF notification work to continue
>>>>   and I will not attend the interim meeting.
>>>>
>>>>2) I want the NETCONF notification work to continue
>>>>   but I will not be able to attend the interim meeting.
>>>>
>>>>3) I want the NETCONF notification work to continue
>>>>   and I will be able to attend some or all of the 3 day interim meeting.
>>>>
>>>>
>>>>Possible location: Outside North America;
>>>>                   (hopefully w/ non-stop flights from all over)
>>>>                   (3 IETFs in a row in NA already)
>>>>
>>>>Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>>>>
>>>>
>>>>Please send comments to the list.
>>>>
>>>>
>>>>thanks,
>>>>Andy
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>to unsubscribe send a message to netconf-request@ops.ietf.org with
>>>>the word 'unsubscribe' in a single line as the message text body.
>>>>archive: <http://ops.ietf.org/lists/netconf/>
>>>>
>>>
>>>--
>>>to unsubscribe send a message to netconf-request@ops.ietf.org with
>>>the word 'unsubscribe' in a single line as the message text body.
>>>archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>
>>--
>>to unsubscribe send a message to netconf-request@ops.ietf.org with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/netconf/>
>>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 




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



From owner-netconf@ops.ietf.org Mon Mar 27 09:12:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNsSa-0001rP-Gm
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 09:12:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNsSa-0008CD-1V
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 09:12:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNsLk-000PWo-B5
	for netconf-data@psg.com; Mon, 27 Mar 2006 14:05:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,
	DATE_IN_PAST_12_24,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [62.241.163.7] (helo=blaster.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1FNsLj-000PVf-76
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 14:05:39 +0000
Received: from pc6 (1Cust158.tnt2.lnd4.gbr.da.uu.net [62.188.131.158])
	by blaster.systems.pipex.net (Postfix) with SMTP id 45C63E000327;
	Mon, 27 Mar 2006 15:05:29 +0100 (BST)
Message-ID: <00db01c6519e$dc0c15e0$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <4425A278.5000804@andybierman.com>
Subject: Re: Interim attendance survey
Date: Sun, 26 Mar 2006 21:34:04 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

2) but could become a 3) if the meeting was somewhere convenient like London,
UK.

I think it matters but not as much as getting the current XML straight, which
seems to be taking an inordinate amount of effort, after which I would give
higher priority to the data model.

Tom Petch


----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Saturday, March 25, 2006 10:05 PM
Subject: Interim attendance survey


> Hi,
>
>
> I want to do a survey to measure interest in the
> NETCONF Notification work.  Very few people read
> the draft before the meeting, let alone reviewed it,
> despite numerous pleas.
>
> There are 3 choices (option 4: don't care, I already know about):
>
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.
>
> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.
>
> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day interim meeting.
>
>
> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)
>
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>
>
> Please send comments to the list.
>
>
> thanks,
> Andy
>
>
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Mar 27 10:13:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNtPH-00088K-7t
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:13:23 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNtPF-0002J7-V9
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:13:23 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNtKR-0003y0-Kq
	for netconf-data@psg.com; Mon, 27 Mar 2006 15:08:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNtKQ-0003xp-PB
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 15:08:23 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2RF8LZj010142
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 10:08:21 -0500
Received: (qmail 4872 invoked by uid 78); 27 Mar 2006 15:08:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 27 Mar 2006 15:08:21 -0000
Message-ID: <4428001D.2090501@andybierman.com>
Date: Mon, 27 Mar 2006 07:09:17 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Message Processing Model
References: <C049745D.10555%sberl@cisco.com> <44243846.7020504@andybierman.com> <4427D70D.5030408@ericsson.com>
In-Reply-To: <4427D70D.5030408@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

Balazs Lengyel wrote:
> If we want to use notifications to send multiple results for an <rpc> is 
> this considered a <config-change-event> or not a compelling need or ?


Sounds like an experiment with a new RPC model.
The IRTF does research, not the IETF.


> Balazs

Andy

> 
> Andy Bierman wrote:
>> So far I see a compelling need for 2 standard notification types:
>>
>> <syslog-event> and <config-change-event>
>> Andy
> 

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



From owner-netconf@ops.ietf.org Mon Mar 27 10:35:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNtkD-0005I5-VB
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:35:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNtkD-0003fG-Fq
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:35:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNtb9-0005LL-HZ
	for netconf-data@psg.com; Mon, 27 Mar 2006 15:25:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNtb8-0005Ky-7i
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 15:25:38 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RFPakQ011810
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 10:25:36 -0500
Received: (qmail 17004 invoked by uid 78); 27 Mar 2006 15:25:36 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 27 Mar 2006 15:25:36 -0000
Message-ID: <44280429.5070805@andybierman.com>
Date: Mon, 27 Mar 2006 07:26:33 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3957@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3957@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e

Romascanu, Dan (Dan) wrote:
> Andy,
> 
> As I said I am not opposed to an interim meeting. In fact I am in favor
> anything that can help us make progress. 
> 
> I would however not tightly couple holding an interim with the success
> of the NETCONF notifications work, or completion of the charter and
> present the interim as a 'last chance' opportunity.


I wasn't -- directly.
However, without an interim I think we will
be in this exact situation in Montreal.

If we have a normal interim, it will be in London in May.

There is also the possibility that the IESG will approve
my request for "Interim Friday", in which case we could
have a 3 day interim (Friday - Sunday) at the Montreal IETF instead.
IMO this is the best choice because it minimizes travel costs.



> 
> For somebody looking from the outside the NETCONF WG may seem actually
> in rather good shape.  All due milestones are completed, we have an
> initial submission for the only remaining charter item - notifications
> and we have still six months ahead until we need to submit a
> notifications document at the required level of consensus for WGLC. This
> is good in IETF terms nowadays. I am aware that this good shape is
> apparent, and there is little agreement on the problem space, and too
> little review of the draft that includes a proposed solution even to
> determine the level of agreement. I would encourage the WG to focus on
> discussing the problem space (why are we doing notifications?) and the
> draft and other options for solutions more intensively on the list. Let
> us see in the next couple of weeks if we can reach more convergence on
> the 'why' and 'how' questions. 


We clearly do not agree on the requirements.

> 
> If we do have contributions about the scope and reviews of the draft and
> solutions on the list we have a chance to better converge and reach
> agreement. If the level of apathy stays the same, I am not sure that a
> partially attended interim meeting would help. 

Maybe it would help to consider other proposals.
Maybe the WG needs to spend a couple years on a
NETCONF Notification Requirements RFC first.

I hate those RFCs, but in this case there is such a
wide array of undocumented and implied requirements in
the draft (and the WG), I don't think consensus will
ever be reached by attempting to "refine" it.



> 
> Regards,
> 
> Dan


Andy

> 
> 
>  
>  
> 
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com] 
>> Sent: Sunday, March 26, 2006 10:01 PM
>> To: Romascanu, Dan (Dan)
>> Cc: Netconf (E-mail)
>> Subject: Re: Interim attendance survey
>>
>> Romascanu, Dan (Dan) wrote:
>>> As a contributor I would like the NETCONF notification work to 
>>> continue and be completed in time.
>>>
>>> As AD and WG Area Advisor I would like to attend the 
>> meeting. However 
>>> my schedule is completely booked all May and the first days 
>> of June, 
>>> until 6/5. Yet, my participation is not of condition for 
>> the meeting 
>>> happening.
>>>
>>> I prefer European venues to North-American ones. 
>> Me too. But it's actually a policy (AFAIK) that interim 
>> meetings take into consideration recent (and next) IETF 
>> locations and try to be fair.  I also think we need to be 
>> practical, so I think London would be a good location.  It 
>> might be easier with a local host to setup the logistics 
>> (Simon and I are not located near London).
>>
>> I'm not actually convinced yet this work matters enough to 
>> the WG to be continued.  IMO, this is a "nice-to-have" 
>> feature not a "must-have" (like a replacement for screen 
>> scraping CLI w/Expect).
>>
>> For many WG members, a replacement for syslog is a 
>> "don't-need" feature.
>> Combine "don't-need" with "nice-to-have" and the outcome isn't very
>> surprising:
>>
>>     -- very few people reviewed the draft
>>     -- very little agreement on the problem space
>>     -- no agreement on the solution
>>
>> An interim meeting would be a last-ditch attempt to get 
>> consensus started somewhere, before giving up.
>>
>>
>>> Dan
>> Andy
>>
>>>
>>>
>>>
>>>  
>>>  
>>>
>>>> -----Original Message-----
>>>> From: owner-netconf@ops.ietf.org
>>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>>>> Sent: Saturday, March 25, 2006 10:05 PM
>>>> To: Netconf (E-mail)
>>>> Subject: Interim attendance survey
>>>>
>>>> Hi,
>>>>
>>>>
>>>> I want to do a survey to measure interest in the NETCONF 
>> Notification 
>>>> work.  Very few people read the draft before the meeting, 
>> let alone 
>>>> reviewed it, despite numerous pleas.
>>>>
>>>> There are 3 choices (option 4: don't care, I already know about):
>>>>
>>>> 1) I do not want the NETCONF notification work to continue
>>>>    and I will not attend the interim meeting.
>>>>
>>>> 2) I want the NETCONF notification work to continue
>>>>    but I will not be able to attend the interim meeting.
>>>>
>>>> 3) I want the NETCONF notification work to continue
>>>>    and I will be able to attend some or all of the 3 day interim 
>>>> meeting.
>>>>
>>>>
>>>> Possible location: Outside North America;
>>>>                    (hopefully w/ non-stop flights from all over)
>>>>                    (3 IETFs in a row in NA already)
>>>>
>>>> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>>>>
>>>>
>>>> Please send comments to the list.
>>>>
>>>>
>>>> thanks,
>>>> Andy
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with 
>>>> the word 'unsubscribe' in a single line as the message text body.
>>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>>
>>> --
>>> to unsubscribe send a message to 
>> netconf-request@ops.ietf.org with the 
>>> word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Mon Mar 27 10:54:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNu3B-0007J6-GS
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:54:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNu3A-0004Hj-73
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 10:54:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNtwS-0006t1-5q
	for netconf-data@psg.com; Mon, 27 Mar 2006 15:47:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNtwR-0006s9-CA
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 15:47:39 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RFlcvW015790
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 10:47:38 -0500
Received: (qmail 8188 invoked by uid 78); 27 Mar 2006 15:47:37 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 27 Mar 2006 15:47:37 -0000
Message-ID: <44280952.40002@andybierman.com>
Date: Mon, 27 Mar 2006 07:48:34 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Real Notification Requirements
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Hi,

This new thread is for people to articulate use cases
to support functional requirement requests. 

Translation: What is the developer or operator doing now, and
how will it change to something great and wonderful because
of this new feature?

Let's try some top-down design, since ad-hoc design isn't
going so well.

I believe there is consensus so far for 2 uses of notifications
in the NETCONF protocol:


Content Layer Requirements
--------------------------

C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content

C2) NETCONF configuration change notification

C3) ???


Andy






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



From owner-netconf@ops.ietf.org Mon Mar 27 11:02:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNuAv-0004CI-UR
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:02:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNuAu-0004V7-LG
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:02:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNu6r-0007ZK-38
	for netconf-data@psg.com; Mon, 27 Mar 2006 15:58:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNu6q-0007Z5-AB
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 15:58:24 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RFwMts006370
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 10:58:23 -0500
Received: (qmail 9068 invoked by uid 78); 27 Mar 2006 15:58:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 27 Mar 2006 15:58:22 -0000
Message-ID: <44280BD5.1090601@andybierman.com>
Date: Mon, 27 Mar 2006 07:59:17 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Named Profiles for notification configuration
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hi,

IMO, the entire concept of the 'named-profile' configuration
option in the draft is broken.  From a standards POV, it is
broken because there is no way for 1 vendor to set a profile
and another to use it.  The content is unspecified.

More importantly, this is "just another data model".
We already have an architecture for defining, naming, and
manipulating data with standard RPC methods (e.g., <edit-config>).
IMO, adding a new 'opaque' label-based configuration model on
top of that is a bad idea.

As Wes would say, "Have you fully considered the access control
implications of this design?"  I don't think so.



Andy



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



From owner-netconf@ops.ietf.org Mon Mar 27 11:31:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNud4-00020R-S3
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:31:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNud4-0005qn-3V
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:31:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNuZ4-0009d9-Uu
	for netconf-data@psg.com; Mon, 27 Mar 2006 16:27:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNuZ3-0009ct-Tg
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 16:27:34 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2RGRTT24883
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 11:27:30 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: (unofficial issue 2) Subscription versus never-ending command
Date: Mon, 27 Mar 2006 11:27:25 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: (unofficial issue 2) Subscription versus never-ending command
Thread-Index: AcZRu1T/NQDxYx+nTWadj8YSWy8oJg==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

hi

I said in the wg meeting that I would start capturing some of the pros
and cons of the subscription method versus the never-ending command
design alternative that some have suggested. This will hopefully allow
us to evaluate them less subjectively. This list is from the meeting,
the mailing list and some off-line discussions we had in Dallas.

1. Subscription

Similar to what is done in Oasis Notifications and SIP, the user
specifies which notifications are of interest and receives a reply
indicating whether or not the subscription command was successful. Then
subscriptions are sent asynchronously across the connection. The user
can modify the subscription, cancel it or start additional
subscriptions. They are also free to execute other synchronous commands
if it makes operational sense to do so on the same connection.

Pros:

- Allows you to modify the subscription without losing any notifications
- Allows you to have more then one subscription at a given time
(including short-lived ones)
- All the information to be easily processed as soon as it arrives since
each notification is a complete document
- Future proofing - easily supports event replay subscriptions
- Conserves connections
- Easily supports operator/manager use cases
- Supporting multiple subscriptions mirrors some popular CLIs


Cons:=20

- Notifications could be blocked by poorly chosen asynchronous commands
- Implementations need to perform more tasks on a single connection,
instead of separating them out into separate ones.

2. Never-ending command. A user sends a command which specifies which
notifications are of interest and waits for a reply. Reply will come in
the form of notifications at some point in the future. User is unable to
directly modify the subscription, cancel the command or execute other
commands.

Pros:=20

- Simple for the server to implement (see below)
- On a single connection, the server only has to either send
notifications or listen for commands
- There is also less functionality to provide
- Only blocked by other notifications (not by other commands)

Cons:

- Eats up more connections
- harder for the client to use (See below)
- Can't be modified ( modifying subscription without losing
notifications requires creating a new connection, creating a new
notification command, start receiving notifications, remove duplicates
then kill the old command)
- Can't be processed by document oriented XML parsers
- Unclear how you would cancel the subscription
- Unclear how to tell if the command was not successful

Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

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



From owner-netconf@ops.ietf.org Mon Mar 27 11:35:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNugn-0002g6-UW
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:35:33 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNugn-00063x-L9
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 11:35:33 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNudQ-0009x5-LS
	for netconf-data@psg.com; Mon, 27 Mar 2006 16:32:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNudP-0009wu-QI
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 16:32:04 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2RGW0H29821
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 11:32:01 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Named Profiles for notification configuration (unofficial issue #16)
Date: Mon, 27 Mar 2006 11:31:59 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407926D61@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Named Profiles for notification configuration (unofficial issue #16)
Thread-Index: AcZRt/2GIuT4+JyeSfC4WU3Nv3DyiwAA2dnw
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

hi

Access control is something the working group should definitely get to,
but I'm not sure how it specifically applies to this issue.

The named profile is intended to be a standard way for people to hook in
proprietary filtering. It is not intended to specified in an
interoperable way, other than how you hook the name in. The more
standardized approach is what the Xpath and subtree (defined
consistently with other Netconf commands) is intended for.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Monday, March 27, 2006 10:59 AM
To: Netconf (E-mail)
Subject: Named Profiles for notification configuration


Hi,

IMO, the entire concept of the 'named-profile' configuration option in
the draft is broken.  From a standards POV, it is broken because there
is no way for 1 vendor to set a profile and another to use it.  The
content is unspecified.

More importantly, this is "just another data model".
We already have an architecture for defining, naming, and manipulating
data with standard RPC methods (e.g., <edit-config>). IMO, adding a new
'opaque' label-based configuration model on top of that is a bad idea.

As Wes would say, "Have you fully considered the access control
implications of this design?"  I don't think so.



Andy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Mar 27 12:31:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNvZD-0002SV-VV
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 12:31:47 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNvZD-0000LQ-LB
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 12:31:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNvUo-000EBm-B9
	for netconf-data@psg.com; Mon, 27 Mar 2006 17:27:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNvUn-000EBY-Ke
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 17:27:13 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RHRCDT014321
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 12:27:12 -0500
Received: (qmail 23741 invoked by uid 78); 27 Mar 2006 17:27:11 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 27 Mar 2006 17:27:11 -0000
Message-ID: <44282067.8070203@andybierman.com>
Date: Mon, 27 Mar 2006 09:27:03 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Named Profiles for notification configuration (unofficial issue
 #16)
References: <713043CE8B8E1348AF3C546DBE02C1B407926D61@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407926D61@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

Sharon Chisholm wrote:
> hi
> 
> Access control is something the working group should definitely get to,
> but I'm not sure how it specifically applies to this issue.
> 
> The named profile is intended to be a standard way for people to hook in
> proprietary filtering. 


Not sure how access control applies to opaque parameters? Yikes!


There aren't going to be any blatant proprietary hooks in NETCONF.
This needs to be fully specified or removed.  Independent
implementations must be able to interoperate based on this
specification.  An opaque "named profile" that just somehow magically
appears on the device is not inter-operable or secure.



It is not intended to specified in an
> interoperable way, other than how you hook the name in. The more
> standardized approach is what the Xpath and subtree (defined
> consistently with other Netconf commands) is intended for.
> 
> Sharon

Andy

> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Monday, March 27, 2006 10:59 AM
> To: Netconf (E-mail)
> Subject: Named Profiles for notification configuration
> 
> 
> Hi,
> 
> IMO, the entire concept of the 'named-profile' configuration option in
> the draft is broken.  From a standards POV, it is broken because there
> is no way for 1 vendor to set a profile and another to use it.  The
> content is unspecified.
> 
> More importantly, this is "just another data model".
> We already have an architecture for defining, naming, and manipulating
> data with standard RPC methods (e.g., <edit-config>). IMO, adding a new
> 'opaque' label-based configuration model on top of that is a bad idea.
> 
> As Wes would say, "Have you fully considered the access control
> implications of this design?"  I don't think so.
> 
> 
> 
> Andy
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Mon Mar 27 13:34:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNwYG-0002eT-Pg
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 13:34:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNwYG-000376-GZ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 13:34:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNwSW-000Im6-Ti
	for netconf-data@psg.com; Mon, 27 Mar 2006 18:28:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNwSU-000IlX-2f
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 18:28:54 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2RIOOQ26137
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 13:24:24 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Named Profiles for notification configuration (unofficial issue #16)
Date: Mon, 27 Mar 2006 13:28:47 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407926F10@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Named Profiles for notification configuration (unofficial issue #16)
Thread-Index: AcZRx0mIqEhs3QeFT/WL0m+0xMcRVgAAFiUg
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

hi


<Andy>
Not sure how access control applies to opaque parameters? Yikes!
</Andy>

Compared to opaque data models? No, I don't see why this is more of an
issue. Not saying this is a good thing, but it is the way it is. The
implementer would apply their own access control to the no-longer-opaque
parameters and determine if the user should have access.


<Andy>
There aren't going to be any blatant proprietary hooks in NETCONF.=20
</Andy>
That's quite the statement. My crystal ball doesn't work that well ...

If there is working group consensus that we don't need extensibility in
the filtering, then I'm (as an individual) fine with it being removed
(as an editor).

In general though, as far as trying to support implementations, there
will be two options

1) Explicitly preclude proprietary extensions
2) Provide a standard way (such as URLs) to enable 'predictable'
proprietary extensions.

Note that the first case really comes in two parts. The first is where
to ensure interoperability we want to limit extensions to limit the
number of ways to say the same thing. The second is that we ensure we
have defined things rich enough to cover everything that will reasonably
come up.

This more relates to other topics of extensibility that came up (such as
event classes) than this issue, but this discussion reminded me of the
extensibility discussion ...

Sharon


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



From owner-netconf@ops.ietf.org Mon Mar 27 13:50:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNwnn-0000sN-D1
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 13:50:55 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNwnn-0003TG-31
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 13:50:55 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNwjP-000K3r-4A
	for netconf-data@psg.com; Mon, 27 Mar 2006 18:46:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNwjO-000K3f-Cm
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 18:46:22 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RIkKvW000750
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 13:46:20 -0500
Received: (qmail 3130 invoked by uid 78); 27 Mar 2006 18:46:20 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 27 Mar 2006 18:46:20 -0000
Message-ID: <442832F1.8040300@andybierman.com>
Date: Mon, 27 Mar 2006 10:46:09 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Named Profiles for notification configuration (unofficial issue
 #16)
References: <713043CE8B8E1348AF3C546DBE02C1B407926F10@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407926F10@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Sharon Chisholm wrote:
> hi
> 
> 
> <Andy>
> Not sure how access control applies to opaque parameters? Yikes!
> </Andy>
> 
> Compared to opaque data models? No, I don't see why this is more of an
> issue. Not saying this is a good thing, but it is the way it is. The
> implementer would apply their own access control to the no-longer-opaque
> parameters and determine if the user should have access.

We don't have opaque string data models.
We have vendors defining explicit XML data models
in their own namespace.  There is a difference.

> 
> 
> <Andy>
> There aren't going to be any blatant proprietary hooks in NETCONF. 
> </Andy>
> That's quite the statement. My crystal ball doesn't work that well ...


Well, I'm the co-Chair, and mine does.
Fully-specified, interoperable mechanisms are required for
inclusion in any standard NETCONF namespace.  What you do outside
any such namespaces is not my concern.



> 
> If there is working group consensus that we don't need extensibility in
> the filtering, then I'm (as an individual) fine with it being removed
> (as an editor).
> 
> In general though, as far as trying to support implementations, there
> will be two options
> 
> 1) Explicitly preclude proprietary extensions
> 2) Provide a standard way (such as URLs) to enable 'predictable'
> proprietary extensions.


I have provided an extensibility mechanism -- IANA registration.
Each event-type is itself a data model with implementation
requirements in the agent.  They should be registered with IANA
and be independent of the document this WG is chartered to create.


> 
> Note that the first case really comes in two parts. The first is where
> to ensure interoperability we want to limit extensions to limit the
> number of ways to say the same thing. The second is that we ensure we
> have defined things rich enough to cover everything that will reasonably
> come up.
> 
> This more relates to other topics of extensibility that came up (such as
> event classes) than this issue, but this discussion reminded me of the
> extensibility discussion ...
> 
> Sharon

Andy

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



From owner-netconf@ops.ietf.org Mon Mar 27 14:09:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNx5v-00052c-9R
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 14:09:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNx5u-0004d2-04
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 14:09:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNx2I-000LN3-8w
	for netconf-data@psg.com; Mon, 27 Mar 2006 19:05:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNx2H-000LMn-DX
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 19:05:53 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2RJ5nH10233
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 14:05:49 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Named Profiles for notification configuration (unofficial issue #16)
Date: Mon, 27 Mar 2006 14:05:37 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407927000@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Named Profiles for notification configuration (unofficial issue #16)
Thread-Index: AcZRzsIDpyQdqtu4SD2onNxTvWZcQAAANF+g
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

hi

<Andy>

We don't have opaque string data models.
We have vendors defining explicit XML data models
in their own namespace.  There is a difference.
</Andy>

Ah. So, I guess we forgot to explicitly specify that it is necessary to
specify some data model for the named filters. That is why it is the
same issue. If they remain in the update, we shall add this
clarification.


<Andy>
I have provided an extensibility mechanism -- IANA registration.
Each event-type is itself a data model with implementation
requirements in the agent.  They should be registered with IANA
and be independent of the document this WG is chartered to create.
</Andy>

I'm confused. So, the proposal in the internet draft is that
notifications are defined in the data model, but are you proposing a
design alternative or suggesting that working group consensus has
already been reached and this is going to be done in another way?

Sharon

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



From owner-netconf@ops.ietf.org Mon Mar 27 14:30:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNxQ8-0007x9-VQ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 14:30:32 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNxQ8-0005hx-Hr
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 14:30:32 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNxK9-000MVr-8J
	for netconf-data@psg.com; Mon, 27 Mar 2006 19:24:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FNxK8-000MVf-Jy
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 19:24:20 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged))
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2RJN3XF012344;
	Mon, 27 Mar 2006 11:23:03 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HRTBQ4BV>; Mon, 27 Mar 2006 11:23:04 -0800
Message-ID: <789E617C880666438EDEE30C2A3E8D10ED94@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Tom Petch'" <nwnetworks@dial.pipex.com>,
        Andy Bierman
	 <ietf@andybierman.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RE: Interim attendance survey [data model first]
Date: Mon, 27 Mar 2006 11:22:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793


Tom Petch wrote on 26 March at 2:34 PM:
> 
> 2) but could become a 3) if the meeting was somewhere 
> convenient like London,
> UK.
> 
> I think it matters but not as much as getting the current XML 
> straight, which
> seems to be taking an inordinate amount of effort, after 
> which I would give
> higher priority to the data model.
> 
> Tom Petch

I agree with David Perkins - notifications, subscriptions,
event aggregation, and event filtering are fascinating
topics.

However, I fail to see any compelling reason for NetConf
to reinvent the wheel once again and create yet another
notification protocol.

Standard data model is _far_ more important, IMHO.

I still maintain that "merge this blob with that blob" is
a wildly underspecified operation - so far, NetConf seems
to have provided the substrate for a number of entirely
vendor proprietary implementations that do not _by_design_
interoperate in any meaningful way - I'm astounded that
the IESG thought it was OK to invent yet another darned
configuration protocol with no standard data model(s).

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.2/294 - Release Date: 3/27/2006
 

--
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 Mar 27 15:25:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyHO-0002pN-VG
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:25:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNyHL-0007hb-Iw
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:25:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyCV-0000A4-JU
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:20:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNyCU-00009t-On
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 20:20:30 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RKKRts030990
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 15:20:29 -0500
Received: (qmail 27876 invoked by uid 78); 27 Mar 2006 19:20:26 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 27 Mar 2006 19:20:26 -0000
Message-ID: <44283AEE.40207@andybierman.com>
Date: Mon, 27 Mar 2006 11:20:14 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Named Profiles for notification configuration (unofficial issue
 #16)
References: <713043CE8B8E1348AF3C546DBE02C1B407927000@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407927000@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

Sharon Chisholm wrote:
> hi
> 
> <Andy>
> 
> We don't have opaque string data models.
> We have vendors defining explicit XML data models
> in their own namespace.  There is a difference.
> </Andy>
> 
> Ah. So, I guess we forgot to explicitly specify that it is necessary to
> specify some data model for the named filters. That is why it is the
> same issue. If they remain in the update, we shall add this
> clarification.

I'm not sure there is WG to have named profiles at all.
We have a mechanism -- data models configured through
standard NETCONF operations.  We don't need more, let alone
mixing them together.   How about if we see some
deployed implementations of this feature (for any profile-named
config data) in some NETCONF products before we standardize it?


> 
> 
> <Andy>
> I have provided an extensibility mechanism -- IANA registration.
> Each event-type is itself a data model with implementation
> requirements in the agent.  They should be registered with IANA
> and be independent of the document this WG is chartered to create.
> </Andy>
> 
> I'm confused. So, the proposal in the internet draft is that
> notifications are defined in the data model, but are you proposing a
> design alternative or suggesting that working group consensus has
> already been reached and this is going to be done in another way?


All event types and any mention of any specific event content
outside the <notification> element header contents should be
removed from the document and made independent of protocol.

People (outside the WG) would then be free to register as many
notification data models with IANA as they want.  Just like
the base protocol, there should be content-independent notifications.

The only exception is the configuration-change notification.
That should be defined in this document and be mandatory-to-implement
if you support the :notification capability.


> 
> Sharon

Andy


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



From owner-netconf@ops.ietf.org Mon Mar 27 15:25:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyHg-0002ts-AY
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:25:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNyHf-0007hs-T4
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:25:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyE7-0000IK-Gn
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:22:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNvQc-000Dsv-Ek
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 17:22:54 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RHMqDT008337
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 12:22:52 -0500
Received: (qmail 19744 invoked by uid 78); 27 Mar 2006 17:22:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 27 Mar 2006 17:22:52 -0000
Message-ID: <44281F63.60909@andybierman.com>
Date: Mon, 27 Mar 2006 09:22:43 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a

Sharon Chisholm wrote:
> hi


I like the publish/subscribe model, but that is not
what is in the draft.  IMO the classifications and content
of each notification should be defined independently
of this document.

This document should just define how a standard NETCONF agent
publishes a set of IANA-registered event-type URIs to indicate it can
meet all the requirements specified for generating those event types.

This document must also specify how a manager subscribes/unsubscribes
to receive an arbitrary subset of those event types.

(IMO that is all the filtering that is needed, but if
the WG really needs to make this more complicated, then fine.)

The only real difference in your list is:
  - the ability to change the event type subscription from
    the same session.
  - the ability to use the same session for operations and
    notifications.

The trade-off is massive complexity -- how massive the complexity
and how valuable these features are in return is quite debatable.

Andy

> 
> I said in the wg meeting that I would start capturing some of the pros
> and cons of the subscription method versus the never-ending command
> design alternative that some have suggested. This will hopefully allow
> us to evaluate them less subjectively. This list is from the meeting,
> the mailing list and some off-line discussions we had in Dallas.
> 
> 1. Subscription
> 
> Similar to what is done in Oasis Notifications and SIP, the user
> specifies which notifications are of interest and receives a reply
> indicating whether or not the subscription command was successful. Then
> subscriptions are sent asynchronously across the connection. The user
> can modify the subscription, cancel it or start additional
> subscriptions. They are also free to execute other synchronous commands
> if it makes operational sense to do so on the same connection.
> 
> Pros:
> 
> - Allows you to modify the subscription without losing any notifications
> - Allows you to have more then one subscription at a given time
> (including short-lived ones)
> - All the information to be easily processed as soon as it arrives since
> each notification is a complete document
> - Future proofing - easily supports event replay subscriptions
> - Conserves connections
> - Easily supports operator/manager use cases
> - Supporting multiple subscriptions mirrors some popular CLIs
> 
> 
> Cons: 
> 
> - Notifications could be blocked by poorly chosen asynchronous commands
> - Implementations need to perform more tasks on a single connection,
> instead of separating them out into separate ones.
> 
> 2. Never-ending command. A user sends a command which specifies which
> notifications are of interest and waits for a reply. Reply will come in
> the form of notifications at some point in the future. User is unable to
> directly modify the subscription, cancel the command or execute other
> commands.
> 
> Pros: 
> 
> - Simple for the server to implement (see below)
> - On a single connection, the server only has to either send
> notifications or listen for commands
> - There is also less functionality to provide
> - Only blocked by other notifications (not by other commands)
> 
> Cons:
> 
> - Eats up more connections
> - harder for the client to use (See below)
> - Can't be modified ( modifying subscription without losing
> notifications requires creating a new connection, creating a new
> notification command, start receiving notifications, remove duplicates
> then kill the old command)
> - Can't be processed by document oriented XML parsers
> - Unclear how you would cancel the subscription
> - Unclear how to tell if the command was not successful
> 
> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 





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



From owner-netconf@ops.ietf.org Mon Mar 27 15:26:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyHp-00031J-Gs
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:26:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNyHp-0007iJ-78
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:26:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyEH-0000J8-HA
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:22:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNwor-000KTa-MW
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 18:52:01 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2RIpvT24114
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 13:51:57 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: (unofficial issue 2) Subscription versus never-ending command
Date: Mon, 27 Mar 2006 13:51:56 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407926F9E@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: (unofficial issue 2) Subscription versus never-ending command
Thread-Index: AcZRx1bZ1a9VqGfMT0ONrWhT4eUSbQABt+PQ
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

hi

<Andy>
I like the publish/subscribe model, but that is not
what is in the draft. =20
</Andy>
What do you view as being missing then?

<Andy>
IMO the classifications and content
of each notification should be defined independently
of this document.
</Andy>
The classification of content into a small set of very big buckets is
powerful and does not take up much room. I think it is comparable to
defining running and candidate configurations in the base protocol
specification. I don't think it needs a separate specification.


<Andy>
This document should just define how a standard NETCONF agent publishes
a set of IANA-registered event-type URIs to indicate it can meet all the
requirements specified for generating those event types.
</Andy>
To advertise the notifications supported? This is a new requirement. We
were thinking you would advertise them the same way you advertise that
you support XML Schema. We didn't use URIs for this, but I did see the
discussion on the mailing list earlier suggesting that particular
approach.

<Andy>
This document must also specify how a manager subscribes/unsubscribes to
receive an arbitrary subset of those event types.
<Andy>
It does currently, assuming that the filtering mechanisms are
sufficiently powerful.

<Andy>
The only real difference in your list is:
  - the ability to change the event type subscription from
    the same session.
  - the ability to use the same session for operations and
    notifications.
</Andy>

This is overly simplified. The implementation in the draft cleanly
supports creation, modification and cancelling of subscriptions. It also
enables additional useful functionality. The draft tries to balance the
needs of the netconf server against those of the operator/manager acting
in the client role.=20

Sharon




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



From owner-netconf@ops.ietf.org Mon Mar 27 15:28:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyKE-0006XS-Dz
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:28:30 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNyKE-0007lj-47
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:28:30 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyH1-0000cj-U0
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:25:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNyH1-0000cW-5v
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 20:25:11 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RKP9kQ021503
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 15:25:10 -0500
Received: (qmail 23213 invoked by uid 78); 27 Mar 2006 20:25:09 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 27 Mar 2006 20:25:09 -0000
Message-ID: <44284A0F.5010006@andybierman.com>
Date: Mon, 27 Mar 2006 12:24:47 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: "'Tom Petch'" <nwnetworks@dial.pipex.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey [data model first]
References: <789E617C880666438EDEE30C2A3E8D10ED94@mailsrvnt05.enet.sharplabs.com>
In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED94@mailsrvnt05.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

McDonald, Ira wrote:
> Tom Petch wrote on 26 March at 2:34 PM:
>> 2) but could become a 3) if the meeting was somewhere 
>> convenient like London,
>> UK.
>>
>> I think it matters but not as much as getting the current XML 
>> straight, which
>> seems to be taking an inordinate amount of effort, after 
>> which I would give
>> higher priority to the data model.
>>
>> Tom Petch
> 
> I agree with David Perkins - notifications, subscriptions,
> event aggregation, and event filtering are fascinating
> topics.
> 
> However, I fail to see any compelling reason for NetConf
> to reinvent the wheel once again and create yet another
> notification protocol.
> 
> Standard data model is _far_ more important, IMHO.

yeah!!
me too!!

Especially diving into notification content.

Data models for network configuration would seem appropriate,
given this is the NET-CONF WG.


> 
> I still maintain that "merge this blob with that blob" is
> a wildly underspecified operation - so far, NetConf seems
> to have provided the substrate for a number of entirely
> vendor proprietary implementations that do not _by_design_
> interoperate in any meaningful way - I'm astounded that
> the IESG thought it was OK to invent yet another darned
> configuration protocol with no standard data model(s).

You are right Ira. It is data-model dependent and
also a bad practice not to define a data model in such
a way that there is no native order or naming of any kind
for multiple instances of a "row".  If you do a merge on
a multi-instanced element that has a naming scheme and
a natural order, then "merge" is not an problem at all.
(If it hurts when you define bad data models, then just
don't do that.)


The IESG insisted we do the protocol first and not include
data models, in order to phase the work.  It took almost
6 years as it is.

> 
> Cheers,
> - Ira

Andy

> 
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 


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



From owner-netconf@ops.ietf.org Mon Mar 27 15:46:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNybe-0007yE-QM
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:46:30 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNybd-0008NU-GZ
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:46:30 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyWI-00024H-E3
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:40:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FNyWH-00023y-Et
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 20:40:57 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2RKaTQ02552
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 15:36:29 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Moving Event Classes to Iana (was: other stuff)
Date: Mon, 27 Mar 2006 15:40:46 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4079272E0@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Moving Event Classes to Iana (was: other stuff)
Thread-Index: AcZR2+dw4Ma+3uXjTg2iFsq9T/bYIQAADGrw
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

hi

Just to confirm. We are both saying that Notifications are defined in
the data model not IANA, but you are proposing an alternative way to
specify the event classes? Currently they are an enumerated list in the
specification. You are suggesting instead to create an IANA registry?
You are suggesting an initial value for this registry to be a much
smaller subset of event classes then is defined in the current draft.
You are also suggesting to make it URI-based.

I think we can specify a reasonably complete list, so IANA seems a bit
overkill, but as I've mentioned, I have a non-functioning crystal ball,
so I'm open to the idea.

I'm not sure we actually want to make these URI-based instead of an
enumerated list. It is the old SNMP rowPointer versus enumerated list
argument. I always hated rowPointers since there was really no way to
validate them or ensure that there were not 234234234 ways to say the
same thing.

I also worry that we would start out way too conservatively with the
list of event classes or that we might try to block additions to the
list unnecessarily. But I guess we can discuss what the list is and what
IANA's method of working will be and take it from there.=20

Note that the content portion of this specification (aside from event
class) has always just been a non-normative appendix. It was added to
provide context to the operations. If there is consensus to remove it,
then that isn't a big deal.=20

Sharon

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



From owner-netconf@ops.ietf.org Mon Mar 27 15:47:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNycU-0008Qq-V9
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:47:22 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNycT-0008OD-H6
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 15:47:22 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNyZP-0002No-9t
	for netconf-data@psg.com; Mon, 27 Mar 2006 20:44:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FNyZO-0002NZ-JI
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 20:44:10 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-5.cisco.com with ESMTP; 27 Mar 2006 12:44:10 -0800
X-IronPort-AV: i="4.03,135,1141632000"; 
   d="scan'208"; a="264473189:sNHT32077916"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2RKiA7T029442;
	Mon, 27 Mar 2006 12:44:10 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 27 Mar 2006 12:44:09 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Mon, 27 Mar 2006 12:44:06 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB019A0D63@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQR8Tg95kLPNfnTOGmIfDJrhfD/QBlwcdA
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 27 Mar 2006 20:44:09.0949 (UTC) FILETIME=[32DC40D0:01C651DF]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

=20
Put me down for #3=20
Hector

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Saturday, March 25, 2006 1:05 PM
> To: Netconf (E-mail)
> Subject: Interim attendance survey
>=20
> Hi,
>=20
>=20
> I want to do a survey to measure interest in the NETCONF=20
> Notification work.  Very few people read the draft before the=20
> meeting, let alone reviewed it, despite numerous pleas.=20
>=20
> There are 3 choices (option 4: don't care, I already know about):
>=20
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.
>=20
> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.
>=20
> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day=20
> interim meeting.
>=20
>=20
> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)
>=20
> Possible dates: 1 - 2 months before the Montreal IETF (May - June)
>=20
>=20
> Please send comments to the list.
>=20
>=20
> thanks,
> Andy
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Mon Mar 27 16:25:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNzCu-0004Dl-Bu
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:25:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNzCs-0004Me-Un
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:25:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNz83-0005Iv-I2
	for netconf-data@psg.com; Mon, 27 Mar 2006 21:19:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FNySN-0001eE-4L
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 20:36:55 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id AC60B65;
	Mon, 27 Mar 2006 22:36:53 +0200 (CEST)
Date: Mon, 27 Mar 2006 22:36:45 +0200 (CEST)
Message-Id: <20060327.223645.124376879.mbj@tail-f.com>
To: schishol@nortel.com
Cc: netconf@ops.ietf.org
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407926F9E@zcarhxm2.corp.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B407926F9E@zcarhxm2.corp.nortel.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

Hi,

"Sharon Chisholm" <schishol@nortel.com> wrote:
> <Andy>
> This document must also specify how a manager subscribes/unsubscribes to
> receive an arbitrary subset of those event types.
> <Andy>
> It does currently, assuming that the filtering mechanisms are
> sufficiently powerful.

Regarding filtering, I have a comment on the current draft.  It uses
subtree filtering as defined in the protocol, but then in the examples
in section 6.2 it shows how what I think is a boolean OR expression is
built using a tag <neb>, which isn't further described.  What's the
intention here?


/martin



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



From owner-netconf@ops.ietf.org Mon Mar 27 16:41:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNzSb-0007Mr-0g
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:41:13 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNzSZ-00058p-Nv
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:41:13 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNzNf-0006Lt-1o
	for netconf-data@psg.com; Mon, 27 Mar 2006 21:36:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNzNe-0006Li-4o
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 21:36:06 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RLa4Q3028219
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 16:36:04 -0500
Received: (qmail 4315 invoked by uid 78); 27 Mar 2006 21:36:04 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 27 Mar 2006 21:36:04 -0000
Message-ID: <44285AB4.2040300@andybierman.com>
Date: Mon, 27 Mar 2006 13:35:48 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Named Profiles for notification configuration (unofficial issue
 #16)
References: <713043CE8B8E1348AF3C546DBE02C1B407927000@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407927000@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

Sharon Chisholm wrote:
> hi
> 
> <Andy>
> 
> We don't have opaque string data models.
> We have vendors defining explicit XML data models
> in their own namespace.  There is a difference.
> </Andy>
> 

To put this another way:

Among the very first standard objects for netconf
configuration should not be a standard pointer to
opaque proprietary extensions.  This somehow misses
the point of the whole standards thing.

Besides, this is XML, not SMI.
You don't need these objects anymore.
Just extend the RPC parameter set in your own namespace
any way you want.


 >...
> Sharon

Andy

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



From owner-netconf@ops.ietf.org Mon Mar 27 16:42:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNzTr-0007d1-DS
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:42:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNzTq-0005CG-1L
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 16:42:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNzQZ-0006Z7-47
	for netconf-data@psg.com; Mon, 27 Mar 2006 21:39:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.72] (helo=pop-sarus.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FNzQY-0006Ys-2m
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 21:39:06 +0000
Received: from h-68-166-189-73.snvacaid.dynamic.covad.net ([68.166.189.73] helo=oemcomputer)
	by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FNzPi-00065C-00
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 16:38:15 -0500
Message-ID: <043001c651e7$2cdb42a0$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
Date: Mon, 27 Mar 2006 13:41:13 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Hi -

I prefer a subscription-based approach.

However, I dislike the specific subscription approach proposed.
I would prefer a more general approach that separated the
subscription supervision from the data transfer.  All of the 
"cons" of the subscription-based proposal in Sharon's summary
are consequences of requiring the notification flow to happen on
the same connection as was used to create the subscription.

An approach in which a subscription object is treated like any other
chuck of configuration data would not suffer from those problems.
This is one of the few things that CMIP and SNMP do in similar ways.
I think binding a subscription to a specific connection, rather than to
the subscriber's identity, would be an architectural mistake.

Randy


--
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 Mar 27 17:12:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNzwO-0004e7-8d
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 17:12:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNzwN-0006nx-VL
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 17:12:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FNzsS-0008gI-IR
	for netconf-data@psg.com; Mon, 27 Mar 2006 22:07:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FNzsR-0008g6-Qz
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 22:07:55 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2RM7sDT030439
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 17:07:54 -0500
Received: (qmail 9307 invoked by uid 78); 27 Mar 2006 22:07:54 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 27 Mar 2006 22:07:54 -0000
Message-ID: <44286228.5070709@andybierman.com>
Date: Mon, 27 Mar 2006 14:07:36 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com> <043001c651e7$2cdb42a0$6401a8c0@oemcomputer>
In-Reply-To: <043001c651e7$2cdb42a0$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

Randy Presuhn wrote:
> Hi -
> 
> I prefer a subscription-based approach.
> 
> However, I dislike the specific subscription approach proposed.
> I would prefer a more general approach that separated the
> subscription supervision from the data transfer.  All of the 
> "cons" of the subscription-based proposal in Sharon's summary
> are consequences of requiring the notification flow to happen on
> the same connection as was used to create the subscription.
> 
> An approach in which a subscription object is treated like any other
> chuck of configuration data would not suffer from those problems.
> This is one of the few things that CMIP and SNMP do in similar ways.
> I think binding a subscription to a specific connection, rather than to
> the subscriber's identity, would be an architectural mistake.


You read my mind.
I am thinking, why isn't there a table to configure
notification preferences and targets on the agent
instead of this mixed channel or even endless RPC stuff?

Why isn't this just more config data like in SNMP?

All these specialized RPCs are overkill.
Disregard for security and access control will
never get past me or the IESG.

If the preference table entry (indexed by profileName for Sharon ;-)
is a static schema-based configuration instead of session-set parameters,
it is much easier to simply reuse existing architecture than invent
a new one which includes special access control for notifications.

I agree with you that connection-based instead of user-based is a mistake.
In the current draft the agent doesn't decide,
the manager decides with the RPC parameters.


> 
> Randy


Andy

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



From owner-netconf@ops.ietf.org Mon Mar 27 17:28:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO0CV-0006TH-3L
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 17:28:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO0CT-0008Pr-Pr
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 17:28:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO08Y-0009ne-TQ
	for netconf-data@psg.com; Mon, 27 Mar 2006 22:24:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <gagnong@nortel.com>)
	id 1FO08Y-0009nL-0l
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 22:24:34 +0000
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2RMOVl09764;
	Mon, 27 Mar 2006 17:24:31 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Mon, 27 Mar 2006 17:24:30 -0500
Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0941C528@zcarhxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQSKTvUOEmPlHJTNWRL62M0oIJkwBpHc5Q
From: "Gilbert Gagnon" <gagnong@nortel.com>
To: "Andy Bierman" <ietf@andybierman.com>,
   "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c

Option 2 for me.
Notifications is one of the points that distinguishes a protocol from a
CLI in practical terms. Just as configuration needs a flexible yet
structured transport, to which NetConf is a possible answer, so do
notifications.  There's enough common logic between the two to define
them in the same framework IMHO. If NETCONF just wants to be an
XML-based CLI, then Notifications will have to come from somwhere else.
I was hoping for more, personally...

Thanks

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Saturday, March 25, 2006 3:05 PM
To: Netconf (E-mail)
Subject: Interim attendance survey


Hi,


I want to do a survey to measure interest in the
NETCONF Notification work.  Very few people read
the draft before the meeting, let alone reviewed it,
despite numerous pleas.=20

There are 3 choices (option 4: don't care, I already know about):

1) I do not want the NETCONF notification work to continue
   and I will not attend the interim meeting.

2) I want the NETCONF notification work to continue
   but I will not be able to attend the interim meeting.

3) I want the NETCONF notification work to continue
   and I will be able to attend some or all of the 3 day interim
meeting.


Possible location: Outside North America;
                   (hopefully w/ non-stop flights from all over)
                   (3 IETFs in a row in NA already)

Possible dates: 1 - 2 months before the Montreal IETF (May - June)


Please send comments to the list.


thanks,
Andy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Mar 27 19:50:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO2PV-0008DO-BN
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 19:50:13 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO2PR-0005Og-VU
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 19:50:13 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO2IA-000IUH-Cl
	for netconf-data@psg.com; Tue, 28 Mar 2006 00:42:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [62.219.98.8] (helo=antivir1.rad.co.il)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <orly_n@rad.com>)
	id 1FO2I7-000IU1-5e
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 00:42:35 +0000
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k2S0bsxH002790
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 02:37:55 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k2S0bsPX002787;
	Tue, 28 Mar 2006 02:37:54 +0200 (IST)
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 02:43:05 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A520674D84E@exrad2.ad.rad.co.il>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQSREBbE0r0CqYTWmpoCCKXELPXwBt0l+Q
From: "Orly Nicklass" <orly_n@rad.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Option 2 that  might turn to 3 if it takes place 1st or 2nd weekend of
June in the US.=20

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Saturday, March 25, 2006 22:05
To: Netconf (E-mail)
Subject: Interim attendance survey

Hi,


I want to do a survey to measure interest in the NETCONF Notification
work.  Very few people read the draft before the meeting, let alone
reviewed it, despite numerous pleas.=20

There are 3 choices (option 4: don't care, I already know about):

1) I do not want the NETCONF notification work to continue
   and I will not attend the interim meeting.

2) I want the NETCONF notification work to continue
   but I will not be able to attend the interim meeting.

3) I want the NETCONF notification work to continue
   and I will be able to attend some or all of the 3 day interim
meeting.


Possible location: Outside North America;
                   (hopefully w/ non-stop flights from all over)
                   (3 IETFs in a row in NA already)

Possible dates: 1 - 2 months before the Montreal IETF (May - June)


Please send comments to the list.


thanks,
Andy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <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 Mar 27 19:58:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO2Xi-0004Wz-DB
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 19:58:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO2Xh-00064w-37
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 19:58:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO2TC-000JIe-Gp
	for netconf-data@psg.com; Tue, 28 Mar 2006 00:54:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FO2TB-000JIR-OL
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 00:54:02 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2S0s0kQ007675
	for <netconf@ops.ietf.org>; Mon, 27 Mar 2006 19:54:00 -0500
Received: (qmail 5650 invoked by uid 78); 28 Mar 2006 00:54:00 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 28 Mar 2006 00:54:00 -0000
Message-ID: <44288913.6030400@andybierman.com>
Date: Mon, 27 Mar 2006 16:53:39 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Orly Nicklass <orly_n@rad.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <27A0F290348F8E45AEF79889DDE65A520674D84E@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520674D84E@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199

Orly Nicklass wrote:
> Option 2 that  might turn to 3 if it takes place 1st or 2nd weekend of
> June in the US. 

Nope.  Last week in May in London, UK

Andy

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



From owner-netconf@ops.ietf.org Mon Mar 27 20:04:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO2dI-0008Rq-1r
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 20:04:28 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO2dF-0006Zt-WB
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 20:04:28 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO2Z8-000JlL-RC
	for netconf-data@psg.com; Tue, 28 Mar 2006 01:00:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 
	autolearn=ham version=3.1.1
Received: from [133.145.228.5] (helo=mail4.hitachi.co.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <h-okita@crl.hitachi.co.jp>)
	id 1FO2Z6-000Jkp-KW
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 01:00:08 +0000
Received: from mlsv8.hitachi.co.jp (unknown [133.145.228.16])
	by mail4.hitachi.co.jp (Postfix) with ESMTP id 5110E33CC8
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 10:00:07 +0900 (JST)
Received: from mfilter-s6.hitachi.co.jp by mlsv8.hitachi.co.jp (8.12.11/8.12.11) id k2S107P8025206; Tue, 28 Mar 2006 10:00:07 +0900
Received: from vshuts2.hitachi.co.jp (unverified) by mfilter-s6.hitachi.co.jp 
    (Content Technologies SMTPRS 4.3.17) with SMTP id 
    <T774cb484d00ac906b6d5c@mfilter-s6.hitachi.co.jp> for 
    <netconf@ops.ietf.org>; Tue, 28 Mar 2006 10:00:07 +0900
Received: from hcrlgate.crl.hitachi.co.jp ([133.144.31.130]) by 
    vshuts2.hitachi.co.jp with SMTP id M2006032810000623923 for 
    <netconf@ops.ietf.org>; Tue, 28 Mar 2006 10:00:07 +0900
Received: from mailgw1.crl.hitachi.co.jp 
    (mailgw1.crl.hitachi.co.jp [133.144.20.5]) by hcrlgate.crl.hitachi.co.jp 
    (8.11.6/8.11.6) with SMTP id k2S10Ci18269 for <netconf@ops.ietf.org>; Tue
    , 28 Mar 2006 10:00:12 +0900 (JST)
Received: (qmail 3793 invoked by uid 1002); 28 Mar 2006 10:00:03 +0900
Received: from 133.144.20.101 by mailgw1 
    (envelope-from <h-okita@crl.hitachi.co.jp>, uid 502) with 
    qmail-scanner-1.23 
    (spamassassin: 3.0.1. Clear:RC:1(133.144.20.101):SA:0(-150.0/20.0):. Processed in 0.237212 secs)
   ; 28 Mar 2006 01:00:03 -0000
X-Envelope-From: h-okita@crl.hitachi.co.jp
Received: from unknown (HELO crl.hitachi.co.jp) (133.144.20.101) by 
    mailgw1.crl.hitachi.co.jp with SMTP; 28 Mar 2006 10:00:03 +0900
Received: from localhost ([133.144.79.118]) by crl.hitachi.co.jp 
    (8.12.10/8.12.11) with ESMTP id k2S106VG022097; Tue, 28 Mar 2006 10:00:06 
    +0900 (JST)
Date: Tue, 28 Mar 2006 10:00:03 +0900 (JST)
Message-Id: <20060328.100003.35780489.h-okita@crl.hitachi.co.jp>
To: netconf@ops.ietf.org
Cc: "Ray S. Atarashi" <ray@iijlab.net>,
	Yoshifumi Atarashi <atarashi@alaxala.net>
Subject: Re: Interim attendance survey
From: OKITA Hideki <h-okita@crl.hitachi.co.jp>
In-Reply-To: <4427C07F.8090000@alaxala.net> <4425A278.5000804@andybierman.com>
References: <20060327.180717.109274331.ray@iijlab.net> 
    <20060327.184430.22808677.ray@iijlab.net> <4427C07F.8090000@alaxala.net>
Organization: Central Research Lab., Hitachi Ltd., Japan
X-Mailer: Mew version 4.2.51 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985

Hi,

From: Andy Bierman <ietf@andybierman.com>
> I want to do a survey to measure interest in the
> NETCONF Notification work.  Very few people read
> the draft before the meeting, let alone reviewed it,
> despite numerous pleas. 

We are interested in notification work (and datamodel).

If everybody doesn't matter to flight to Japan,
we are pleased to host the interim meeting in Tokyo.

As Atarashi-san wrote,
> we can reserve internet connected meeting room.
> And we found coffee and snack sponcer. :-)

we can serve lunches, beverages and refreshments...

Regards,

Hideki Okita
Central Research Laboratory,
Hitachi, Ltd.



From: Yoshifumi Atarashi <atarashi@alaxala.net>
Subject: Re: Interim attendance survey
Date: Mon, 27 Mar 2006 19:37:51 +0900

> > My suggestion is to hold the interim meeting in Tokyo downtown
> > area around June 12-14. The schedule is flexible.
> >
> > If you're interested, you can tour INTEROP Tokyo, held in near
> > Tokyo, in June 5-9. 
> 
> Interop Tokyo is biggest IT exhibition in Japan.
> You can see Japnese broadband enviroment.
> Probably it isn't rainy season in June 5-14.
> Rainy season starting is about June 20.
> You'll be able to site seeing weekend.
> # http://www.h5.dion.ne.jp/~donkey/sub3.html    and so on.
> 
> we can reserve internet connected meeting room.
> And we found coffee and snack sponcer. :-)
> -------
>   Yoshifumi Atarashi
>   ALAXALA Networks, Corp.
> 
> 			
> > From: "Ray S. Atarashi" <ray@iijlab.net>
> > 
> >>I mean, "Tokyo downtown area", Japan. 
> >>The INTEROP Tokyo is held in June 5-9.
> >>
> >>Ray
> >>
> >>From: "Ray S. Atarashi" <ray@iijlab.net>
> >>
> >>>Hi, 
> >>>
> >>>I guess I (and some Japanese guy) can arrange the interim meeting
> >>>in Japan. How do you think to be held the interim meeting in
> >>>Japan? 
> >>>
> >>>I want to attend the interim meeting, but I can't travel now. 
> >>>If the interim meeing is held in Japan, I am in 3), if not, I am
> >>>in 2).
> >>>
> >>>Ray
> >>>
> >>>
> >>>From: Andy Bierman <ietf@andybierman.com>
> >>>
> >>>>Hi,
> >>>>
> >>>>
> >>>>I want to do a survey to measure interest in the
> >>>>NETCONF Notification work.  Very few people read
> >>>>the draft before the meeting, let alone reviewed it,
> >>>>despite numerous pleas. 
> >>>>
> >>>>There are 3 choices (option 4: don't care, I already know about):
> >>>>
> >>>>1) I do not want the NETCONF notification work to continue
> >>>>   and I will not attend the interim meeting.
> >>>>
> >>>>2) I want the NETCONF notification work to continue
> >>>>   but I will not be able to attend the interim meeting.
> >>>>
> >>>>3) I want the NETCONF notification work to continue
> >>>>   and I will be able to attend some or all of the 3 day interim meeting.
> >>>>
> >>>>
> >>>>Possible location: Outside North America;
> >>>>                   (hopefully w/ non-stop flights from all over)
> >>>>                   (3 IETFs in a row in NA already)
> >>>>
> >>>>Possible dates: 1 - 2 months before the Montreal IETF (May - June)
> >>>>
> >>>>
> >>>>Please send comments to the list.
> >>>>
> >>>>
> >>>>thanks,
> >>>>Andy
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>to unsubscribe send a message to netconf-request@ops.ietf.org with
> >>>>the word 'unsubscribe' in a single line as the message text body.
> >>>>archive: <http://ops.ietf.org/lists/netconf/>
> >>>>
> >>>
> >>>--
> >>>to unsubscribe send a message to netconf-request@ops.ietf.org with
> >>>the word 'unsubscribe' in a single line as the message text body.
> >>>archive: <http://ops.ietf.org/lists/netconf/>
> >>>
> >>
> >>--
> >>to unsubscribe send a message to netconf-request@ops.ietf.org with
> >>the word 'unsubscribe' in a single line as the message text body.
> >>archive: <http://ops.ietf.org/lists/netconf/>
> >>
> > 
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> > 
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

--
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 Mar 27 23:31:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO5rD-0004PM-1m
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 23:31:03 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO5rA-0006FA-Mf
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 23:31:03 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO5ll-0004Ge-N5
	for netconf-data@psg.com; Tue, 28 Mar 2006 04:25:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.66] (helo=pop-canoe.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FO5lk-0004GS-Dn
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 04:25:25 +0000
Received: from h-68-166-189-73.snvacaid.dynamic.covad.net ([68.166.189.73] helo=oemcomputer)
	by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FO5lj-0005C5-00
	for netconf@ops.ietf.org; Mon, 27 Mar 2006 23:25:23 -0500
Message-ID: <002701c65220$1030c2e0$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <44280952.40002@andybierman.com>
Subject: Re: Real Notification Requirements
Date: Mon, 27 Mar 2006 20:28:28 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

Hi -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, March 27, 2006 7:48 AM
> Subject: Real Notification Requirements


...
> Content Layer Requirements
> --------------------------
> 
> C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
> 
> C2) NETCONF configuration change notification
> 
> C3) ???
...

Based on experience with a product for which management protocol was
the sole means of configuration, the following are some events that the
notification protocol should be able to represent.  (there were more, but
these are some I remember as being important to the configuration
management part)  These are low-level, but I think they make the point that
configuration change notification isn't the only thing a configuration management
system will need to know about.

   - (configurable) hardware resource added (e.g. card plugged into chassis of
     running system, or a cable to an expansion chassis plugged in)
   - hardware resource removed (e.g. card pulled out of running system, or
     expansion chassis cable unplugged)
   - failover in n:m redundancy (failover results in 1 of m posible configurations
     being activated on 1 of the n backup resources - this is a very interesting event)
   - system reverting to configuration version foo (because version bar is corrupt
     or has become unusable, e.g. due to swapped hardware version compatibility issues)
   - configuration data store off-line (e.g., disk drive failed or removed from chassis)

Randy


--
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 Mar 27 23:44:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO649-0002Xw-47
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 23:44:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO647-0006T2-Pa
	for netconf-archive@lists.ietf.org; Mon, 27 Mar 2006 23:44:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FO5zj-00051u-5f
	for netconf-data@psg.com; Tue, 28 Mar 2006 04:39:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FO5zi-00051h-IC
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 04:39:50 +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 k2S4ddX90728;
	Mon, 27 Mar 2006 20:39:43 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2S4dX522892;
	Mon, 27 Mar 2006 20:39:33 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2S4ilYE052899;
	Mon, 27 Mar 2006 23:44:47 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603280444.k2S4ilYE052899@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey 
In-Reply-To: Your message of "Mon, 27 Mar 2006 16:53:39 PST."
             <44288913.6030400@andybierman.com> 
Date: Mon, 27 Mar 2006 23:44:47 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

Andy Bierman writes:
>Nope.  Last week in May in London, UK

Unfortunately, this timing knocks me from a 3 to a 2.  I'm booked
up the last two weeks of May and the first week of June.

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 Tue Mar 28 04:56:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOAwH-0006XR-Pr
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 04:56:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOAwH-0001w8-3P
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 04:56:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOApb-000Jlb-NU
	for netconf-data@psg.com; Tue, 28 Mar 2006 09:49:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOApZ-000JlD-Mr
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 09:49:42 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9DE85913
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 11:49:40 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 28 Mar 2006 11:49:40 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 28 Mar 2006 11:49:40 +0200
Message-ID: <442906B3.2080406@ericsson.com>
Date: Tue, 28 Mar 2006 11:49:39 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com> <043001c651e7$2cdb42a0$6401a8c0@oemcomputer> <44286228.5070709@andybierman.com>
In-Reply-To: <44286228.5070709@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Mar 2006 09:49:40.0182 (UTC) FILETIME=[EEAB1760:01C6524C]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

Do we allow one user to use multiple subscriptions ? I would say yes.

If we connect the notification subscription strictly to a user identity we force the user 
to specify security data multiple times to be able to use multiple subscriptions. Is this 
our aim or am I missing something ? (In our management system different functional parts 
are interested in different notifications, but I see no need for a security point of view 
to require multiple user identities for them.)

Balazs

Andy Bierman wrote:
> Randy Presuhn wrote:
>> Hi -
>>
>> I prefer a subscription-based approach.
>>
>> However, I dislike the specific subscription approach proposed.
>> I would prefer a more general approach that separated the
>> subscription supervision from the data transfer.  All of the "cons" of 
>> the subscription-based proposal in Sharon's summary
>> are consequences of requiring the notification flow to happen on
>> the same connection as was used to create the subscription.
>>
>> An approach in which a subscription object is treated like any other
>> chuck of configuration data would not suffer from those problems.
>> This is one of the few things that CMIP and SNMP do in similar ways.
>> I think binding a subscription to a specific connection, rather than to
>> the subscriber's identity, would be an architectural mistake.
> 
> 
> You read my mind.
> I am thinking, why isn't there a table to configure
> notification preferences and targets on the agent
> instead of this mixed channel or even endless RPC stuff?
> 
> Why isn't this just more config data like in SNMP?
> 
> All these specialized RPCs are overkill.
> Disregard for security and access control will
> never get past me or the IESG.
> 
> If the preference table entry (indexed by profileName for Sharon ;-)
> is a static schema-based configuration instead of session-set parameters,
> it is much easier to simply reuse existing architecture than invent
> a new one which includes special access control for notifications.
> 
> I agree with you that connection-based instead of user-based is a mistake.
> In the current draft the agent doesn't decide,
> the manager decides with the RPC parameters.
> 
> 
>>
>> Randy
> 
> 
> Andy
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Tue Mar 28 06:00:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOBvc-0005BQ-5E
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 06:00:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOBvb-0004qL-Gr
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 06:00:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOBqz-000NZh-3F
	for netconf-data@psg.com; Tue, 28 Mar 2006 10:55:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,
	UNPARSEABLE_RELAY autolearn=ham version=3.1.1
Received: from [202.232.30.157] (helo=omgo.iij.ad.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ray@iijlab.net>)
	id 1FOBqv-000NZK-9k
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 10:55:09 +0000
Received: OTM-MO id k2SAt1GI028250; Tue, 28 Mar 2006 19:55:01 +0900 (JST)
Received: OTM-MIX0 id k2SAt0Qq008259; Tue, 28 Mar 2006 19:55:00 +0900 (JST)
Received: from localhost (h169n190.iij.ad.jp [192.168.190.169])
	by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k2SAsw9F023173;
	Tue, 28 Mar 2006 19:55:00 +0900 (JST)
Date: Tue, 28 Mar 2006 19:55:04 +0900 (LMT)
Message-Id: <20060328.195504.14273535.ray@iijlab.net>
To: schishol@nortel.com
Cc: netconf@ops.ietf.org
Subject: Re: Moving Event Classes to Iana
From: "Ray S. Atarashi" <ray@iijlab.net>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4079272E0@zcarhxm2.corp.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B4079272E0@zcarhxm2.corp.nortel.com>
X-Mailer: Mew version 4.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Hi, 

IMO, Notifications should be defined in the data model not
IANA. We can develop the mechanism to maintenance the event
classes using XML-related technologies such as XML namespace.

I prefer to make these URI-based. If you want to use enumerated
list, you can map the URL-based to the enumerated list.
				
Ray

From: "Sharon Chisholm" <schishol@nortel.com>
> hi
> 
> Just to confirm. We are both saying that Notifications are defined in
> the data model not IANA, but you are proposing an alternative way to
> specify the event classes? Currently they are an enumerated list in the
> specification. You are suggesting instead to create an IANA registry?
> You are suggesting an initial value for this registry to be a much
> smaller subset of event classes then is defined in the current draft.
> You are also suggesting to make it URI-based.
> 
> I think we can specify a reasonably complete list, so IANA seems a bit
> overkill, but as I've mentioned, I have a non-functioning crystal ball,
> so I'm open to the idea.
> 
> I'm not sure we actually want to make these URI-based instead of an
> enumerated list. It is the old SNMP rowPointer versus enumerated list
> argument. I always hated rowPointers since there was really no way to
> validate them or ensure that there were not 234234234 ways to say the
> same thing.
> 
> I also worry that we would start out way too conservatively with the
> list of event classes or that we might try to block additions to the
> list unnecessarily. But I guess we can discuss what the list is and what
> IANA's method of working will be and take it from there. 
> 
> Note that the content portion of this specification (aside from event
> class) has always just been a non-normative appendix. It was added to
> provide context to the operations. If there is consensus to remove it,
> then that isn't a big deal. 
> 
> Sharon
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


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



From owner-netconf@ops.ietf.org Tue Mar 28 07:28:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FODJR-0007sU-7p
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 07:28:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FODJP-0000L8-V2
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 07:28:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FODCI-0004xN-96
	for netconf-data@psg.com; Tue, 28 Mar 2006 12:21:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FODCH-0004x1-F7
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 12:21:17 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SCLDf00183
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 07:21:13 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 07:20:55 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407927718@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZSAuZjn2I7bV48Q8msCajbLB1a1QAXp9AA
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

hi

I take it this date is based on availability of a venue or something?

I have a personal commitment in Ottawa the morning of May 27th. If we do
that week, if we can do it earlier in the week to ensure I'm back (not
jet lagged might be too much to ask for), I'd really appreciate it.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Monday, March 27, 2006 7:54 PM
To: Orly Nicklass
Cc: Netconf (E-mail)
Subject: Re: Interim attendance survey


Orly Nicklass wrote:
> Option 2 that  might turn to 3 if it takes place 1st or 2nd weekend of

> June in the US.

Nope.  Last week in May in London, UK

Andy

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


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



From owner-netconf@ops.ietf.org Tue Mar 28 08:40:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOERO-0007tP-Q1
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 08:40:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOERO-0002xN-G7
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 08:40:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOEIW-0008up-KW
	for netconf-data@psg.com; Tue, 28 Mar 2006 13:31:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOEIV-0008uV-Ok
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 13:31:47 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2SDUIml011787
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 08:30:18 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2SDSaer002408
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 08:28:37 -0500 (EST)
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: Interim attendance survey
Date: Tue, 28 Mar 2006 15:31:44 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E53@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZSAuZjn2I7bV48Q8msCajbLB1a1QAXp9AAAAKKxwA=
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Sharon Chisholm" <schishol@nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

I am not sure either about what week we are talking.=20

If this is about the week of May 22, I cannot make it at all.=20

If it's the week of May 29, I could possibly make May 29-31, but need to
be back to Israel in the morning of June 1st.=20

The first week of June would be much better.=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Tuesday, March 28, 2006 2:21 PM
> To: Netconf (E-mail)
> Subject: RE: Interim attendance survey
>=20
> hi
>=20
> I take it this date is based on availability of a venue or something?
>=20
> I have a personal commitment in Ottawa the morning of May=20
> 27th. If we do that week, if we can do it earlier in the week=20
> to ensure I'm back (not jet lagged might be too much to ask=20
> for), I'd really appreciate it.
>=20
> Sharon
>=20
> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Monday, March 27, 2006 7:54 PM
> To: Orly Nicklass
> Cc: Netconf (E-mail)
> Subject: Re: Interim attendance survey
>=20
>=20
> Orly Nicklass wrote:
> > Option 2 that  might turn to 3 if it takes place 1st or 2nd=20
> weekend of
>=20
> > June in the US.
>=20
> Nope.  Last week in May in London, UK
>=20
> Andy
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Mar 28 09:07:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOErB-0005uv-SC
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:07:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOErB-0004ES-ID
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:07:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOEhx-000Acs-GF
	for netconf-data@psg.com; Tue, 28 Mar 2006 13:58:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOEhw-000AcT-HU
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 13:58:04 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SDvxf06345
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 08:58:00 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 08:57:55 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407927840@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZSAuZjn2I7bV48Q8msCajbLB1a1QAXp9AAAAKKxwAAANIb0A==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

hi

I just doubled checked my commitment, and it is for morning of the 28th,
which would make it a challenge (impossible?) to be in Europe the
morning of the 29th. It makes the previous week a bit better though.
Also later in the week of the 29th should work as well.

It sounds like we need a bit more discussion on dates before we can lock
into something that will work with all of our constraints.

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
Sent: Tuesday, March 28, 2006 8:32 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
Subject: RE: Interim attendance survey


I am not sure either about what week we are talking.=20

If this is about the week of May 22, I cannot make it at all.=20

If it's the week of May 29, I could possibly make May 29-31, but need to
be back to Israel in the morning of June 1st.=20

The first week of June would be much better.=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Tuesday, March 28, 2006 2:21 PM
> To: Netconf (E-mail)
> Subject: RE: Interim attendance survey
>=20
> hi
>=20
> I take it this date is based on availability of a venue or something?
>=20
> I have a personal commitment in Ottawa the morning of May
> 27th. If we do that week, if we can do it earlier in the week=20
> to ensure I'm back (not jet lagged might be too much to ask=20
> for), I'd really appreciate it.
>=20
> Sharon
>=20
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Monday, March 27, 2006 7:54 PM
> To: Orly Nicklass
> Cc: Netconf (E-mail)
> Subject: Re: Interim attendance survey
>=20
>=20
> Orly Nicklass wrote:
> > Option 2 that  might turn to 3 if it takes place 1st or 2nd
> weekend of
>=20
> > June in the US.
>=20
> Nope.  Last week in May in London, UK
>=20
> Andy
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <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/>
>=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 Mar 28 09:25:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOF8C-00016J-I5
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:25:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOF8B-0005F1-D8
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:25:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOF0c-000BuP-FZ
	for netconf-data@psg.com; Tue, 28 Mar 2006 14:17:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 
	autolearn=ham version=3.1.1
Received: from [133.145.228.43] (helo=mail8.hitachi.co.jp)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ktoumura@crl.hitachi.co.jp>)
	id 1FOF0a-000BuA-1J
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 14:17:20 +0000
Received: from mlsv10.hitachi.co.jp (unknown [133.145.228.16])
	by mail8.hitachi.co.jp (Postfix) with ESMTP id B93EF37C88
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 23:17:16 +0900 (JST)
Received: from mfilter-s5.hitachi.co.jp by mlsv10.hitachi.co.jp (8.12.11/8.12.11) id k2SEHGJD013693; Tue, 28 Mar 2006 23:17:16 +0900
Received: from vshuts1.hitachi.co.jp (unverified) by mfilter-s5.hitachi.co.jp
 (Content Technologies SMTPRS 4.3.17) with SMTP id <T774f8e56720ac906b5aa0@mfilter-s5.hitachi.co.jp> for <netconf@ops.ietf.org>;
 Tue, 28 Mar 2006 23:17:16 +0900
Received: from hcrlgate.crl.hitachi.co.jp ([133.144.31.130])
 by vshuts1.hitachi.co.jp with SMTP id M2006032823171605973
 for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 23:17:16 +0900
Received: from mailgw2.crl.hitachi.co.jp (mailgw2.crl.hitachi.co.jp [133.144.20.6])
	by hcrlgate.crl.hitachi.co.jp (8.11.6/8.11.6) with SMTP id k2SEHMi08750
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 23:17:22 +0900 (JST)
Received: (qmail 2452 invoked by uid 1002); 28 Mar 2006 23:17:05 +0900
Received: from 133.144.20.101 by mailgw2 (envelope-from <ktoumura@crl.hitachi.co.jp>, uid 502) with qmail-scanner-1.23 
 (spamassassin: 3.0.1.  
 Clear:RC:1(133.144.20.101):SA:0(-150.2/20.0):. 
 Processed in 0.141228 secs); 28 Mar 2006 14:17:05 -0000
X-Envelope-From: ktoumura@crl.hitachi.co.jp
Received: from unknown (HELO crl.hitachi.co.jp) (133.144.20.101)
  by mailgw2.crl.hitachi.co.jp with SMTP; 28 Mar 2006 23:17:05 +0900
Received: from [192.168.0.5] ([133.144.20.40])
	by crl.hitachi.co.jp (8.12.10/8.12.11) with ESMTP id k2SEHGVG004525
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 23:17:16 +0900 (JST)
Message-ID: <44294562.4050404@crl.hitachi.co.jp>
Date: Tue, 28 Mar 2006 23:17:06 +0900
From: Kunihiko Toumura <ktoumura@crl.hitachi.co.jp>
Organization: Central Research Lab., Hitachi Ltd.
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: netconf@ops.ietf.org
Subject: Re: Notification Message Processing Model
References: <200603232023.k2NKNfYE022289@idle.juniper.net>
In-Reply-To: <200603232023.k2NKNfYE022289@idle.juniper.net>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

Hi,

IMHO, it is unreasonable to adhere to use <rpc> for notification.

In notification, a server (=router/switch) sends message to client (=manager),
and there is no need to reply for the notification message.
This far differs from RPC model (client->server, request-reply).

I prefer separating <rpc> and <notification>, and providing different
application protocol for each method.

-- 
TOUMURA Kunihiko - ktoumura@crl.hitachi.co.jp
Central Research Laboratory, Hitachi, Ltd.

Phil Shafer wrote:
> Andy Bierman writes:
>>   An active NETCONF session has two modes:
> 
> This introduces modality into the netconf session, which
> is increasing the complexity.
> 
> Instead, we could just have a simple RPC that is long-lived:
> 
> C:  <rpc ...>
> C:    <get-syslog-notifications>
> C:      <level>warning</level>
> C:    </get-syslog-notifications>
> C:  </rpc>
> 
> The server responds with an <rpc-reply> containing an
> unending series of notifications which match the criteria from
> the <get-syslog-notifications> RPC:
> 
> S:  <rpc-reply ...>
> S:    <notification> ... data for one notification ... </notification>
> S:    <notification> ... data for another notification ... </notification>
> S:    <notification> ... data for yet another notification ... </notification>
> S:    <notification> ... data for one more notification ... </notification>
> 
> The notifications would continue until the channel is closed.  Or
> until we resurrect the <abort/> mechanism ;^)
> 
> This is simple, direct, and uses the existing netconf framework.
> If interleaving is a lose-lose, this is a win-win.
> 
> Thanks,
>  Phil
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 



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



From owner-netconf@ops.ietf.org Tue Mar 28 09:32:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFFM-0005tx-04
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:32:36 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOFFL-0005gv-Hv
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:32:35 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOF8f-000CUB-Px
	for netconf-data@psg.com; Tue, 28 Mar 2006 14:25:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOF8e-000CTq-HT
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 14:25:41 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2SEErkQ023697
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 09:14:54 -0500
Received: (qmail 6730 invoked by uid 78); 28 Mar 2006 14:14:53 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 28 Mar 2006 14:14:53 -0000
Message-ID: <442944BC.5020208@andybierman.com>
Date: Tue, 28 Mar 2006 06:14:20 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E53@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E53@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168

Romascanu, Dan (Dan) wrote:
> I am not sure either about what week we are talking. 
> 
> If this is about the week of May 22, I cannot make it at all. 
> 
> If it's the week of May 29, I could possibly make May 29-31, but need to
> be back to Israel in the morning of June 1st. 
> 
> The first week of June would be much better. 

I am just trying to get an idea of who would show up.
So far (besides the authors and 1 co-chair, which doesn't
even count) there are about 2 people who can attend
an interim at the end of May in London.

I don't think there is enough interest to hold an interim.

If the interim is too late, then there won't
enough time afterwards to get a new draft out
before the I-D cutoff for Montreal.


> 
> Dan

Andy

> 
> 
>  
>  
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
>> Sent: Tuesday, March 28, 2006 2:21 PM
>> To: Netconf (E-mail)
>> Subject: RE: Interim attendance survey
>>
>> hi
>>
>> I take it this date is based on availability of a venue or something?
>>
>> I have a personal commitment in Ottawa the morning of May 
>> 27th. If we do that week, if we can do it earlier in the week 
>> to ensure I'm back (not jet lagged might be too much to ask 
>> for), I'd really appreciate it.
>>
>> Sharon
>>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Monday, March 27, 2006 7:54 PM
>> To: Orly Nicklass
>> Cc: Netconf (E-mail)
>> Subject: Re: Interim attendance survey
>>
>>
>> Orly Nicklass wrote:
>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd 
>> weekend of
>>
>>> June in the US.
>> Nope.  Last week in May in London, UK
>>
>> Andy
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org 
>> with the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org 
>> with the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Tue Mar 28 09:41:14 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFNi-0001i6-Ph
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:41:14 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOFNh-0005yC-CX
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 09:41:14 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOFII-000DM1-GR
	for netconf-data@psg.com; Tue, 28 Mar 2006 14:35:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOFIH-000DLO-Eg
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 14:35:37 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SEZWf06415
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 09:35:33 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 09:34:47 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407927945@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZScf/1dEcFasXJSJ6n3nwg0CcHmQAAg01A
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3

hi

There were a number of people who said they could attend depending on
location and dates. Let's try some other dates

3. Week of May 8th
4. Week of May 15th
5. Week of June 5th

where 1 was week of May 22nd and 2 was week of May 29th.

Of course, we could also consider a series of teleconference, but it is
difficult to get a timeslot that works for everyone.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Tuesday, March 28, 2006 9:14 AM
To: Romascanu, Dan (Dan)
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
Subject: Re: Interim attendance survey


Romascanu, Dan (Dan) wrote:
> I am not sure either about what week we are talking.
>=20
> If this is about the week of May 22, I cannot make it at all.
>=20
> If it's the week of May 29, I could possibly make May 29-31, but need=20
> to be back to Israel in the morning of June 1st.
>=20
> The first week of June would be much better.

I am just trying to get an idea of who would show up.
So far (besides the authors and 1 co-chair, which doesn't
even count) there are about 2 people who can attend
an interim at the end of May in London.

I don't think there is enough interest to hold an interim.

If the interim is too late, then there won't
enough time afterwards to get a new draft out
before the I-D cutoff for Montreal.


>=20
> Dan

Andy

>=20
>=20
> =20
> =20
>=20
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
>> Sent: Tuesday, March 28, 2006 2:21 PM
>> To: Netconf (E-mail)
>> Subject: RE: Interim attendance survey
>>
>> hi
>>
>> I take it this date is based on availability of a venue or something?
>>
>> I have a personal commitment in Ottawa the morning of May
>> 27th. If we do that week, if we can do it earlier in the week=20
>> to ensure I'm back (not jet lagged might be too much to ask=20
>> for), I'd really appreciate it.
>>
>> Sharon
>>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Monday, March 27, 2006 7:54 PM
>> To: Orly Nicklass
>> Cc: Netconf (E-mail)
>> Subject: Re: Interim attendance survey
>>
>>
>> Orly Nicklass wrote:
>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd
>> weekend of
>>
>>> June in the US.
>> Nope.  Last week in May in London, UK
>>
>> Andy
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org
>> with the word 'unsubscribe' in a single line as the message text
body.
>> archive: <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/>
>>
>=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 Tue Mar 28 10:09:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFp8-0005Te-W1
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:09:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOFp7-0006mN-Jt
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:09:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOFiH-000FG4-CC
	for netconf-data@psg.com; Tue, 28 Mar 2006 15:02:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FOFiG-000FFs-Pe
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 15:02:28 +0000
Received: from [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b] (unknown [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id B93C9E6106;
	Tue, 28 Mar 2006 15:02:27 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <44295001.3090309@isc.org>
Date: Tue, 28 Mar 2006 17:02:25 +0200
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Real Notification Requirements
References: <44280952.40002@andybierman.com>
In-Reply-To: <44280952.40002@andybierman.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

Andy Bierman wrote:
> Hi,
> 
> This new thread is for people to articulate use cases
> to support functional requirement requests.
> Translation: What is the developer or operator doing now, and
> how will it change to something great and wonderful because
> of this new feature?
> 
> Let's try some top-down design, since ad-hoc design isn't
> going so well.
> 
> I believe there is consensus so far for 2 uses of notifications
> in the NETCONF protocol:
> 
> 
> Content Layer Requirements
> --------------------------
> 
> C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
> 
> C2) NETCONF configuration change notification
> 
> C3) ???

I had a quick look at draft-ietf-syslog-protocol-16, and was interested
to see it supports structured data in addition to traditional syslog
free-form text. It also has a way for vendors to specify their own
structured data identifiers, and several standard ones defined already.

I wonder what the key differences are between the SYSLOG stuff and
anything within the NETCONF notification. Perhaps:

- XML (of course)
- Registration vs. complete log feed

Is there anything else?

Perhaps it would be better to focus on adding a subscription mechanism
to SYSLOG?

--
Shane

--
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 Mar 28 10:20:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFzc-0007cx-LS
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:20:24 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOFza-00078K-6Y
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:20:24 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOFvS-000G63-3Z
	for netconf-data@psg.com; Tue, 28 Mar 2006 15:16:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOFvR-000G5p-2j
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 15:16:05 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2SFG2Zj020320
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 10:16:03 -0500
Received: (qmail 9264 invoked by uid 78); 28 Mar 2006 15:16:02 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 28 Mar 2006 15:16:02 -0000
Message-ID: <44295313.5040307@andybierman.com>
Date: Tue, 28 Mar 2006 07:15:31 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <713043CE8B8E1348AF3C546DBE02C1B407927945@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407927945@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

Sharon Chisholm wrote:
> hi
> 
> There were a number of people who said they could attend depending on
> location and dates. Let's try some other dates
> 
> 3. Week of May 8th
> 4. Week of May 15th
> 5. Week of June 5th
> 

I want to make sure there is time to publish
an updated draft before the I-D cutoff for Montreal.

I think the most realistic choices would be in
Montreal, either before (Th, July 6 - Sat, July 8)
or after (Fri July 14 - Sun July 16) IETF #66.


> where 1 was week of May 22nd and 2 was week of May 29th.
> 
> Of course, we could also consider a series of teleconference, but it is
> difficult to get a timeslot that works for everyone.

I am considering another approach.
Putting your document on the shelf and forcing
the WG to write a Requirements specification first.
The current draft doesn't even have a Requirements section.

We have no agreement on why we need notifications
in NETCONF and what specific roles they serve.
We don't event agree on whether notification content
is part of the problem space or not.

I could argue that the SYSLOG WG should standardize the
protocol and contents for system logging messages, not NETCONF.
There are some people (including myself) who think
that if we are going to work on data models, we should
work on configuration data models, not notification content.



> 
> Sharon

Andy


> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Tuesday, March 28, 2006 9:14 AM
> To: Romascanu, Dan (Dan)
> Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
> Subject: Re: Interim attendance survey
> 
> 
> Romascanu, Dan (Dan) wrote:
>> I am not sure either about what week we are talking.
>>
>> If this is about the week of May 22, I cannot make it at all.
>>
>> If it's the week of May 29, I could possibly make May 29-31, but need 
>> to be back to Israel in the morning of June 1st.
>>
>> The first week of June would be much better.
> 
> I am just trying to get an idea of who would show up.
> So far (besides the authors and 1 co-chair, which doesn't
> even count) there are about 2 people who can attend
> an interim at the end of May in London.
> 
> I don't think there is enough interest to hold an interim.
> 
> If the interim is too late, then there won't
> enough time afterwards to get a new draft out
> before the I-D cutoff for Montreal.
> 
> 
>> Dan
> 
> Andy
> 
>>
>>  
>>  
>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org
>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
>>> Sent: Tuesday, March 28, 2006 2:21 PM
>>> To: Netconf (E-mail)
>>> Subject: RE: Interim attendance survey
>>>
>>> hi
>>>
>>> I take it this date is based on availability of a venue or something?
>>>
>>> I have a personal commitment in Ottawa the morning of May
>>> 27th. If we do that week, if we can do it earlier in the week 
>>> to ensure I'm back (not jet lagged might be too much to ask 
>>> for), I'd really appreciate it.
>>>
>>> Sharon
>>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org
>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>>> Sent: Monday, March 27, 2006 7:54 PM
>>> To: Orly Nicklass
>>> Cc: Netconf (E-mail)
>>> Subject: Re: Interim attendance survey
>>>
>>>
>>> Orly Nicklass wrote:
>>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd
>>> weekend of
>>>
>>>> June in the US.
>>> Nope.  Last week in May in London, UK
>>>
>>> Andy
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org
>>> with the word 'unsubscribe' in a single line as the message text
> body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org
>>> with the word 'unsubscribe' in a single line as the message text
> body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> 
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Tue Mar 28 10:21:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOG0n-0007mk-9G
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:21:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOG0m-0007Aq-5k
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:21:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOFvd-000G6S-PC
	for netconf-data@psg.com; Tue, 28 Mar 2006 15:16:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [203.178.142.162] (helo=pc1.alaxala.net)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <atarashi@alaxala.net>)
	id 1FOEV0-0009na-73
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 13:44:44 +0000
Received: from localhost (localhost [127.0.0.1])
	by pc1.alaxala.net (Postfix) with ESMTP id 91328BB21;
	Tue, 28 Mar 2006 22:44:39 +0900 (JST)
Received: from pc1.alaxala.net ([127.0.0.1])
 by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 72227-08; Tue, 28 Mar 2006 22:44:35 +0900 (JST)
Received: from [192.168.0.2] (2.30.30.125.dy.iij4u.or.jp [125.30.30.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by pc1.alaxala.net (Postfix) with ESMTP id A2EAABB20;
	Tue, 28 Mar 2006 22:44:35 +0900 (JST)
Message-ID: <44293DB6.6010401@alaxala.net>
Date: Tue, 28 Mar 2006 22:44:22 +0900
From: Yoshifumi Atarashi <atarashi@alaxala.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
CC: Sharon Chisholm <schishol@nortel.com>, 
 "Netconf (E-mail)" <netconf@ops.ietf.org>,
 Yoshifumi Atarashi <atarashi@alaxala.net>
Subject: Re: Interim attendance survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E53@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E53@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at alaxala.net
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

You are talking about schedule.
But nobody commited to arrange the interim meeting facility except us.
Does some one find any sponcer and good meeting rooms?
We can arrage any schedule in May and June.

Welcome to Japan :-)
Maybe good season.
-------
  Yoshifumi Atarashi


Romascanu, Dan (Dan) wrote:
> I am not sure either about what week we are talking. 
> 
> If this is about the week of May 22, I cannot make it at all. 
> 
> If it's the week of May 29, I could possibly make May 29-31, but need to
> be back to Israel in the morning of June 1st. 
> 
> The first week of June would be much better. 
> 
> Dan
> 
> 
>  
>  
> 
> 
>>-----Original Message-----
>>From: owner-netconf@ops.ietf.org 
>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
>>Sent: Tuesday, March 28, 2006 2:21 PM
>>To: Netconf (E-mail)
>>Subject: RE: Interim attendance survey
>>
>>hi
>>
>>I take it this date is based on availability of a venue or something?
>>
>>I have a personal commitment in Ottawa the morning of May 
>>27th. If we do that week, if we can do it earlier in the week 
>>to ensure I'm back (not jet lagged might be too much to ask 
>>for), I'd really appreciate it.
>>
>>Sharon
>>
>>-----Original Message-----
>>From: owner-netconf@ops.ietf.org 
>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>>Sent: Monday, March 27, 2006 7:54 PM
>>To: Orly Nicklass
>>Cc: Netconf (E-mail)
>>Subject: Re: Interim attendance survey
>>
>>
>>Orly Nicklass wrote:
>>
>>>Option 2 that  might turn to 3 if it takes place 1st or 2nd 
>>
>>weekend of
>>
>>
>>>June in the US.
>>
>>Nope.  Last week in May in London, UK
>>
>>Andy
>>
>>--
>>to unsubscribe send a message to netconf-request@ops.ietf.org 
>>with the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>>--
>>to unsubscribe send a message to netconf-request@ops.ietf.org 
>>with the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/netconf/>
>>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 




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



From owner-netconf@ops.ietf.org Tue Mar 28 10:22:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOG1d-0007s0-Md
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:22:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOG1c-0007Fg-32
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 10:22:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOFxb-000GDy-0T
	for netconf-data@psg.com; Tue, 28 Mar 2006 15:18:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOFxZ-000GDj-JG
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 15:18:17 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id CE10755DCC;
	Tue, 28 Mar 2006 17:18:16 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 29224-01; Tue, 28 Mar 2006 17:18:15 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 0BEED55DFB;
	Tue, 28 Mar 2006 17:18:13 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id C251564DF6F; Tue, 28 Mar 2006 17:18:11 +0200 (CEST)
Date: Tue, 28 Mar 2006 17:18:11 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Shane Kerr <Shane_Kerr@isc.org>
Cc: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Real Notification Requirements
Message-ID: <20060328151811.GA6407@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Shane Kerr <Shane_Kerr@isc.org>,
	Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <44280952.40002@andybierman.com> <44295001.3090309@isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44295001.3090309@isc.org>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

On Tue, Mar 28, 2006 at 05:02:25PM +0200, Shane Kerr wrote:
 
> Perhaps it would be better to focus on adding a subscription mechanism
> to SYSLOG?

Certainly an option. Having a subcription mechanism is actually for me
an important feature. Some 12 years ago, we hacked our central syslog
daemon to actually ship syslog messages once you connected to it and
it was a lovely hack which we used a lot (since it makes access to
syslog message real simply for programs).

On the classification question: I think you can put anything into
syslog, so the distinction between syslog messages, configuration
change notifications, or SNMP notifications is kind of artificial.

In fact, it seems popular in many operational environments to have
SNMP notification receivers which simply write to syslog, probably
because there are also pretty nice syslog readers that can trigger all
sorts of actions when they discover certain input patterns.

If we do an interim, it would be valuable to get some syslog experts
there as well so that we can evaluate whether structured syslog and
syslog enhancements will actually solve the problem.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Tue Mar 28 11:44:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHJE-00053U-Tw
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 11:44:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOHJD-0002Xd-Kv
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 11:44:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHF9-000LHA-TO
	for netconf-data@psg.com; Tue, 28 Mar 2006 16:40:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FOHF9-000LGv-Be
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 16:40:31 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2SGeT1Z007710;
	Tue, 28 Mar 2006 08:40:29 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2SGeS550021;
	Tue, 28 Mar 2006 08:40:28 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2SGjgYE055634;
	Tue, 28 Mar 2006 11:45:42 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603281645.k2SGjgYE055634@idle.juniper.net>
To: Kunihiko Toumura <ktoumura@crl.hitachi.co.jp>
cc: netconf@ops.ietf.org
Subject: Re: Notification Message Processing Model 
In-Reply-To: Your message of "Tue, 28 Mar 2006 23:17:06 +0900."
             <44294562.4050404@crl.hitachi.co.jp> 
Date: Tue, 28 Mar 2006 11:45:42 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Kunihiko Toumura writes:
>In notification, a server (=router/switch) sends message to client (=manager),
>and there is no need to reply for the notification message.
>This far differs from RPC model (client->server, request-reply).

It's a matter of perspective, I guess.  I see it as an RPC asking
for a realtime feed of specific syslog data.  The reply contains
the data, and continues feeding data until the request is aborted.
The client is requesting data, the server is serving it up, in a
classic client/server model.

In the subscription-model, the application asks the device to send
notifications as a background task, interleaved with the normal
<rpc-reply>s that are the netconf mainstay.  I dislike this "oh by
the way, if you're bored, please send some notifications" metaphor.
It takes a fairly simple request for data and turns into something
more complex.  It puts multiplexing/interleaving into an RPC mechanism
where it is not well suited, imho.

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 Tue Mar 28 11:44:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHJG-00053x-N3
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 11:44:46 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOHJG-0002Xj-2X
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 11:44:46 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHFK-000LI6-TM
	for netconf-data@psg.com; Tue, 28 Mar 2006 16:40:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	SPF_PASS autolearn=ham version=3.1.1
Received: from [85.10.201.79] (helo=hetzner.adiscon.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@hq.adiscon.com>)
	id 1FOHF9-000LGu-3J
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 16:40:31 +0000
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id D2AFC27C066;
	Tue, 28 Mar 2006 17:45:39 +0200 (CEST)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 00535-07; Tue, 28 Mar 2006 17:45:39 +0200 (CEST)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 7F37127C061;
	Tue, 28 Mar 2006 17:45:39 +0200 (CEST)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 28 Mar 2006 18:40:29 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Real Notification Requirements
Date: Tue, 28 Mar 2006 18:40:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1743C9@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Real Notification Requirements
Thread-Index: AcZSfM5b2vLp/fJLQh+UAjjUOGlxJgAByXww
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <j.schoenwaelder@iu-bremen.de>, "Shane Kerr" <Shane_Kerr@isc.org>
Cc: "Andy Bierman" <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 28 Mar 2006 16:40:30.0001 (UTC) FILETIME=[531AFA10:01C65286]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8

Hello,

I am a lurker on this list. My name is Rainer Gerhards and I am the
editor of the syslog-protocol draft. I think it might be useful if I
provide some of my views of how syslog could relate to the notification
work.

STRUCTURED-DATA in syslog is a flat system. There is only one level of
depth. The syslog WG considers this to be sufficient for syslog uses
because most information that syslog conveys is non-hierarchical. Also
syslog-sec was concerend about the maximum message size (we need to be
able to provide meaningful messages in as few as 480 octets). However,
STRUCTURED-DATA is designed as the primary extension mechanism for
syslog. It is my belief that XML-data fits nicely into the
STRUCTURED-DATA part, if there is need to.

Another major difference is that syslog is still a simplex protocol.
Also, the transport tends to be more simplistic in general, because this
is what we see the market place dictates. So we currently do not try to
standardize a secure transport on top of SSH but rather on top of TLS
(which is often deployed in practice).=20

A subscribtion model would require considerable change to syslog. There
would be no consensus to integrate this into the current set of drafts.

A major problem with the syslog-sec wg has been lack of interest and
sufficient review. If there would be more voices, things would probably
have evolved into a different direction. On the other hand, RFC 3195
(BEEP-based syslog) has not gotten any momentum and received few
implementations. That implies that rapid change is not easily accepted
in syslog.

I do not have a strong opinion of NETCONF notifications should be merged
with syslog. I've seen some of the problems that we faced come up here
(e.g. message length), but I am not sure if the potential user base is
similar enough to justify a merge. I like that NETCONF notifications are
able to do more changes than we can do in syslog.

Many syslog receivers consume SNMP traps today. If NETCONF notifications
get standardized, I would expect that many syslog receivers would
consume them, too.=20

My 2cts ... maybe the are useful for somebody ;)

Rainer Gerhards

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, March 28, 2006 5:18 PM
> To: Shane Kerr
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: Real Notification Requirements
>=20
> On Tue, Mar 28, 2006 at 05:02:25PM +0200, Shane Kerr wrote:
> =20
> > Perhaps it would be better to focus on adding a=20
> subscription mechanism
> > to SYSLOG?
>=20
> Certainly an option. Having a subcription mechanism is actually for me
> an important feature. Some 12 years ago, we hacked our central syslog
> daemon to actually ship syslog messages once you connected to it and
> it was a lovely hack which we used a lot (since it makes access to
> syslog message real simply for programs).
>=20
> On the classification question: I think you can put anything into
> syslog, so the distinction between syslog messages, configuration
> change notifications, or SNMP notifications is kind of artificial.
>=20
> In fact, it seems popular in many operational environments to have
> SNMP notification receivers which simply write to syslog, probably
> because there are also pretty nice syslog readers that can trigger all
> sorts of actions when they discover certain input patterns.
>=20
> If we do an interim, it would be valuable to get some syslog experts
> there as well so that we can evaluate whether structured syslog and
> syslog enhancements will actually solve the problem.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561,=20
> 28725 Bremen, Germany
>=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

--
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 Mar 28 12:08:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHgT-00023h-VK
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:08:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOHgS-0003kK-LJ
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:08:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHcz-000NDw-4u
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:05:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOHcy-000NDh-60
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:05:08 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2SH56ts008478
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:05:06 -0500
Received: (qmail 20324 invoked by uid 78); 28 Mar 2006 17:05:06 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 28 Mar 2006 17:05:06 -0000
Message-ID: <44296CBC.1070606@andybierman.com>
Date: Tue, 28 Mar 2006 09:05:00 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: no interim meeting -- read the rules
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Hi,

Here is the IESG rules on holding interim meetings:

http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt

We can't have an interim meeting within 30 days before the IETF,
and we can't have one instead of our 2 hour slot just after
the IETF.

There is supposedly interest in the notification work.
I don't understand why most of these people have time
and money to go to an interim to work on this topic,
but they don't have time to read the draft and send comments
to the mailing list, or show up to the IETF meeting in Dallas
prepared to work on this document.

As Dan and Dave H. pointed out, we need to agree on what
we are doing and why we are doing it.  Several people
have told me (and mentioned on the list) that they
don't understand why we are reinventing syslog instead
of working on network configuration.

So let's write down all the reasons why we need notifications
in NETCONF, and why using or extending existing standards
instead won't work.

It doesn't really matter which parameters get passed
in the 'start-notifications' RPC if the entire work item
ends up in the dumpster, does it?


Andy


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



From owner-netconf@ops.ietf.org Tue Mar 28 12:23:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHuQ-0002Pn-31
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:23:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOHuP-0004Tq-KM
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:23:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHqR-000ON6-M7
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:19:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOHqQ-000OMm-88
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:19:02 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SHIvf10613
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:18:57 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 12:18:56 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40798EC87@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZSepC3g0isaOPwQtmSS39Zi6PIjgADqelw
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227

hi

We have historically not had much luck with requirements documents
(unless killing a working group can be considered success) or
requirements sections which is why they were not included in the draft.
If we wanted to start documenting requirements in parallel with
developing the notifications draft, that could potentially be
productive.

I believe that the list of requirements and a realistic assessment of
the likelihood of successfully updating legacy solutions (documents and
deployments) to meet those requirements (including alignment with
Netconf content) will support the general direction we are taking. If
people need to do the math on that and it helps get us more on the same
page, then that would be good.

Note though that I know of at least three different vendors that now
have non-interoperable solutions for doing notifications in Netconf. I'm
not sure how that serves the industry.

I'm not sure who's pushing standardizing notification content as our
next priority, but when I look at what to do after standardizing on the
messaging format (the goal of the current draft), access control and
*how* to specify content are pretty high up there for me.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Tuesday, March 28, 2006 10:16 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Interim attendance survey


Sharon Chisholm wrote:
> hi
>=20
> There were a number of people who said they could attend depending on=20
> location and dates. Let's try some other dates
>=20
> 3. Week of May 8th
> 4. Week of May 15th
> 5. Week of June 5th
>=20

I want to make sure there is time to publish
an updated draft before the I-D cutoff for Montreal.

I think the most realistic choices would be in
Montreal, either before (Th, July 6 - Sat, July 8)
or after (Fri July 14 - Sun July 16) IETF #66.


> where 1 was week of May 22nd and 2 was week of May 29th.
>=20
> Of course, we could also consider a series of teleconference, but it=20
> is difficult to get a timeslot that works for everyone.

I am considering another approach.
Putting your document on the shelf and forcing
the WG to write a Requirements specification first.
The current draft doesn't even have a Requirements section.

We have no agreement on why we need notifications
in NETCONF and what specific roles they serve.
We don't event agree on whether notification content
is part of the problem space or not.

I could argue that the SYSLOG WG should standardize the protocol and
contents for system logging messages, not NETCONF. There are some people
(including myself) who think that if we are going to work on data
models, we should work on configuration data models, not notification
content.



>=20
> Sharon

Andy


>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Tuesday, March 28, 2006 9:14 AM
> To: Romascanu, Dan (Dan)
> Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
> Subject: Re: Interim attendance survey
>=20
>=20
> Romascanu, Dan (Dan) wrote:
>> I am not sure either about what week we are talking.
>>
>> If this is about the week of May 22, I cannot make it at all.
>>
>> If it's the week of May 29, I could possibly make May 29-31, but need
>> to be back to Israel in the morning of June 1st.
>>
>> The first week of June would be much better.
>=20
> I am just trying to get an idea of who would show up.
> So far (besides the authors and 1 co-chair, which doesn't even count)=20
> there are about 2 people who can attend an interim at the end of May=20
> in London.
>=20
> I don't think there is enough interest to hold an interim.
>=20
> If the interim is too late, then there won't
> enough time afterwards to get a new draft out
> before the I-D cutoff for Montreal.
>=20
>=20
>> Dan
>=20
> Andy
>=20
>>
>> =20
>> =20
>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]

>>> On Behalf Of Sharon Chisholm
>>> Sent: Tuesday, March 28, 2006 2:21 PM
>>> To: Netconf (E-mail)
>>> Subject: RE: Interim attendance survey
>>>
>>> hi
>>>
>>> I take it this date is based on availability of a venue or=20
>>> something?
>>>
>>> I have a personal commitment in Ottawa the morning of May 27th. If=20
>>> we do that week, if we can do it earlier in the week to ensure I'm=20
>>> back (not jet lagged might be too much to ask for), I'd really=20
>>> appreciate it.
>>>
>>> Sharon
>>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]

>>> On Behalf Of Andy Bierman
>>> Sent: Monday, March 27, 2006 7:54 PM
>>> To: Orly Nicklass
>>> Cc: Netconf (E-mail)
>>> Subject: Re: Interim attendance survey
>>>
>>>
>>> Orly Nicklass wrote:
>>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd
>>> weekend of
>>>
>>>> June in the US.
>>> Nope.  Last week in May in London, UK
>>>
>>> Andy
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
>>> 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=20
>>> 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=20
>> the
>=20
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>=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/>
>=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 Mar 28 12:25:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHwO-0004H7-Qc
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:25:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOHwO-0004ci-E8
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:25:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHtj-000Oda-BG
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:22:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOHti-000OdJ-ED
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:22:26 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2SHKuUb018997
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:20:56 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2SHJFdu019349
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:19:16 -0500 (EST)
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: no interim meeting -- read the rules
Date: Tue, 28 Mar 2006 19:22:23 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E88@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: no interim meeting -- read the rules
Thread-Index: AcZSieJKagZpCiGyQDmz2xKFcF4QrwAAGecQ
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

Right. We seem to need:
- comments on the current draft
- a requirements for notifications in NETCONF contribution - desired in
Internet-Draft format
- contributions for other solutions=20

A dialog with the syslog community also could be useful.=20

Then we can discuss what form of meetings we need. I will do my best to
help (AD hat on). Rules must help the process while keeping it fair. For
example the rules seem to allow to have an interim meeting immediately
after the IETF supplementary to the usual meeting during the IETF. But
we need to have rough consensus that this would be helpful.=20

Regards,

Dan



=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, March 28, 2006 7:05 PM
> To: Netconf (E-mail)
> Subject: no interim meeting -- read the rules
>=20
> Hi,
>=20
> Here is the IESG rules on holding interim meetings:
>=20
> http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt
>=20
> We can't have an interim meeting within 30 days before the=20
> IETF, and we can't have one instead of our 2 hour slot just=20
> after the IETF.
>=20
> There is supposedly interest in the notification work.
> I don't understand why most of these people have time and=20
> money to go to an interim to work on this topic, but they=20
> don't have time to read the draft and send comments to the=20
> mailing list, or show up to the IETF meeting in Dallas=20
> prepared to work on this document.
>=20
> As Dan and Dave H. pointed out, we need to agree on what we=20
> are doing and why we are doing it.  Several people have told=20
> me (and mentioned on the list) that they don't understand why=20
> we are reinventing syslog instead of working on network configuration.
>=20
> So let's write down all the reasons why we need notifications=20
> in NETCONF, and why using or extending existing standards=20
> instead won't work.
>=20
> It doesn't really matter which parameters get passed in the=20
> 'start-notifications' RPC if the entire work item ends up in=20
> the dumpster, does it?
>=20
>=20
> Andy
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Mar 28 12:30:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOI1e-0006mQ-42
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:30:38 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOI1e-0004rA-22
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:30:38 -0500
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FOI1c-0003q9-Cg
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:30:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHyd-000PCT-FB
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:27:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOHyc-000PCH-Fi
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:27:30 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2SHRSts003151
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:27:29 -0500
Received: (qmail 7028 invoked by uid 78); 28 Mar 2006 17:27:28 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 28 Mar 2006 17:27:28 -0000
Message-ID: <442971F7.2050409@andybierman.com>
Date: Tue, 28 Mar 2006 09:27:19 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: no interim meeting -- read the rules
References: <44296CBC.1070606@andybierman.com>
In-Reply-To: <44296CBC.1070606@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Andy Bierman wrote:
> Hi,
> 
> Here is the IESG rules on holding interim meetings:
> 
> http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt
> 
> We can't have an interim meeting within 30 days before the IETF,
> and we can't have one instead of our 2 hour slot just after
> the IETF.
> 

Actually our AD just informed me that he thinks it
would be okay to have the regular NETCONF session
on Friday morning, and then continue the interim
(for those who want to stay) until Sunday.

That is what we will plan to do. July 14-16 at the
IETF #66 hotel.

Thank you to everybody who offered to host the interim.
I hope you will show up in Montreal instead.


Andy

> There is supposedly interest in the notification work.
> I don't understand why most of these people have time
> and money to go to an interim to work on this topic,
> but they don't have time to read the draft and send comments
> to the mailing list, or show up to the IETF meeting in Dallas
> prepared to work on this document.
> 
> As Dan and Dave H. pointed out, we need to agree on what
> we are doing and why we are doing it.  Several people
> have told me (and mentioned on the list) that they
> don't understand why we are reinventing syslog instead
> of working on network configuration.
> 
> So let's write down all the reasons why we need notifications
> in NETCONF, and why using or extending existing standards
> instead won't work.
> 
> It doesn't really matter which parameters get passed
> in the 'start-notifications' RPC if the entire work item
> ends up in the dumpster, does it?
> 
> 
> Andy
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Tue Mar 28 12:31:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOI2l-0006sw-I4
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:31:47 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOI2l-0004uh-G5
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:31:47 -0500
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FOI2i-0003qQ-RV
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:31:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOHz8-000PHz-Ny
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:28:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <alex@cisco.com>)
	id 1FOHz8-000PHi-1x
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:28:02 +0000
Received: from sj-core-4.cisco.com ([171.68.223.138])
  by sj-iport-4.cisco.com with ESMTP; 28 Mar 2006 09:28:02 -0800
X-IronPort-AV: i="4.03,139,1141632000"; 
   d="scan'208"; a="1789173443:sNHT39443844"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2SHS1Yg017736;
	Tue, 28 Mar 2006 09:28:01 -0800 (PST)
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Tue, 28 Mar 2006 09:28:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 09:28:00 -0800
Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB01777479@xmb-sjc-236.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZQR8TjuA7YpEP/RXuTH9rlsToGvACROwBw
From: "Alexander Clemm \(alex\)" <alex@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 28 Mar 2006 17:28:01.0598 (UTC) FILETIME=[F6CA25E0:01C6528C]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Please put me down for #2. =20
--- Alex=20

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Saturday, March 25, 2006 12:05 PM
To: Netconf (E-mail)
Subject: Interim attendance survey

Hi,


I want to do a survey to measure interest in the NETCONF Notification
work.  Very few people read the draft before the meeting, let alone
reviewed it, despite numerous pleas.=20

There are 3 choices (option 4: don't care, I already know about):

1) I do not want the NETCONF notification work to continue
   and I will not attend the interim meeting.

2) I want the NETCONF notification work to continue
   but I will not be able to attend the interim meeting.

3) I want the NETCONF notification work to continue
   and I will be able to attend some or all of the 3 day interim
meeting.


Possible location: Outside North America;
                   (hopefully w/ non-stop flights from all over)
                   (3 IETFs in a row in NA already)

Possible dates: 1 - 2 months before the Montreal IETF (May - June)


Please send comments to the list.


thanks,
Andy




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

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



From owner-netconf@ops.ietf.org Tue Mar 28 12:40:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOIBe-0004bK-34
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:40:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOIBd-0005IK-Ki
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:40:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOI8e-000097-Q1
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:37:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOI8d-00008q-A9
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:37:51 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2SHbl620485
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:37:47 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Interim attendance survey
Date: Tue, 28 Mar 2006 12:37:46 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40798ECCD@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim attendance survey
Thread-Index: AcZSepC3g0isaOPwQtmSS39Zi6PIjgAEpvrg
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7

hi

So, they can't be 30 days before the July IETF meeting and need to
announced 30 days in advanced. Doesn't this leave us a window of April
27 -> June 9? So, while we didn't have quorum for the first date
proposed, are you suggesting we don't have consensus at all to meet, or
that I'm misinterpreting the window?

I believe this week we are starting to get people reading the draft and
commenting on it. This is good. An interim meeting or a series of
conference calls should help maintain the momentum. I always get in
trouble with the mailing list purist, but I'll take input into a
document whichever way works :-).

Sharon=20

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Tuesday, March 28, 2006 10:16 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Interim attendance survey


Sharon Chisholm wrote:
> hi
>=20
> There were a number of people who said they could attend depending on=20
> location and dates. Let's try some other dates
>=20
> 3. Week of May 8th
> 4. Week of May 15th
> 5. Week of June 5th
>=20

I want to make sure there is time to publish
an updated draft before the I-D cutoff for Montreal.

I think the most realistic choices would be in
Montreal, either before (Th, July 6 - Sat, July 8)
or after (Fri July 14 - Sun July 16) IETF #66.


> where 1 was week of May 22nd and 2 was week of May 29th.
>=20
> Of course, we could also consider a series of teleconference, but it=20
> is difficult to get a timeslot that works for everyone.

I am considering another approach.
Putting your document on the shelf and forcing
the WG to write a Requirements specification first.
The current draft doesn't even have a Requirements section.

We have no agreement on why we need notifications
in NETCONF and what specific roles they serve.
We don't event agree on whether notification content
is part of the problem space or not.

I could argue that the SYSLOG WG should standardize the protocol and
contents for system logging messages, not NETCONF. There are some people
(including myself) who think that if we are going to work on data
models, we should work on configuration data models, not notification
content.



>=20
> Sharon

Andy


>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Tuesday, March 28, 2006 9:14 AM
> To: Romascanu, Dan (Dan)
> Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
> Subject: Re: Interim attendance survey
>=20
>=20
> Romascanu, Dan (Dan) wrote:
>> I am not sure either about what week we are talking.
>>
>> If this is about the week of May 22, I cannot make it at all.
>>
>> If it's the week of May 29, I could possibly make May 29-31, but need
>> to be back to Israel in the morning of June 1st.
>>
>> The first week of June would be much better.
>=20
> I am just trying to get an idea of who would show up.
> So far (besides the authors and 1 co-chair, which doesn't even count)=20
> there are about 2 people who can attend an interim at the end of May=20
> in London.
>=20
> I don't think there is enough interest to hold an interim.
>=20
> If the interim is too late, then there won't
> enough time afterwards to get a new draft out
> before the I-D cutoff for Montreal.
>=20
>=20
>> Dan
>=20
> Andy
>=20
>>
>> =20
>> =20
>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]

>>> On Behalf Of Sharon Chisholm
>>> Sent: Tuesday, March 28, 2006 2:21 PM
>>> To: Netconf (E-mail)
>>> Subject: RE: Interim attendance survey
>>>
>>> hi
>>>
>>> I take it this date is based on availability of a venue or=20
>>> something?
>>>
>>> I have a personal commitment in Ottawa the morning of May 27th. If=20
>>> we do that week, if we can do it earlier in the week to ensure I'm=20
>>> back (not jet lagged might be too much to ask for), I'd really=20
>>> appreciate it.
>>>
>>> Sharon
>>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]

>>> On Behalf Of Andy Bierman
>>> Sent: Monday, March 27, 2006 7:54 PM
>>> To: Orly Nicklass
>>> Cc: Netconf (E-mail)
>>> Subject: Re: Interim attendance survey
>>>
>>>
>>> Orly Nicklass wrote:
>>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd
>>> weekend of
>>>
>>>> June in the US.
>>> Nope.  Last week in May in London, UK
>>>
>>> Andy
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
>>> 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=20
>>> 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=20
>> the
>=20
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>=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/>
>=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 Mar 28 12:45:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOIGO-0006wS-7e
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:45:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOIGN-0005X5-U7
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 12:45:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOICx-0000W6-Az
	for netconf-data@psg.com; Tue, 28 Mar 2006 17:42:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOICu-0000Vs-KW
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:42:16 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2SHgFQ3027299
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 12:42:15 -0500
Received: (qmail 4041 invoked by uid 78); 28 Mar 2006 17:42:15 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 28 Mar 2006 17:42:15 -0000
Message-ID: <44297571.3000403@andybierman.com>
Date: Tue, 28 Mar 2006 09:42:09 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
References: <713043CE8B8E1348AF3C546DBE02C1B40798EC87@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40798EC87@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

Sharon Chisholm wrote:
> hi
> 
> We have historically not had much luck with requirements documents
> (unless killing a working group can be considered success) or
> requirements sections which is why they were not included in the draft.
> If we wanted to start documenting requirements in parallel with
> developing the notifications draft, that could potentially be
> productive.
> 
> I believe that the list of requirements and a realistic assessment of
> the likelihood of successfully updating legacy solutions (documents and
> deployments) to meet those requirements (including alignment with
> Netconf content) will support the general direction we are taking. If
> people need to do the math on that and it helps get us more on the same
> page, then that would be good.
> 
> Note though that I know of at least three different vendors that now
> have non-interoperable solutions for doing notifications in Netconf. I'm
> not sure how that serves the industry.
> 
> I'm not sure who's pushing standardizing notification content as our
> next priority, but when I look at what to do after standardizing on the
> messaging format (the goal of the current draft), access control and
> *how* to specify content are pretty high up there for me.


We do requirements documents when we deadlock on the solution.
Like now.  IMO, the WG opinions are all over the map.  I cannot
declare WG consensus for or against anything so far.
If we can't agree on the requirements, then the work should
be shut down.

As Dan just pointed out, there needs to be many more reviews
of the draft, work on requirements, and even people willing to do
implementations in order for us to make progress.

We were able to make NETCONF happen because it started as
XMLCONF, which started as Junoscript.  Without operators
saying they liked Junoscript and wanted us to standardize
it, we wouldn't be talking about notifications for netconf today.

This time we seem to be deep in the sandbox instead.


> 
> Sharon

Andy

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



From owner-netconf@ops.ietf.org Tue Mar 28 13:19:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOInH-00017i-HL
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:19:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOInH-0007bx-2r
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:19:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOIjB-0002yz-UX
	for netconf-data@psg.com; Tue, 28 Mar 2006 18:15:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [12.129.211.51] (helo=usaga01-in.huawei.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dharrington@huawei.com>)
	id 1FOHDK-000L9F-IR
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 16:38:38 +0000
Received: from huawei.com (usaga01-in [172.18.4.6])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0IWU000HVJF0RF@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 08:35:24 -0800 (PST)
Received: from Harrington73653 ([10.124.8.206])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0IWU001N4JEZ3D@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 08:35:24 -0800 (PST)
Date: Tue, 28 Mar 2006 10:38:34 -0600
From: David Harrington <dharrington@huawei.com>
Subject: RE: Interim attendance survey
In-reply-to: <44295313.5040307@andybierman.com>
To: 'Andy Bierman' <ietf@andybierman.com>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Message-id: <010d01c65286$0e486a80$e4087c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb

Hi,

I am willing to attend an interim. At this point, I am not particular
about the date or location.

I don't fit into any of the four categories provided.

I am not convinced we have justified notifications adequately, and am
willing to attend an interm meeting to discuss the goals that underlie
including notifications in the Netconf protocol.

David Harrington
dharrington@huawei.com 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, March 28, 2006 9:16 AM
> To: Sharon Chisholm
> Cc: Netconf (E-mail)
> Subject: Re: Interim attendance survey
> 
> 
> Sharon Chisholm wrote:
> > hi
> > 
> > There were a number of people who said they could attend 
> depending on
> > location and dates. Let's try some other dates
> > 
> > 3. Week of May 8th
> > 4. Week of May 15th
> > 5. Week of June 5th
> > 
> 
> I want to make sure there is time to publish
> an updated draft before the I-D cutoff for Montreal.
> 
> I think the most realistic choices would be in
> Montreal, either before (Th, July 6 - Sat, July 8)
> or after (Fri July 14 - Sun July 16) IETF #66.
> 
> 
> > where 1 was week of May 22nd and 2 was week of May 29th.
> > 
> > Of course, we could also consider a series of 
> teleconference, but it is
> > difficult to get a timeslot that works for everyone.
> 
> I am considering another approach.
> Putting your document on the shelf and forcing
> the WG to write a Requirements specification first.
> The current draft doesn't even have a Requirements section.
> 
> We have no agreement on why we need notifications
> in NETCONF and what specific roles they serve.
> We don't event agree on whether notification content
> is part of the problem space or not.
> 
> I could argue that the SYSLOG WG should standardize the
> protocol and contents for system logging messages, not NETCONF.
> There are some people (including myself) who think
> that if we are going to work on data models, we should
> work on configuration data models, not notification content.
> 
> 
> 
> > 
> > Sharon
> 
> Andy
> 
> 
> > 
> > -----Original Message-----
> > From: Andy Bierman [mailto:ietf@andybierman.com] 
> > Sent: Tuesday, March 28, 2006 9:14 AM
> > To: Romascanu, Dan (Dan)
> > Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
> > Subject: Re: Interim attendance survey
> > 
> > 
> > Romascanu, Dan (Dan) wrote:
> >> I am not sure either about what week we are talking.
> >>
> >> If this is about the week of May 22, I cannot make it at all.
> >>
> >> If it's the week of May 29, I could possibly make May 
> 29-31, but need 
> >> to be back to Israel in the morning of June 1st.
> >>
> >> The first week of June would be much better.
> > 
> > I am just trying to get an idea of who would show up.
> > So far (besides the authors and 1 co-chair, which doesn't
> > even count) there are about 2 people who can attend
> > an interim at the end of May in London.
> > 
> > I don't think there is enough interest to hold an interim.
> > 
> > If the interim is too late, then there won't
> > enough time afterwards to get a new draft out
> > before the I-D cutoff for Montreal.
> > 
> > 
> >> Dan
> > 
> > Andy
> > 
> >>
> >>  
> >>  
> >>
> >>> -----Original Message-----
> >>> From: owner-netconf@ops.ietf.org
> >>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> >>> Sent: Tuesday, March 28, 2006 2:21 PM
> >>> To: Netconf (E-mail)
> >>> Subject: RE: Interim attendance survey
> >>>
> >>> hi
> >>>
> >>> I take it this date is based on availability of a venue 
> or something?
> >>>
> >>> I have a personal commitment in Ottawa the morning of May
> >>> 27th. If we do that week, if we can do it earlier in the week 
> >>> to ensure I'm back (not jet lagged might be too much to ask 
> >>> for), I'd really appreciate it.
> >>>
> >>> Sharon
> >>>
> >>> -----Original Message-----
> >>> From: owner-netconf@ops.ietf.org
> >>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> >>> Sent: Monday, March 27, 2006 7:54 PM
> >>> To: Orly Nicklass
> >>> Cc: Netconf (E-mail)
> >>> Subject: Re: Interim attendance survey
> >>>
> >>>
> >>> Orly Nicklass wrote:
> >>>> Option 2 that  might turn to 3 if it takes place 1st or 2nd
> >>> weekend of
> >>>
> >>>> June in the US.
> >>> Nope.  Last week in May in London, UK
> >>>
> >>> Andy
> >>>
> >>> --
> >>> to unsubscribe send a message to netconf-request@ops.ietf.org
> >>> with the word 'unsubscribe' in a single line as the message text
> > body.
> >>> archive: <http://ops.ietf.org/lists/netconf/>
> >>>
> >>>
> >>> --
> >>> to unsubscribe send a message to netconf-request@ops.ietf.org
> >>> with the word 'unsubscribe' in a single line as the message text
> > body.
> >>> archive: <http://ops.ietf.org/lists/netconf/>
> >>>
> >> --
> >> to unsubscribe send a message to 
> netconf-request@ops.ietf.org with the
> > 
> >> word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://ops.ietf.org/lists/netconf/>
> >>
> >>
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> > 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 




--
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 Mar 28 13:19:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOInI-00017u-9q
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:19:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOInH-0007bw-0M
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:19:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOIjL-00030J-HT
	for netconf-data@psg.com; Tue, 28 Mar 2006 18:15:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.1
Received: from [209.173.53.84] (helo=willow.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FOHdi-000NHO-HF
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 17:05:54 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2SH5p9W020374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 28 Mar 2006 17:05:51 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FOHdf-0000mn-4V; Tue, 28 Mar 2006 12:05:51 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
   RFC Editor <rfc-editor@rfc-editor.org>,
   netconf mailing list <netconf@ops.ietf.org>,
   netconf chair <simon@switch.ch>, netconf chair <ietf@andybierman.com>
Subject: Protocol Action: 'Using the NETCONF Protocol over Blocks 
         Extensible Exchange Protocol (BEEP)' to Proposed Standard 
Message-Id: <E1FOHdf-0000mn-4V@stiedprstage1.ietf.org>
Date: Tue, 28 Mar 2006 12:05:51 -0500
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

The IESG has approved the following document:

- 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) '
   <draft-ietf-netconf-beep-10.txt> as a Proposed Standard

This document is the product of the Network Configuration Working Group. 

The IESG contact persons are Bert Wijnen and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-10.txt

Technical Summary

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

Working Group Summary
 
   The NETCONF Working Group has consensus to publish this document
   as a Proposed Standard.  

Protocol Quality

   It is likely that there are several implementations of this
   document in various stages of completion at this time.
   Several major equipment vendors have indicated interest in
   supporting this document, and some non-commercial
   implementations are also expected.  The WG would like to
   thank Marshall Rose for his assistance with portions
   of this document.

   Bert Wijnen has reviewed this document for the IESG

IANA Note

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, March 23, 2006 14:45
To: Bert Wijnen
Cc: iana@iana.org
Subject: Port request for draft-ietf-netconf-beep-10.txt


Hi,

Please assign a port number < 1024 for the NETCONF
protocol over the Blocks Extensible Exchange protocol,
as specified in section 4 of this document.


thanks,
Andy




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



From owner-netconf@ops.ietf.org Tue Mar 28 13:22:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOIpc-0001e8-GE
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:22:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOIpa-0007gl-UD
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:22:16 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOImX-0003FK-Bk
	for netconf-data@psg.com; Tue, 28 Mar 2006 18:19:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FOImW-0003F4-Hk
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 18:19:04 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2SIIdIo025345;
	Tue, 28 Mar 2006 10:18:39 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HRTBR4N8>; Tue, 28 Mar 2006 10:18:40 -0800
Message-ID: <789E617C880666438EDEE30C2A3E8D10ED9C@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'shane_kerr@isc.org'" <shane_kerr@isc.org>,
        Andy Bierman
	 <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RE: Real Notification Requirements
Date: Tue, 28 Mar 2006 10:18:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027

Hi Shane,

A partial, informal list of current, widely-deployed network
element configuration protocols:

- IETF SNMP over TCP, UDP, ISO TP4, NetWare, AppleTalk, etc.
- ISO CMIP over TCP, ISO TP4, etc.
- DMTF DMI over TCP - DMI MIFs for IETF and vendor MIBs
- DMTF WBEM over HTTP - XML schema for DMTF CIM MOFs
- Oasis WSDM over SOAP - XML schema for WS-Resource* framework
- DMTF WS-Management over SOAP - XML schema for WS-Resource*

DMTF and Oasis have a formal alliance to convert all CIM XML
schema into the WS-Resource* framework for use with WSDM.

WSDM and WS-Management have just issued a historic convergence
white paper that shows how they'll add new higher level classes
to allow a single application data model and harmonize the
resource, transfer, notifications, and subscriptions elements:

 
http://www-128.ibm.com/developerworks/webservices/library/specification/ws-r
oadmap/ 

  http://devresource.hp.com/drc/specifications/wsm/index.jsp

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Shane Kerr
> Sent: Tuesday, March 28, 2006 10:02 AM
> To: Andy Bierman
> Cc: Netconf (E-mail)
> Subject: Re: Real Notification Requirements
> 
> 
> Andy Bierman wrote:
> > Hi,
> > 
> > This new thread is for people to articulate use cases
> > to support functional requirement requests.
> > Translation: What is the developer or operator doing now, and
> > how will it change to something great and wonderful because
> > of this new feature?
> > 
> > Let's try some top-down design, since ad-hoc design isn't
> > going so well.
> > 
> > I believe there is consensus so far for 2 uses of notifications
> > in the NETCONF protocol:
> > 
> > 
> > Content Layer Requirements
> > --------------------------
> > 
> > C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
> > 
> > C2) NETCONF configuration change notification
> > 
> > C3) ???
> 
> I had a quick look at draft-ietf-syslog-protocol-16, and was 
> interested
> to see it supports structured data in addition to traditional syslog
> free-form text. It also has a way for vendors to specify their own
> structured data identifiers, and several standard ones 
> defined already.
> 
> I wonder what the key differences are between the SYSLOG stuff and
> anything within the NETCONF notification. Perhaps:
> 
> - XML (of course)
> - Registration vs. complete log feed
> 
> Is there anything else?
> 
> Perhaps it would be better to focus on adding a subscription mechanism
> to SYSLOG?
> 
> --
> Shane
> 
> --
> 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/>
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.2/294 - Release 
> Date: 3/27/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.2/294 - Release Date: 3/27/2006
 

--
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 Mar 28 13:23:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOIql-0003Fz-MI
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:23:27 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOIql-0007lT-84
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 13:23:27 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOIo1-0003Rh-4a
	for netconf-data@psg.com; Tue, 28 Mar 2006 18:20:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.107] (helo=sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FOIo0-0003RL-CC
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 18:20:36 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2SIKRYl025392;
	Tue, 28 Mar 2006 10:20:27 -0800 (PST)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <HRTBR4QX>; Tue, 28 Mar 2006 10:20:28 -0800
Message-ID: <789E617C880666438EDEE30C2A3E8D10ED9D@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
        "'shane_kerr@isc.org'"
	 <shane_kerr@isc.org>,
        "'Andy Bierman'" <ietf@andybierman.com>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: RE: Real Notification Requirements
Date: Tue, 28 Mar 2006 10:20:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a

Hi,

All of which was supposed to be an answer to an off-list
question of Shane's - sorry about that.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: McDonald, Ira 
> Sent: Tuesday, March 28, 2006 1:19 PM
> To: 'shane_kerr@isc.org'; Andy Bierman
> Cc: Netconf (E-mail)
> Subject: RE: Real Notification Requirements
> 
> 
> Hi Shane,
> 
> A partial, informal list of current, widely-deployed network
> element configuration protocols:
> 
> - IETF SNMP over TCP, UDP, ISO TP4, NetWare, AppleTalk, etc.
> - ISO CMIP over TCP, ISO TP4, etc.
> - DMTF DMI over TCP - DMI MIFs for IETF and vendor MIBs
> - DMTF WBEM over HTTP - XML schema for DMTF CIM MOFs
> - Oasis WSDM over SOAP - XML schema for WS-Resource* framework
> - DMTF WS-Management over SOAP - XML schema for WS-Resource*
> 
> DMTF and Oasis have a formal alliance to convert all CIM XML
> schema into the WS-Resource* framework for use with WSDM.
> 
> WSDM and WS-Management have just issued a historic convergence
> white paper that shows how they'll add new higher level classes
> to allow a single application data model and harmonize the
> resource, transfer, notifications, and subscriptions elements:
> 
>   
> http://www-128.ibm.com/developerworks/webservices/library/spec
ification/ws-roadmap/ 
> 
>   http://devresource.hp.com/drc/specifications/wsm/index.jsp
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org]On
> > Behalf Of Shane Kerr
> > Sent: Tuesday, March 28, 2006 10:02 AM
> > To: Andy Bierman
> > Cc: Netconf (E-mail)
> > Subject: Re: Real Notification Requirements
> > 
> > 
> > Andy Bierman wrote:
> > > Hi,
> > > 
> > > This new thread is for people to articulate use cases
> > > to support functional requirement requests.
> > > Translation: What is the developer or operator doing now, and
> > > how will it change to something great and wonderful because
> > > of this new feature?
> > > 
> > > Let's try some top-down design, since ad-hoc design isn't
> > > going so well.
> > > 
> > > I believe there is consensus so far for 2 uses of notifications
> > > in the NETCONF protocol:
> > > 
> > > 
> > > Content Layer Requirements
> > > --------------------------
> > > 
> > > C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
> > > 
> > > C2) NETCONF configuration change notification
> > > 
> > > C3) ???
> > 
> > I had a quick look at draft-ietf-syslog-protocol-16, and was 
> > interested
> > to see it supports structured data in addition to traditional syslog
> > free-form text. It also has a way for vendors to specify their own
> > structured data identifiers, and several standard ones 
> > defined already.
> > 
> > I wonder what the key differences are between the SYSLOG stuff and
> > anything within the NETCONF notification. Perhaps:
> > 
> > - XML (of course)
> > - Registration vs. complete log feed
> > 
> > Is there anything else?
> > 
> > Perhaps it would be better to focus on adding a 
> subscription mechanism
> > to SYSLOG?
> > 
> > --
> > Shane
> > 
> > --
> > 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/>
> > 
> > -- 
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.385 / Virus Database: 268.3.2/294 - Release 
> > Date: 3/27/2006
> >  
> > 
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.2/294 - Release 
> Date: 3/27/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.2/294 - Release Date: 3/27/2006
 

--
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 Mar 28 14:55:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOKHN-0001Kv-Dy
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:55:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOKHL-0003pM-UA
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:55:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOKDV-000AOr-IV
	for netconf-data@psg.com; Tue, 28 Mar 2006 19:51:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,RCVD_IN_SORBS_WEB autolearn=no version=3.1.1
Received: from [62.241.162.32] (helo=ranger.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1FOKDU-000AOb-BI
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 19:51:00 +0000
Received: from pc6 (1Cust129.tnt105.lnd4.gbr.da.uu.net [213.116.58.129])
	by ranger.systems.pipex.net (Postfix) with SMTP id 8946EE00023E;
	Tue, 28 Mar 2006 20:50:50 +0100 (BST)
Message-ID: <036101c65298$4487e0a0$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <44280952.40002@andybierman.com>
Subject: Re: Real Notification Requirements
Date: Tue, 28 Mar 2006 20:12:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

Plugging in a new blade.  Most of the network boxes I deal with are chassis with
hot-pluggable blades.  When  a new blade is plugged in, or an old one removed,
then I want a notfication so that the other party has a chance to amend the
configuration.

Tom Petch



----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Monday, March 27, 2006 5:48 PM
Subject: Real Notification Requirements


> Hi,
>
> This new thread is for people to articulate use cases
> to support functional requirement requests.
>
> Translation: What is the developer or operator doing now, and
> how will it change to something great and wonderful because
> of this new feature?
>
> Let's try some top-down design, since ad-hoc design isn't
> going so well.
>
> I believe there is consensus so far for 2 uses of notifications
> in the NETCONF protocol:
>
>
> Content Layer Requirements
> --------------------------
>
> C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
>
> C2) NETCONF configuration change notification
>
> C3) ???
>
> Andy


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



From owner-netconf@ops.ietf.org Tue Mar 28 14:55:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOKHX-0001R1-U1
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:55:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOKHW-0003qE-KU
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:55:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOKDY-000APH-9e
	for netconf-data@psg.com; Tue, 28 Mar 2006 19:51:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,RCVD_IN_SORBS_WEB autolearn=no version=3.1.1
Received: from [62.241.162.32] (helo=ranger.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1FOKDX-000AP3-Om
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 19:51:03 +0000
Received: from pc6 (1Cust129.tnt105.lnd4.gbr.da.uu.net [213.116.58.129])
	by ranger.systems.pipex.net (Postfix) with SMTP id 2498AE00038A;
	Tue, 28 Mar 2006 20:50:58 +0100 (BST)
Message-ID: <036201c65298$45946ea0$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
	"Andy Bierman" <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3E88@is0004avexu1.global.avaya.com>
Subject: Re: no interim meeting -- read the rules
Date: Tue, 28 Mar 2006 20:48:05 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa


----- Original Message -----
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>; "Netconf (E-mail)"
<netconf@ops.ietf.org>
Sent: Tuesday, March 28, 2006 7:22 PM
Subject: RE: no interim meeting -- read the rules


Right. We seem to need:
- comments on the current draft
- a requirements for notifications in NETCONF contribution - desired in
Internet-Draft format
- contributions for other solutions

A dialog with the syslog community also could be useful.

Dan

I do follow syslog.  The WG now has a new charter to produce
TLS based security - 'that is what the industry uses' - by November 2006 but, as
I have commented here before, participation is thin and I am not over confident
that the objectives will be met.  And anyone familiar with MIB modules -
probably
not many on this list:-) - could look at the MIB I-D, which is required by IESG,
and judge how much effort is still needed.

Tom Petch


Then we can discuss what form of meetings we need. I will do my best to
help (AD hat on). Rules must help the process while keeping it fair. For
example the rules seem to allow to have an interim meeting immediately
after the IETF supplementary to the usual meeting during the IETF. But
we need to have rough consensus that this would be helpful.

Regards,

Dan



--
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 Mar 28 14:58:14 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOKKU-0003rM-90
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:58:14 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOKKT-0004Ed-PB
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 14:58:14 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOKHP-000Al8-WE
	for netconf-data@psg.com; Tue, 28 Mar 2006 19:55:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [12.129.211.51] (helo=usaga01-in.huawei.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dharrington@huawei.com>)
	id 1FOIsv-0003zx-4o
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 18:25:41 +0000
Received: from huawei.com (usaga01-in [172.18.4.6])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0IWU00M04ODI5E@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 10:22:30 -0800 (PST)
Received: from Harrington73653 ([10.124.8.206])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0IWU001UTODG5A@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 10:22:30 -0800 (PST)
Date: Tue, 28 Mar 2006 12:25:39 -0600
From: David Harrington <dharrington@huawei.com>
Subject: Why are we doing netconf?
In-reply-to:
 <AAB4B3D3CF0F454F98272CBE187FDE2F0A3F3957@is0004avexu1.global.avaya.com>
To: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Message-id: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d

Hi,

I would like a better understasnding of why we are doing
notifications. I am struck by what appears to me to be two very
different drivers for netconf, and the "why are we doing
notifications?" question relates to these different motivations.

I have suggested that the O&M and Security communities should work at
establishing a strategic vision about converging aspects of the
various NM protocols and NM security solutions. If this is a path
worth taking, it should be a deliberate decision to do so because
there are some real problems associated with a convergence approach.

For this reason, I would like to understand what we are trying to
achieve with netconf and the current proposal for notifications, to
determine if the goals are compatible.

If the purpose of netconf is to provide a machine-friendly,
standardized protocol to eliminate the need for screen scraping CLI
expect scripts, I am not convinced we need notifications in the
netconf protocol. I think the netconf WG has done a reasonably good
job of standardizing the operations, but to achieve the goals, we also
need to improve the parseability of the data that now needs to be
screen scraped. The parseability of the data contained in the
responses coming back must be addressed. If vendors simply take their
existing screens of data and surround them with <cli></cli> tags, then
I think we've failed to eliminate the screen-scraping problem, and
other problems identified by operators at the IAB NM workshop:

   -  Some command line interfaces lack a common data model.  It is
very
      well possible that the same command on different devices, even
      from the same vendor, behaves differently.

   -  The command line interface is primarily targeted to humans which
      can adapt to minor syntax and format changes easily.  Using
      command line interfaces as a programmatic interface is
troublesome
      because of parsing complexities.

   -  Command line interfaces often lack proper version control for
the
      syntax and the semantics.  It is therefore time consuming and
      error prone to maintain programs or scripts that interface with
      different versions of a command line interface.

   -  Since command line interfaces are proprietary, they can not be
      used efficiently to automate processes in an environment with a
      heterogenous set of devices.

   -  The access control facilities, if present at all, are often
ad-hoc
      and sometimes insufficient.

Netconf does not seem to resolve these operational disadvantages of
the CLI, and notifications aren't even mentioned as a problem to be
solved.

If the purpose of netconf is to standardzie existing practice, and
existing practice is defined as screen scraping CLI expect scripts
plus syslog notifications, then I question whether we need to include
syslog notifications in netconf; syslog works well in its special
niche, and really doesn't need to be added to netconf.

The Syslog (-security) WG has been working to standardize the message
header format. The syslog community has not reached consensus on the
need to standard message content, except to add a structured data
component. The WG had difficulty even reaching agreement on
standardizing their message header format beyond starting the message
with <PRI>. I do not believe that netconf would be more successful at
standardizing syslog content than the syslog community, so I do not
believe that standardizing syslog message content should be a
justification for adding notifications to netconf, without a long
discussion about the feasibility of accomplishing this goal. I think
the standardization of syslog belongs in a (O&M) syslog WG, not the
netconf WG (and not the syslog security WG).

If the purpose of netconf is to assimilate the functionality of older
protocols like syslog and SNMP - to integrate them into a collective
netconf structure, and to eventually replace the old protocols with a
new general purpose management protocol minus the known problems, then
netconf has a higher bar to meet in its design requirements than have
been acknowledged. SNMPv3 is complex because it needed to deal with
security issues and troubleshooting requirements and other things;
syslog does not have a standard content format because there are a
wide number of vendors protecting their space, and the demand for
backwards compatibility to all or most existing header formats has
prevented progress in the syslog (security) WG. Faced with
requirements comparable to those faced by the older protocols during
their design, I expect netconf would fail to assimilate them properly.
Therefore, if the purpose of netconf is to be a general purpose NM
protocol, we need to have a serious discussion about the requirements
that must be met to achieve successful assimilation.

I find the existing proposal has plans to assimilate other protocols -
"The purpose of this [syslog-to-netconf] mapping is to provide an
unambiguous mapping to enable consistent multi-protocol
implementations as well as to enable future migration." and to attempt
to standardize that which the syslog community has failed to
standardize - "The intent is to promote the use of the NETCONF
interface and not to simply provide a wrapper and additional delivery
mechanism for syslog messages.  NETCONF events are intended to be well
defined and structured, therefore providing an advantage over the
unstructured and often times arbitrarily defined syslog messages (i.e.
the message field)."

I am a strong supporter of judicious reuse of NM and security
solutions across NM interfaces, but I believe apparent convergence
opportunities need to be discussed and for  each convergence we need
to consider the requirements met by each protocol and whether a
converged solution continues to meet those requirements or
deliberately does not meet some requirements.

I am bothered by the fact that netconf, a configuration protocol, is
being redesigned in the current proposal to carry syslog messages that
may have nothing to do with configuration, and it is expected that
even more stuff, also possibly not related to configuration, will be
carried in a new event message format. Operators at the IAB Network
Management Workshop apparently did not find syslog sufficiently broken
to request that a new event messaging capability be designed, so I
have concerns that the current proposal includes a brand-new
notification solution.

If netconf will become the new general purpose mgmt protocol for the
IETF, we should do this deliberately, not as a side-effect of adding a
notification operation to netconf.

David Harrington
FutureWei Technologies, a Huawei company
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Monday, March 27, 2006 5:20 AM
> To: Andy Bierman
> Cc: Netconf (E-mail)
> Subject: RE: Interim attendance survey
> 
> [...] I am aware that this good shape is
> apparent, and there is little agreement on the problem space, and
too
> little review of the draft that includes a proposed solution even to
> determine the level of agreement. I would encourage the WG to focus
on
> discussing the problem space (why are we doing notifications?) and
the
> draft and other options for solutions more intensively on the 
> list. Let
> us see in the next couple of weeks if we can reach more convergence
on
> the 'why' and 'how' questions. 
> 
> If we do have contributions about the scope and reviews of 
> the draft and
> solutions on the list we have a chance to better converge and reach
> agreement. If the level of apathy stays the same, I am not sure that
a
> partially attended interim meeting would help. 
> 





--
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 Mar 28 17:16:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOMTz-0002AU-Sc
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 17:16:11 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOMTz-00019w-8X
	for netconf-archive@lists.ietf.org; Tue, 28 Mar 2006 17:16:11 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOMPJ-000IUx-ED
	for netconf-data@psg.com; Tue, 28 Mar 2006 22:11:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOMPH-000IUc-N2
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 22:11:20 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2SMBHQ3024348
	for <netconf@ops.ietf.org>; Tue, 28 Mar 2006 17:11:18 -0500
Received: (qmail 32530 invoked by uid 78); 28 Mar 2006 22:11:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 28 Mar 2006 22:11:17 -0000
Message-ID: <4429B482.3010908@andybierman.com>
Date: Tue, 28 Mar 2006 14:11:14 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: David Harrington <dharrington@huawei.com>
CC: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
References: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
In-Reply-To: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121

David Harrington wrote:
> Hi,
> 
> I would like a better understasnding of why we are doing
> notifications. I am struck by what appears to me to be two very
> different drivers for netconf, and the "why are we doing
> notifications?" question relates to these different motivations.
> 
> I have suggested that the O&M and Security communities should work at
> establishing a strategic vision about converging aspects of the
> various NM protocols and NM security solutions. If this is a path
> worth taking, it should be a deliberate decision to do so because
> there are some real problems associated with a convergence approach.
> 
> For this reason, I would like to understand what we are trying to
> achieve with netconf and the current proposal for notifications, to
> determine if the goals are compatible.
> 
> If the purpose of netconf is to provide a machine-friendly,
> standardized protocol to eliminate the need for screen scraping CLI
> expect scripts, I am not convinced we need notifications in the
> netconf protocol. I think the netconf WG has done a reasonably good
> job of standardizing the operations, but to achieve the goals, we also
> need to improve the parseability of the data that now needs to be
> screen scraped. The parseability of the data contained in the
> responses coming back must be addressed. If vendors simply take their
> existing screens of data and surround them with <cli></cli> tags, then
> I think we've failed to eliminate the screen-scraping problem, and
> other problems identified by operators at the IAB NM workshop:
> 
>    -  Some command line interfaces lack a common data model.  It is
> very
>       well possible that the same command on different devices, even
>       from the same vendor, behaves differently.
> 
>    -  The command line interface is primarily targeted to humans which
>       can adapt to minor syntax and format changes easily.  Using
>       command line interfaces as a programmatic interface is
> troublesome
>       because of parsing complexities.
> 
>    -  Command line interfaces often lack proper version control for
> the
>       syntax and the semantics.  It is therefore time consuming and
>       error prone to maintain programs or scripts that interface with
>       different versions of a command line interface.
> 
>    -  Since command line interfaces are proprietary, they can not be
>       used efficiently to automate processes in an environment with a
>       heterogenous set of devices.
> 
>    -  The access control facilities, if present at all, are often
> ad-hoc
>       and sometimes insufficient.
> 
> Netconf does not seem to resolve these operational disadvantages of
> the CLI, and notifications aren't even mentioned as a problem to be
> solved.


Why not?
Because there are no standard data models yet?
The RFCs haven't even been published, so it's a bit early
to declare standard data modeling dead.


I am thrilled that so many implementations are under way
for a not-yet-published, no-port-assigned-yet protocol.
I want these implementations to continue, get deployed,
and then start with the enhancements.

The <cli> data model you mention is a natural evolutionary
step in the replacement of screen-scraping.  It provides
a way to get the protocol and error handling in place,
without giving up functionality.

This is the "wide and shallow" vs. "narrow and deep"
data model debate.  The reason every replacement
for the CLI that has been attempted has failed is
that they all attempt to deploy 1 or 2 "perfect" data models,
but most operators are not willing to use the CLI for
10000 commands and the fancy GUI for 20 more.

Although <cli> as a data model provides no depth whatsoever,
it provides 100% coverage of the CLI, plus structured error
codes, and maybe more.  Once this is in place, you can
start adding deep models for specific applications you
need to support.


> 
> If the purpose of netconf is to standardzie existing practice, and
> existing practice is defined as screen scraping CLI expect scripts
> plus syslog notifications, then I question whether we need to include
> syslog notifications in netconf; syslog works well in its special
> niche, and really doesn't need to be added to netconf.
> 
> The Syslog (-security) WG has been working to standardize the message
> header format. The syslog community has not reached consensus on the
> need to standard message content, except to add a structured data
> component. The WG had difficulty even reaching agreement on
> standardizing their message header format beyond starting the message
> with <PRI>. I do not believe that netconf would be more successful at
> standardizing syslog content than the syslog community, so I do not
> believe that standardizing syslog message content should be a
> justification for adding notifications to netconf, without a long
> discussion about the feasibility of accomplishing this goal. I think
> the standardization of syslog belongs in a (O&M) syslog WG, not the
> netconf WG (and not the syslog security WG).
> 
> If the purpose of netconf is to assimilate the functionality of older
> protocols like syslog and SNMP - to integrate them into a collective
> netconf structure, and to eventually replace the old protocols with a
> new general purpose management protocol minus the known problems, then
> netconf has a higher bar to meet in its design requirements than have
> been acknowledged. SNMPv3 is complex because it needed to deal with
> security issues and troubleshooting requirements and other things;
> syslog does not have a standard content format because there are a
> wide number of vendors protecting their space, and the demand for
> backwards compatibility to all or most existing header formats has
> prevented progress in the syslog (security) WG. Faced with
> requirements comparable to those faced by the older protocols during
> their design, I expect netconf would fail to assimilate them properly.
> Therefore, if the purpose of netconf is to be a general purpose NM
> protocol, we need to have a serious discussion about the requirements
> that must be met to achieve successful assimilation.
> 
> I find the existing proposal has plans to assimilate other protocols -
> "The purpose of this [syslog-to-netconf] mapping is to provide an
> unambiguous mapping to enable consistent multi-protocol
> implementations as well as to enable future migration." and to attempt
> to standardize that which the syslog community has failed to
> standardize - "The intent is to promote the use of the NETCONF
> interface and not to simply provide a wrapper and additional delivery
> mechanism for syslog messages.  NETCONF events are intended to be well
> defined and structured, therefore providing an advantage over the
> unstructured and often times arbitrarily defined syslog messages (i.e.
> the message field)."
> 
> I am a strong supporter of judicious reuse of NM and security
> solutions across NM interfaces, but I believe apparent convergence
> opportunities need to be discussed and for  each convergence we need
> to consider the requirements met by each protocol and whether a
> converged solution continues to meet those requirements or
> deliberately does not meet some requirements.
> 
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that
> even more stuff, also possibly not related to configuration, will be
> carried in a new event message format. Operators at the IAB Network
> Management Workshop apparently did not find syslog sufficiently broken
> to request that a new event messaging capability be designed, so I
> have concerns that the current proposal includes a brand-new
> notification solution.
> 
> If netconf will become the new general purpose mgmt protocol for the
> IETF, we should do this deliberately, not as a side-effect of adding a
> notification operation to netconf.


I agree with these last 2 paragraphs a lot.
It occurred to me when I saw an event type
for "performance metrics" notifications that
we might not all be on the same page wrt/
what netconf notifications are needed for.

I know that throughout design meetings from Day One,
only 3 notification types related to configuration came up:

   - config-change: some part of the <running> configuration changed
   - device-change: some part of the managed device changed
     (e.g., card swap)
   - direct usage of RFC 3195 (syslog over beep)

I also think that if the content of syslog is to
be standardized, that the syslog WG should do it, not netconf.
I was comfortable with throwing a beep channel for syslog
into netconf, but not standardizing an XML-based replacement
for syslog content.  I am going to ask the ADs
to "move it or lose it" wrt/ syslog content in netconf.

Since our charter says we are doing network configuration,
not a syslog replacement or an snmp replacement, I would
rather work on that.  That's what I thought I was signing
up for as co-Chair in fact.

There are lots of unsolved problems in the NM world.
If we run off trying to solve everybody else's problems,
who is going to actually work on network configuration?




> 
> David Harrington
> FutureWei Technologies, a Huawei company
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net

Andy

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



From owner-netconf@ops.ietf.org Wed Mar 29 03:10:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOVlU-00014Z-RM
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:10:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOVlS-0007vT-5D
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:10:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOVZ5-000MMY-K6
	for netconf-data@psg.com; Wed, 29 Mar 2006 07:58:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOVZ3-000MMF-Tr
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 07:58:02 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C322BDD;
	Wed, 29 Mar 2006 09:57:56 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 09:57:55 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 09:57:55 +0200
Message-ID: <442A3E03.3000006@ericsson.com>
Date: Wed, 29 Mar 2006 09:57:55 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: no interim meeting -- read the rules
References: <44296CBC.1070606@andybierman.com>
In-Reply-To: <44296CBC.1070606@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2006 07:57:55.0401 (UTC) FILETIME=[7CB87390:01C65306]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Hi,
For us notifications are needed mostly not as a logging mechanism but as:
- a way to notify about configuration changes
- a way to notify the management system about delayed results of an RPC (e.g. when an RPC 
initiated action takes 10 minutes to complete we send an immediate reply <started> and a 
late reply <finished>)
- to notify the network management system (NMS) about things that might need operator 
action. (While alarm handling is mostly SNMP there is a need for some other events to be 
handled by the NMS.)


For these reasons we do need a notification mechanism. We could use
- SNMP: but if we have an XML based hierarchical data model with meaningful names using 
SNMP is not my choice.
- Syslog: but the message size limit of less then 480 octets seems a problem. Also I like 
subscription. Adding XML to syslog needs some work. We have to care about a second 
transport/security mechanism TLS (I don't know if this is a real problem).
- Netconf-notifications: This would mean a somewhat unified structure within Netconf. 
Using our XML-based hierarchical data model would be natural.

regards Balazs

Andy Bierman wrote:
> As Dan and Dave H. pointed out, we need to agree on what
> we are doing and why we are doing it.  Several people
> have told me (and mentioned on the list) that they
> don't understand why we are reinventing syslog instead
> of working on network configuration.
> 
> So let's write down all the reasons why we need notifications
> in NETCONF, and why using or extending existing standards
> instead won't work.
  >
> Andy

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



From owner-netconf@ops.ietf.org Wed Mar 29 03:48:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOWMK-0006Ae-Hi
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:48:56 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOWMI-0001D8-7i
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:48:56 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOWHY-000Oxf-RL
	for netconf-data@psg.com; Wed, 29 Mar 2006 08:44:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [12.129.211.51] (helo=usaga01-in.huawei.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dharrington@huawei.com>)
	id 1FOLt9-000Gtr-Ds
	for netconf@ops.ietf.org; Tue, 28 Mar 2006 21:38:07 +0000
Received: from huawei.com (usaga01-in [172.18.4.6])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0IWU0034WXA8GR@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 13:34:56 -0800 (PST)
Received: from Harrington73653 ([10.124.8.206])
 by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0IWU0017NXA755@usaga01-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 28 Mar 2006 13:34:56 -0800 (PST)
Date: Tue, 28 Mar 2006 15:38:05 -0600
From: David Harrington <dharrington@huawei.com>
Subject: RE: Real Notification Requirements
In-reply-to: <036101c65298$4487e0a0$0601a8c0@pc6>
To: 'Tom Petch' <nwnetworks@dial.pipex.com>,
 'Andy Bierman' <ietf@andybierman.com>,
 "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Message-id: <012301c652af$e6634e20$e4087c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac

Hi,

I don't doubt the usefulness of notifications. That's why syslog and
snmp notifications are commonly available in devices.

I am not convinced we need to deliver the notifications via Netconf. 



> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Tom Petch
> Sent: Tuesday, March 28, 2006 12:12 PM
> To: Andy Bierman; Netconf (E-mail)
> Subject: Re: Real Notification Requirements
> 
> 
> Plugging in a new blade.  Most of the network boxes I deal 
> with are chassis with
> hot-pluggable blades.  When  a new blade is plugged in, or an 
> old one removed,
> then I want a notfication so that the other party has a 
> chance to amend the
> configuration.
> 
> Tom Petch
> 
> 
> 
> ----- Original Message -----
> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, March 27, 2006 5:48 PM
> Subject: Real Notification Requirements
> 
> 
> > Hi,
> >
> > This new thread is for people to articulate use cases
> > to support functional requirement requests.
> >
> > Translation: What is the developer or operator doing now, and
> > how will it change to something great and wonderful because
> > of this new feature?
> >
> > Let's try some top-down design, since ad-hoc design isn't
> > going so well.
> >
> > I believe there is consensus so far for 2 uses of notifications
> > in the NETCONF protocol:
> >
> >
> > Content Layer Requirements
> > --------------------------
> >
> > C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content
> >
> > C2) NETCONF configuration change notification
> >
> > C3) ???
> >
> > Andy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Wed Mar 29 03:53:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOWR6-00019u-8U
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:53:52 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOWR4-0001O7-NY
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 03:53:52 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOWLX-000PAs-P1
	for netconf-data@psg.com; Wed, 29 Mar 2006 08:48:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOWLW-000PAT-9k
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 08:48:06 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 86FDC55D8B;
	Wed, 29 Mar 2006 10:48:05 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 06250-04; Wed, 29 Mar 2006 10:48:03 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 9253755DBF;
	Wed, 29 Mar 2006 10:48:02 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 7126164EA06; Wed, 29 Mar 2006 10:48:01 +0200 (CEST)
Date: Wed, 29 Mar 2006 10:48:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: no interim meeting -- read the rules
Message-ID: <20060329084801.GC972@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <442A3E03.3000006@ericsson.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

On Wed, Mar 29, 2006 at 09:57:55AM +0200, Balazs Lengyel wrote:

> For us notifications are needed mostly not as a logging mechanism but as:
> - a way to notify about configuration changes
> - a way to notify the management system about delayed results of an RPC 
> (e.g. when an RPC initiated action takes 10 minutes to complete we send an 
> immediate reply <started> and a late reply <finished>)
> - to notify the network management system (NMS) about things that might 
> need operator action. (While alarm handling is mostly SNMP there is a need 
> for some other events to be handled by the NMS.)
> 
> 
> For these reasons we do need a notification mechanism. We could use
> - SNMP: but if we have an XML based hierarchical data model with meaningful 
> names using SNMP is not my choice.
> - Syslog: but the message size limit of less then 480 octets seems a 
> problem. Also I like subscription. Adding XML to syslog needs some work. We 
> have to care about a second transport/security mechanism TLS (I don't know 
> if this is a real problem).
> - Netconf-notifications: This would mean a somewhat unified structure 
> within Netconf. Using our XML-based hierarchical data model would be 
> natural.

This is useful input.

In order to avoid a formal requirements document, I suggest we simply
collect motivations and requirements in an easy and simple online
format in one place until we believe we have something we can agree
on. I am willing to play the editor for this. I created an initial
wiki page:

http://www.ietf.org/html.charters/netconf-charter.html

Please send additions and clarifications (lets try to do some work in
the mailing list ;-).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 04:19:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOWph-0000o1-6k
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 04:19:17 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOWpf-0003NT-TJ
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 04:19:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOWkW-0000oG-Ud
	for netconf-data@psg.com; Wed, 29 Mar 2006 09:13:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOWkW-0000o5-3A
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 09:13:56 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 684DF55DCC
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:13:55 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 08740-04; Wed, 29 Mar 2006 11:13:53 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 5DAA755D27;
	Wed, 29 Mar 2006 11:13:53 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 3F45664EB07; Wed, 29 Mar 2006 11:13:51 +0200 (CEST)
Date: Wed, 29 Mar 2006 11:13:51 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: notification motivation and requirements
Message-ID: <20060329091351.GC1181@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "Netconf (E-mail)" <netconf@ops.ietf.org>
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com> <20060329084801.GC972@boskop.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060329084801.GC972@boskop.local>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

On Wed, Mar 29, 2006 at 10:48:01AM +0200, Juergen Schoenwaelder wrote:
 
> In order to avoid a formal requirements document, I suggest we simply
> collect motivations and requirements in an easy and simple online
> format in one place until we believe we have something we can agree
> on. I am willing to play the editor for this. I created an initial
> wiki page:
> 
> http://www.ietf.org/html.charters/netconf-charter.html
> 
> Please send additions and clarifications (lets try to do some work in
> the mailing list ;-).

It seems people are actually reading my emails. So here is the correct
URL:

http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

I also have changed the subject just in case you feel you need to
reply to this message. :)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 05:17:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOXjo-0007r0-It
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 05:17:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOXjn-0005ie-9Y
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 05:17:16 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOXcI-0005lZ-Vu
	for netconf-data@psg.com; Wed, 29 Mar 2006 10:09:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [204.152.187.5] (helo=farside.isc.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <Shane_Kerr@isc.org>)
	id 1FOXcI-0005lN-1Y
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 10:09:30 +0000
Received: from [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b] (unknown [IPv6:2001:888:1936:2:216:6fff:fe49:7d9b])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id D24A1E6109;
	Wed, 29 Mar 2006 10:09:28 +0000 (UTC)
	(envelope-from shane@isc.org)
Message-ID: <442A5CD5.5060300@isc.org>
Date: Wed, 29 Mar 2006 12:09:25 +0200
From: Shane Kerr <Shane_Kerr@isc.org>
Reply-To:  shane_kerr@isc.org
Organization: ISC
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060312)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Harrington <dharrington@huawei.com>
CC: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
References: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
In-Reply-To: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Harrington wrote:
> I would like a better understasnding of why we are doing
> notifications. I am struck by what appears to me to be two very
> different drivers for netconf, and the "why are we doing
> notifications?" question relates to these different motivations.
<snip/>
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that
> even more stuff, also possibly not related to configuration, will be
> carried in a new event message format. Operators at the IAB Network
> Management Workshop apparently did not find syslog sufficiently broken
> to request that a new event messaging capability be designed, so I
> have concerns that the current proposal includes a brand-new
> notification solution.

It sounds like at least one person working on syslog thinks there is
value in a brand-new notification solution, and I believe him. :)

For me the first question is whether this should be done in NETCONF or
perhaps in a new working group. I don't know too much about it, but
since the scope seems very broad, I think maybe a new working group
makes sense, and NETCONF can declare victory.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEKlzVMsfZxBO4kbQRAoXnAKCq+uCpON+26e5F9D0bOC83dWZ+nACgwK6X
GXxRbQnZ82da2/yzTGuA2Mg=
=+eAm
-----END PGP SIGNATURE-----

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



From owner-netconf@ops.ietf.org Wed Mar 29 07:00:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOZLf-0008JC-Pe
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:00:27 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOZLe-0000e5-6z
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:00:27 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOZF4-000BkV-8W
	for netconf-data@psg.com; Wed, 29 Mar 2006 11:53:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <leinen@diotima.switch.ch>)
	id 1FOZF3-000BkG-5H
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 11:53:37 +0000
Received: from diotima.switch.ch (localhost [127.0.0.1])
	by diotima.switch.ch (8.13.5+Sun/8.13.5) with ESMTP id k2TBrXI9007206;
	Wed, 29 Mar 2006 13:53:33 +0200 (CEST)
Received: (from leinen@localhost)
	by diotima.switch.ch (8.13.5+Sun/8.13.5/Submit) id k2TBrWij007205;
	Wed, 29 Mar 2006 13:53:32 +0200 (CEST)
To: Andy Bierman <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Interim attendance survey
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: <4425A278.5000804@andybierman.com> (Andy Bierman's message of
 "Sat, 25 Mar 2006 12:05:12 -0800")
References: <4425A278.5000804@andybierman.com>
Date: Wed, 29 Mar 2006 13:53:32 +0200
Message-ID: <aad5g531s3.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
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

Sorry for the late response.

Andy Bierman writes:
> 1) I do not want the NETCONF notification work to continue
>    and I will not attend the interim meeting.

> 2) I want the NETCONF notification work to continue
>    but I will not be able to attend the interim meeting.

> 3) I want the NETCONF notification work to continue
>    and I will be able to attend some or all of the 3 day interim meeting.

Like DaveH, I'm not sure how much work on notifications we should do
*in NETCONF*; but I would attend an interim meeting.

> Possible location: Outside North America;
>                    (hopefully w/ non-stop flights from all over)
>                    (3 IETFs in a row in NA already)

We could offer a meeting room for up to ~30 people in the center of
Zurich.  Zurich still has many direct international flight
connections, including from Tokyo (not from San Francisco anymore,
sorry, but there's plenty of one-hop connections).

> Possible dates: 1 - 2 months before the Montreal IETF (May - June)

Fine with me except for 16-19 May.
-- 
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 Wed Mar 29 07:42:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOa0V-0006qO-IM
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:42:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOa0V-00029A-8s
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:42:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOZuk-000EL8-CB
	for netconf-data@psg.com; Wed, 29 Mar 2006 12:36:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	SPF_PASS autolearn=ham version=3.1.1
Received: from [85.10.201.79] (helo=hetzner.adiscon.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@hq.adiscon.com>)
	id 1FOZuh-000EKm-4W
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 12:36:39 +0000
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 491E127C066;
	Wed, 29 Mar 2006 13:41:45 +0200 (CEST)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 15925-09; Wed, 29 Mar 2006 13:41:45 +0200 (CEST)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 05EA027C061;
	Wed, 29 Mar 2006 13:41:44 +0200 (CEST)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 14:36:37 +0200
Subject: RE: no interim meeting -- read the rules
Date: Wed, 29 Mar 2006 14:36:33 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1743E3@grfint2.intern.adiscon.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-class: urn:content-classes:message
Thread-Topic: no interim meeting -- read the rules
X-MimeOLE: Produced By Microsoft Exchange V6.5
Thread-Index: AcZTCKX640u2VT3gTKK1pSOAuRaTBgAH5eKg
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>,
	"Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 29 Mar 2006 12:36:37.0328 (UTC) FILETIME=[6BC40500:01C6532D]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

> - Syslog: but the message size limit of less then 480 octets=20
> seems a problem. Also I like=20
> subscription. Adding XML to syslog needs some work. We have=20
> to care about a second=20
> transport/security mechanism TLS (I don't know if this is a=20
> real problem).

Just a clarification: the 480 octets is not the maximum allowed message
size per se. It is the size that a transport must support at a minimum.
It has to do with the difficult problems of error notification in broken
networks (where fragmentation shall be avoided). It is recommended that
all implementations support syslog messages up to 2k and it is allowed
to support larger messages. The transport mapping may set an upper limit
on the message, but only within the bounds outlined.

Anyhow, we tried to keep the header and structured data as small as
possible to leave enough room for actual message content in cases where
we are limited to 480 octets.

Syslog serves at least three purposes:

- alarm notification for system troubles
  (like link down, card plugged, ...)
  This is where the 480 octet limit is important.
- debugging messages (e.g. during setup and testing)
- status messages (e.g. traffic flow)

There is also a forth use-case that has nothing to do with NM:

- application level messages (e.g. IHE)

The 4th case has been intensively discussed. It is a major driver behind
larger message sizes (32+k). Purists say this is not something that
syslog should carry. Histriocans point to the fact that syslog started
as an app-level protocol for sendmail. Practicians (me included) say
that this is a currently widely deployed use case so it is valid by
virtue of that.

Rainer Gerhards

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



From owner-netconf@ops.ietf.org Wed Mar 29 07:48:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOa6H-0000fo-Nv
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:48:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOa6G-0002NO-0i
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 07:48:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOZzF-000EdJ-6Z
	for netconf-data@psg.com; Wed, 29 Mar 2006 12:41:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <simon@limmat.switch.ch>)
	id 1FOZzD-000Ed0-1E
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 12:41:19 +0000
Received: from diotima.switch.ch (localhost [127.0.0.1])
	by diotima.switch.ch (8.13.5+Sun/8.13.5) with ESMTP id k2TCfGgn007434;
	Wed, 29 Mar 2006 14:41:16 +0200 (CEST)
Message-ID: <17450.32876.369971.553053@diotima.switch.ch>
X-From-Line: procmail  Wed Mar 29 12:19:02 2006
X-Gnus-Mail-Source: directory:~/Mail/incoming/
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQ
X-OriginalArrivalTime: 29 Mar 2006 10:18:51.0911 (UTC) FILETIME=[2D317970:01C6531A]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-SWITCH-SIGNATURE: caffd2203b7cff438f6b1ae92ce0fc89
X-SWITCH-MailScanner: Found to be clean
X-SWITCH-SCANNER: scanned
Lines: 277
Xref: diotima.switch.ch lists.netman.netconf.owner:8376
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
Date: Wed, 29 Mar 2006 12:18:36 +0200
X-SWITCH-MailScanner-SpamCheck: spam, SpamAssassin (score=0.001, required 0,
	BAYES_50 0.00)
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e

Hi,=20

from the syslog guy's perspective:

*If* the primary motivation to include notifications is to replace
syslog, I think a shared effort with the syslog community would be
benefitial.

A root problem in syslog is the lack of interest. (Partly) following the
dicsussions on this list here, the same problem seems to resurface for
netconf notifications. I have come to the conclusion that too few
people/organizations have deep interest in system logging and that this
prevents (at least hinders) any serious effort to standardize an event
logging system (essentially, this is what snmp, syslog and eventually
netconf notifications is basically about).

With that said: the lack of a common data model is the primary problem
in syslog. I guess everybody here knows the negative effects of this
missing standardization. For another description, you might have a look
at my paper:

http://www.monitorware.com/en/workinprogress/nature-of-syslog-data.php

This primary problem has not been addressed so far. The syslog-sec WG
was not (and is not) able to do this, because message content is beyond
the charter. This is probably good, because the WG is progressing slowly
enough even with its limited charter. The only thing we "managed" (no
IDs are final, so we can't be sure we actually managed anything...) is
to include the STRUCTURED-DATA (SD) concept. SD is the primary extension
mechanism and hoped to be immensely useful when (if) it comes to content
standardization.

An effort to standardize a data model for logging messages would
definitely be useful, be it for syslog or netconf. I think such a model
must not necessarily be bound to a specific protocol. But there could
(must?) be different models for different use cases (e.g. traffic
reporting, firewalls, config changes, hardware failure reports...).
*This* would be immensely useful to the industry. If that standardized
event would be carried by syslog or netconf is actually of less interest
(at least in my point of view).

Please note that an important motivation for the current series of
syslog IDs was to make syslog transport-independent. You might want to
review a presentation of the early ideas:
   http://www.syslog.cc/ietf/presentat/syslog-protocol-03/index.html

It is partly outdated, but the transport-independence is still described
correctly. This slide is probably the most important one:
   http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img6.html

Given this design, syslog could use netconf as a transport. I know this
is different from what the current notification draft describes, but I
would like to mention it.

One way of integrating syslog and netconf could be that netconf
describes the data model and actions that are needed to

- set up a syslog subscription
- filter/specify the events to be sent
- cancel the syslog subscription
- *understand* the event message content

Once the subscription is setup, syslog messages could travel via RFC
3195(bis) or any other upcoming transport. This would also solve the
issue of an endless RPC, because the actual asynchronous notification
happens via a protocol that is designed to handle them. Plus, it would
solve the issue of the simplex syslog nature, allowing the syslog client
and server to exchange parameters via a separate netconf connection.

The problem with this approach is that it is somewhat like (non-passive)
FTP with a control and data connection. There are a lot of security
implications in this design.

If netconf does notifications, I think specifying a data model is the
top priority. It isn't sufficient to just deliver an event. Its content
and meaning must be understandable. If netconf just specifies a
transport, it will end up with another transmission mode for event
messages. I wouldn't see any advantage over current syslog in this case.

And: please do not underestimate the problems that come along with
insufficient interest in the topic. To limited review of IDs is an issue
I know very well from the syslog WG. If you read the syslog archives,
you will also find that there are few regulars. People come and go.
Depending on who's active when, design choices change. We have more than
once run in cycles just because active participants disappeared for a
while whereas past participants entered again. This caused a constant
shift in decision. It was the primary reason that the work, when thought
to be completed, was once again revamped and nearly put to a stop. It is
quite questionable if the syslog WG will succeed this year. If not, it
will be an official failure and no syslog RFC will appear (which of
course could be a motivation to do it in netconf). I doubt it is useful
to split ressources in an area where already very few people express
interest in.

Rainer Gerhards

> -----Original Message-----
> From:=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David Harrington
> Sent: Tuesday, March 28, 2006 8:26 PM
> To: 'Netconf (E-mail)'
> Subject: Why are we doing netconf?
>=20
> Hi,
>=20
> I would like a better understasnding of why we are doing
> notifications. I am struck by what appears to me to be two very
> different drivers for netconf, and the "why are we doing
> notifications?" question relates to these different motivations.
>=20
> I have suggested that the O&M and Security communities should work at
> establishing a strategic vision about converging aspects of the
> various NM protocols and NM security solutions. If this is a path
> worth taking, it should be a deliberate decision to do so because
> there are some real problems associated with a convergence approach.
>=20
> For this reason, I would like to understand what we are trying to
> achieve with netconf and the current proposal for notifications, to
> determine if the goals are compatible.
>=20
> If the purpose of netconf is to provide a machine-friendly,
> standardized protocol to eliminate the need for screen scraping CLI
> expect scripts, I am not convinced we need notifications in the
> netconf protocol. I think the netconf WG has done a reasonably good
> job of standardizing the operations, but to achieve the goals, we also
> need to improve the parseability of the data that now needs to be
> screen scraped. The parseability of the data contained in the
> responses coming back must be addressed. If vendors simply take their
> existing screens of data and surround them with <cli></cli> tags, then
> I think we've failed to eliminate the screen-scraping problem, and
> other problems identified by operators at the IAB NM workshop:
>=20
>    -  Some command line interfaces lack a common data model.  It is
> very
>       well possible that the same command on different devices, even
>       from the same vendor, behaves differently.
>=20
>    -  The command line interface is primarily targeted to humans which
>       can adapt to minor syntax and format changes easily.  Using
>       command line interfaces as a programmatic interface is
> troublesome
>       because of parsing complexities.
>=20
>    -  Command line interfaces often lack proper version control for
> the
>       syntax and the semantics.  It is therefore time consuming and
>       error prone to maintain programs or scripts that interface with
>       different versions of a command line interface.
>=20
>    -  Since command line interfaces are proprietary, they can not be
>       used efficiently to automate processes in an environment with a
>       heterogenous set of devices.
>=20
>    -  The access control facilities, if present at all, are often
> ad-hoc
>       and sometimes insufficient.
>=20
> Netconf does not seem to resolve these operational disadvantages of
> the CLI, and notifications aren't even mentioned as a problem to be
> solved.
>=20
> If the purpose of netconf is to standardzie existing practice, and
> existing practice is defined as screen scraping CLI expect scripts
> plus syslog notifications, then I question whether we need to include
> syslog notifications in netconf; syslog works well in its special
> niche, and really doesn't need to be added to netconf.
>=20
> The Syslog (-security) WG has been working to standardize the message
> header format. The syslog community has not reached consensus on the
> need to standard message content, except to add a structured data
> component. The WG had difficulty even reaching agreement on
> standardizing their message header format beyond starting the message
> with <PRI>. I do not believe that netconf would be more successful at
> standardizing syslog content than the syslog community, so I do not
> believe that standardizing syslog message content should be a
> justification for adding notifications to netconf, without a long
> discussion about the feasibility of accomplishing this goal. I think
> the standardization of syslog belongs in a (O&M) syslog WG, not the
> netconf WG (and not the syslog security WG).
>=20
> If the purpose of netconf is to assimilate the functionality of older
> protocols like syslog and SNMP - to integrate them into a collective
> netconf structure, and to eventually replace the old protocols with a
> new general purpose management protocol minus the known problems, then
> netconf has a higher bar to meet in its design requirements than have
> been acknowledged. SNMPv3 is complex because it needed to deal with
> security issues and troubleshooting requirements and other things;
> syslog does not have a standard content format because there are a
> wide number of vendors protecting their space, and the demand for
> backwards compatibility to all or most existing header formats has
> prevented progress in the syslog (security) WG. Faced with
> requirements comparable to those faced by the older protocols during
> their design, I expect netconf would fail to assimilate them properly.
> Therefore, if the purpose of netconf is to be a general purpose NM
> protocol, we need to have a serious discussion about the requirements
> that must be met to achieve successful assimilation.
>=20
> I find the existing proposal has plans to assimilate other protocols -
> "The purpose of this [syslog-to-netconf] mapping is to provide an
> unambiguous mapping to enable consistent multi-protocol
> implementations as well as to enable future migration." and to attempt
> to standardize that which the syslog community has failed to
> standardize - "The intent is to promote the use of the NETCONF
> interface and not to simply provide a wrapper and additional delivery
> mechanism for syslog messages.  NETCONF events are intended to be well
> defined and structured, therefore providing an advantage over the
> unstructured and often times arbitrarily defined syslog messages (i.e.
> the message field)."
>=20
> I am a strong supporter of judicious reuse of NM and security
> solutions across NM interfaces, but I believe apparent convergence
> opportunities need to be discussed and for  each convergence we need
> to consider the requirements met by each protocol and whether a
> converged solution continues to meet those requirements or
> deliberately does not meet some requirements.
>=20
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that
> even more stuff, also possibly not related to configuration, will be
> carried in a new event message format. Operators at the IAB Network
> Management Workshop apparently did not find syslog sufficiently broken
> to request that a new event messaging capability be designed, so I
> have concerns that the current proposal includes a brand-new
> notification solution.
>=20
> If netconf will become the new general purpose mgmt protocol for the
> IETF, we should do this deliberately, not as a side-effect of adding a
> notification operation to netconf.
>=20
> David Harrington
> FutureWei Technologies, a Huawei company
> dharrington@huawei.com=20
> dbharrington@comcast.net
> ietfdbh@comcast.net
>=20
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org=20
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
> > Sent: Monday, March 27, 2006 5:20 AM
> > To: Andy Bierman
> > Cc: Netconf (E-mail)
> > Subject: RE: Interim attendance survey
> >=20
> > [...] I am aware that this good shape is
> > apparent, and there is little agreement on the problem space, and
> too
> > little review of the draft that includes a proposed solution even to
> > determine the level of agreement. I would encourage the WG to focus
> on
> > discussing the problem space (why are we doing notifications?) and
> the
> > draft and other options for solutions more intensively on the=20
> > list. Let
> > us see in the next couple of weeks if we can reach more convergence
> on
> > the 'why' and 'how' questions.=20
> >=20
> > If we do have contributions about the scope and reviews of=20
> > the draft and
> > solutions on the list we have a chance to better converge and reach
> > agreement. If the level of apathy stays the same, I am not sure that
> a
> > partially attended interim meeting would help.=20
> >=20
>=20
>=20
>=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/>
>=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 Wed Mar 29 08:17:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOaYK-0002jw-7x
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:17:36 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOaYJ-0003nh-RW
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:17:36 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOaRy-000Giy-KF
	for netconf-data@psg.com; Wed, 29 Mar 2006 13:11:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <clonvick@cisco.com>)
	id 1FOaRy-000Gin-07
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 13:11:02 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-1.cisco.com with ESMTP; 29 Mar 2006 05:11:02 -0800
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TDB1w2028945;
	Wed, 29 Mar 2006 05:11:01 -0800 (PST)
Date: Wed, 29 Mar 2006 05:11:01 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: Andy Bierman <ietf@andybierman.com>
cc: David Harrington <dharrington@huawei.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
In-Reply-To: <4429B482.3010908@andybierman.com>
Message-ID: <Pine.GSO.4.63.0603281433440.11997@sjc-cde-011.cisco.com>
References: <011301c65295$03e40e00$e4087c0a@china.huawei.com>
 <4429B482.3010908@andybierman.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac

Hi,

I, too, have a concern about sending notification messages through 
netconf.

syslog is frequently the oldest piece of running code on many boxes. 
Since it works and is well understood by automated parsers, there is 
little impetus to change the log messages or the underlying protocol. 
That's a challenge that we knew about when we started the WG.

The BoFs and email threads from before the WG was formed showed that many 
people have strong opinions about how the format of a syslog message, 
including the payload, should be structured.  We figured that a WG would 
never come to consensus on that problem.  From that, the syslog WG was 
charterd in the security area to provide security mechanisms for the 
syslog protocol.  We tried working with the rather undefined header 
information but came to the conclusion that we couldn't provide a good set 
of documents without some work on standardizing the header fields.  That 
allowed us to add structured data (Rainer has described that).

When we started doing that, we also separatied the transports from the 
protocol.  The netconf WG could use that format within netconf if desired. 
This will allow the message format to be utilized within new secure 
transports as they are developed (e.g., dtls) without having to make 
changes to the message body.

If the netconf WG decides to provide notifications, we hope that the WG 
will consider the use of The syslog Protocol within whatever transports 
you decide upon.  I believe that the framework provided within The syslog 
Protocol will allow you to define message bodies as you see fit.


We are making progress on the current set of IDs within our new charter. 
We have:

For the basic protocol and transports

The syslog Protocol
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt

Transmission of syslog messages over UDP
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-06.txt
(this provides compatability with existing syslog/udp)

TLS Transport Mapping for SYSLOG
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-00.txt


We are still going to provide Signed syslog Messages
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-17.txt
as a way to ensure end-to-end security of the messages.  We are also going 
to provide a revision to RFC 3195 that supports The syslog Protocol 
(standardized headers, larger payload size, etc.).  The driver for 
revising RFC 3195 is that it is being implemented in the medical health 
industry and they do require larger payloads.


As far as the interest level goes, the IESG felt that there was enough 
support and interest to develop code to allow us to recharter.  I agree 
with that.

Thanks,
Chris





On Tue, 28 Mar 2006, Andy Bierman wrote:

> David Harrington wrote:
---remainder deleted for brevity---

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



From owner-netconf@ops.ietf.org Wed Mar 29 08:17:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOaYY-0002nn-7E
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:17:50 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOaYX-0003pp-II
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:17:50 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOaMs-000GLX-SP
	for netconf-data@psg.com; Wed, 29 Mar 2006 13:05:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOaMr-000GLA-2H
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 13:05:45 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2TD1Eu16284
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 08:01:14 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Wed, 29 Mar 2006 08:05:35 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40798F5F9@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSog7JG4Q4kVrMQe61wWIWQ7TahwAioHpQ
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 325b777e1a3a618c889460b612a65510

hi

Thanks Dave for the well-thought through post.

I think the 'restriction' on Netconf for configuration has always been
an artificial one, but it has served us well. One of the big problems we
ran into with SNMP was we kept picking off the easier problem of
monitoring and never giving configuration enough focus. By limiting the
focusing primarily on configuration for Netconf 1.0, we have ended up
with a great technical solution that is seeing some good market uptake.

I think actual implementations of Netconf are not limiting themselves to
just configuration. The CLI never did. For deployments, the high cost of
having to integrate information from different sources gets weighed
against the cost of having to replace legacy systems. Sometimes it wins.
Sometimes it doesn't. For the most part, all this can be done using the
existing framework. The gaps that people run into when trying to do this
are, I believe, the same ones they run into while trying to use Netconf
for configuration - access control, data model and notifications.
Another gap might be 'operational' commands such as rebooting and
maintenance, but the universal requirements there are not yet clear to
me.

I've personally been working both the data modeling and the notification
issue. I'd work access control, but other then a sense that I'd like
something simpler then we've seen in the past, I have no idea what we
would need. They are all important, both for configuration-only
implementations and configuration-plus ones.  I've focused more on the
notification work lately because I was getting a lot of pushback on the
data model work from certain people, but I'm willing to put time on that
topic again. I think though, that for people looking to be able to pick
up third-party Netconf stacks, there are some big advantages to being
able to standardize on any extended protocol operations sooner rather
then later.

As far as whether if we said from day one that netconf would do more
than configuration and things would have been designed differently, I
don't now if that is the case. As far as being forced to solve problems
at some point in the future related to performance management if we
don't somehow engineer/re-engineer the protocol so it can't be used for
things like that, I don't think that would be helpful.   At that day in
the future the community can decide whether it wants to spend time on
that particular problem. Plus, unless at that point in the future we
learned that they were not also using Netconf for configuration, this
would be a sign of success.

So, in summary, I think the current notification work absolutely is
necessary for configuration management. I don't see the value of
precluding its use for other functions and I believe for the other
functions all we need to do is provide the ability to specify the
correct event class. I'm also willing to work on the other gaps.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of David Harrington
Sent: Tuesday, March 28, 2006 1:26 PM
To: 'Netconf (E-mail)'
Subject: Why are we doing netconf?


Hi,

I would like a better understasnding of why we are doing notifications.
I am struck by what appears to me to be two very different drivers for
netconf, and the "why are we doing notifications?" question relates to
these different motivations.

I have suggested that the O&M and Security communities should work at
establishing a strategic vision about converging aspects of the various
NM protocols and NM security solutions. If this is a path worth taking,
it should be a deliberate decision to do so because there are some real
problems associated with a convergence approach.

For this reason, I would like to understand what we are trying to
achieve with netconf and the current proposal for notifications, to
determine if the goals are compatible.

If the purpose of netconf is to provide a machine-friendly, standardized
protocol to eliminate the need for screen scraping CLI expect scripts, I
am not convinced we need notifications in the netconf protocol. I think
the netconf WG has done a reasonably good job of standardizing the
operations, but to achieve the goals, we also need to improve the
parseability of the data that now needs to be screen scraped. The
parseability of the data contained in the responses coming back must be
addressed. If vendors simply take their existing screens of data and
surround them with <cli></cli> tags, then I think we've failed to
eliminate the screen-scraping problem, and other problems identified by
operators at the IAB NM workshop:

   -  Some command line interfaces lack a common data model.  It is very
      well possible that the same command on different devices, even
      from the same vendor, behaves differently.

   -  The command line interface is primarily targeted to humans which
      can adapt to minor syntax and format changes easily.  Using
      command line interfaces as a programmatic interface is troublesome
      because of parsing complexities.

   -  Command line interfaces often lack proper version control for the
      syntax and the semantics.  It is therefore time consuming and
      error prone to maintain programs or scripts that interface with
      different versions of a command line interface.

   -  Since command line interfaces are proprietary, they can not be
      used efficiently to automate processes in an environment with a
      heterogenous set of devices.

   -  The access control facilities, if present at all, are often ad-hoc
      and sometimes insufficient.

Netconf does not seem to resolve these operational disadvantages of the
CLI, and notifications aren't even mentioned as a problem to be solved.

If the purpose of netconf is to standardzie existing practice, and
existing practice is defined as screen scraping CLI expect scripts plus
syslog notifications, then I question whether we need to include syslog
notifications in netconf; syslog works well in its special niche, and
really doesn't need to be added to netconf.

The Syslog (-security) WG has been working to standardize the message
header format. The syslog community has not reached consensus on the
need to standard message content, except to add a structured data
component. The WG had difficulty even reaching agreement on
standardizing their message header format beyond starting the message
with <PRI>. I do not believe that netconf would be more successful at
standardizing syslog content than the syslog community, so I do not
believe that standardizing syslog message content should be a
justification for adding notifications to netconf, without a long
discussion about the feasibility of accomplishing this goal. I think the
standardization of syslog belongs in a (O&M) syslog WG, not the netconf
WG (and not the syslog security WG).

If the purpose of netconf is to assimilate the functionality of older
protocols like syslog and SNMP - to integrate them into a collective
netconf structure, and to eventually replace the old protocols with a
new general purpose management protocol minus the known problems, then
netconf has a higher bar to meet in its design requirements than have
been acknowledged. SNMPv3 is complex because it needed to deal with
security issues and troubleshooting requirements and other things;
syslog does not have a standard content format because there are a wide
number of vendors protecting their space, and the demand for backwards
compatibility to all or most existing header formats has prevented
progress in the syslog (security) WG. Faced with requirements comparable
to those faced by the older protocols during their design, I expect
netconf would fail to assimilate them properly. Therefore, if the
purpose of netconf is to be a general purpose NM protocol, we need to
have a serious discussion about the requirements that must be met to
achieve successful assimilation.

I find the existing proposal has plans to assimilate other protocols -
"The purpose of this [syslog-to-netconf] mapping is to provide an
unambiguous mapping to enable consistent multi-protocol implementations
as well as to enable future migration." and to attempt to standardize
that which the syslog community has failed to standardize - "The intent
is to promote the use of the NETCONF interface and not to simply provide
a wrapper and additional delivery mechanism for syslog messages.
NETCONF events are intended to be well defined and structured, therefore
providing an advantage over the unstructured and often times arbitrarily
defined syslog messages (i.e. the message field)."

I am a strong supporter of judicious reuse of NM and security solutions
across NM interfaces, but I believe apparent convergence opportunities
need to be discussed and for  each convergence we need to consider the
requirements met by each protocol and whether a converged solution
continues to meet those requirements or deliberately does not meet some
requirements.

I am bothered by the fact that netconf, a configuration protocol, is
being redesigned in the current proposal to carry syslog messages that
may have nothing to do with configuration, and it is expected that even
more stuff, also possibly not related to configuration, will be carried
in a new event message format. Operators at the IAB Network Management
Workshop apparently did not find syslog sufficiently broken to request
that a new event messaging capability be designed, so I have concerns
that the current proposal includes a brand-new notification solution.

If netconf will become the new general purpose mgmt protocol for the
IETF, we should do this deliberately, not as a side-effect of adding a
notification operation to netconf.

David Harrington
FutureWei Technologies, a Huawei company
dharrington@huawei.com=20
dbharrington@comcast.net
ietfdbh@comcast.net

> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Monday, March 27, 2006 5:20 AM
> To: Andy Bierman
> Cc: Netconf (E-mail)
> Subject: RE: Interim attendance survey
>=20
> [...] I am aware that this good shape is
> apparent, and there is little agreement on the problem space, and
too
> little review of the draft that includes a proposed solution even to=20
> determine the level of agreement. I would encourage the WG to focus
on
> discussing the problem space (why are we doing notifications?) and
the
> draft and other options for solutions more intensively on the
> list. Let
> us see in the next couple of weeks if we can reach more convergence
on
> the 'why' and 'how' questions.
>=20
> If we do have contributions about the scope and reviews of
> the draft and
> solutions on the list we have a chance to better converge and reach
> agreement. If the level of apathy stays the same, I am not sure that
a
> partially attended interim meeting would help.
>=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/>


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



From owner-netconf@ops.ietf.org Wed Mar 29 08:27:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOaiL-00021i-Th
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:27:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOaiK-0004NU-L8
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 08:27:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOadv-000HWO-Cg
	for netconf-data@psg.com; Wed, 29 Mar 2006 13:23:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOadu-000HW3-Jp
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 13:23:22 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2TDNIZ14790
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 08:23:18 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Wed, 29 Mar 2006 08:23:10 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40798F62F@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQAAe8XsA=
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

hi

<Rainer>

*If* the primary motivation to include notifications is to replace
syslog, I think a shared effort with the syslog community would be
benefitial.
</Rainer>

That isn't our primary motivation. It is just that some people feel that
some of the requirements can be met by this existing solution, which is
why it comes up.

Sharon

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



From owner-netconf@ops.ietf.org Wed Mar 29 09:21:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FObYN-0006v5-IY
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 09:21:43 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FObYM-0006ef-9A
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 09:21:43 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FObSv-000KbF-En
	for netconf-data@psg.com; Wed, 29 Mar 2006 14:16:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	SPF_PASS autolearn=ham version=3.1.1
Received: from [85.10.201.79] (helo=hetzner.adiscon.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@hq.adiscon.com>)
	id 1FObSu-000Kb4-NN
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 14:16:04 +0000
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 59F7F27C066;
	Wed, 29 Mar 2006 15:21:10 +0200 (CEST)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 24731-10; Wed, 29 Mar 2006 15:21:10 +0200 (CEST)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 06E9227C061;
	Wed, 29 Mar 2006 15:21:09 +0200 (CEST)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 16:16:02 +0200
Subject: RE: Why are we doing netconf?
Date: Wed, 29 Mar 2006 16:15:54 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1743F0@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQAAe8XsAAAW9QUA==
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Sharon Chisholm" <schishol@nortel.com>, <netconf@ops.ietf.org>
X-OriginalArrivalTime: 29 Mar 2006 14:16:02.0537 (UTC) FILETIME=[4F4EAD90:01C6533B]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

Sharon,=20

> <Rainer>
> *If* the primary motivation to include notifications is to replace
> syslog, I think a shared effort with the syslog community would be
> benefitial.
> </Rainer>
>=20
> That isn't our primary motivation. It is just that some=20
> people feel that
> some of the requirements can be met by this existing=20
> solution, which is
> why it comes up.

From following the list (but sometimes briefly), I have to admit that I
do not have a clear impression on what the primary motivation is and why
a separate event logging protocol is needed. I think it would help
immensely if there would be description of what is intended and why
syslog can not do the job. That would also help focus the document on
these topics. Besides, it might be easy to modify syslog to solve
issues...

I am aware that there is a requirements/motivation discussion. I think
this discussion is useful for the reasons outlined above.

Rainer

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



From owner-netconf@ops.ietf.org Wed Mar 29 09:53:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOc3b-0004Qw-8r
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 09:53:59 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOc3Y-00087O-OL
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 09:53:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FObzB-000Mc5-Uo
	for netconf-data@psg.com; Wed, 29 Mar 2006 14:49:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FObzA-000Mbr-ET
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 14:49:24 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id AC23855DFD
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 16:49:23 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 14029-05; Wed, 29 Mar 2006 16:49:22 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 1145255DCC;
	Wed, 29 Mar 2006 16:49:22 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id AF86D64F12C; Wed, 29 Mar 2006 16:49:19 +0200 (CEST)
Date: Wed, 29 Mar 2006 16:49:19 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: notification motivation and requirements
Message-ID: <20060329144919.GE486@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "Netconf (E-mail)" <netconf@ops.ietf.org>
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com> <20060329084801.GC972@boskop.local> <20060329091351.GC1181@boskop.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060329091351.GC1181@boskop.local>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

On Wed, Mar 29, 2006 at 11:13:51AM +0200, Juergen Schoenwaelder wrote:
 
> http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

If you want to add something to the motivation/requirements page,
please send email to the WG list and not to me directly. I will not
add something which is not posted as well to this list.

Consider myself a scribe who simply takes notes of the mailing list
discussion and the wiki page is simply my notepad that everyone can
see (and which tracks history).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 10:13:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOcM9-0007iw-Qs
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 10:13:09 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOcM9-0000bz-H4
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 10:13:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOcHt-000NjE-3Z
	for netconf-data@psg.com; Wed, 29 Mar 2006 15:08:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOcHs-000Nir-7i
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 15:08:44 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2TF4Du25615
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 10:04:14 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Wed, 29 Mar 2006 10:08:33 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40798F8E6@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQAAe8XsAAAW9QUAACEt/Q
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

Here are some of the requirements .=20

- Netconf content (without mapping )
- Filtering
- Subscription
- Event classification
- Structured content
- Predictable content
- reliable delivery (or ability to detect when things go wrong)
- event replay=20
- Ability to support different types of events (alarms, logs,
configuration snippets, etc)
- XML encoding (not a big driver, but certainly a major industry
direction)

The thing I struggle with in syslog is the well-deployed syslog versus
the new stuff we designed. I think some of the changes made recently to
add new features on top of legacy (or that is at least my
interpretation) will help compared to the original plan, but I worry
that if we change syslog too much we lose any benefits of using an
existing solution. We then end up with a new protocol that we still call
syslog for sentimental reasons, but not one that integrates well with
either legacy syslog or other management functions being supported by
solutions like Netconf.

The same applies to trying to modify SNMP to do this as well.=20

Sharon

-----Original Message-----
From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20
Sent: Wednesday, March 29, 2006 9:16 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
Subject: RE: Why are we doing netconf?


Sharon,=20

> <Rainer>
> *If* the primary motivation to include notifications is to replace=20
> syslog, I think a shared effort with the syslog community would be=20
> benefitial. </Rainer>
>=20
> That isn't our primary motivation. It is just that some
> people feel that
> some of the requirements can be met by this existing=20
> solution, which is
> why it comes up.

From following the list (but sometimes briefly), I have to admit that I
do not have a clear impression on what the primary motivation is and why
a separate event logging protocol is needed. I think it would help
immensely if there would be description of what is intended and why
syslog can not do the job. That would also help focus the document on
these topics. Besides, it might be easy to modify syslog to solve
issues...

I am aware that there is a requirements/motivation discussion. I think
this discussion is useful for the reasons outlined above.

Rainer


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



From owner-netconf@ops.ietf.org Wed Mar 29 11:16:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdLH-0006uB-N0
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:16:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdLH-00048V-8Q
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:16:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdGE-0001nO-DA
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:11:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOdGD-0001nA-G3
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:11:05 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2TG9oZq019379
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:09:55 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2TFsovS021984
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 10:54:50 -0500 (EST)
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: Why are we doing netconf?
Date: Wed, 29 Mar 2006 18:10:58 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BD93@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQAAe8XsAAAW9QUAACEt/QAAJTsCA=
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Sharon Chisholm" <schishol@nortel.com>, <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a

This may be a good list to start a discussion about Netconf
notifications, but are all these requirements at the same level of
priority? Maybe there is a sub-class of higher priority requirements
that can be met with a simpler protocol?=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, March 29, 2006 5:09 PM
> To: netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
>=20
> Here are some of the requirements .=20
>=20
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification
> - Structured content
> - Predictable content
> - reliable delivery (or ability to detect when things go wrong)
> - event replay
> - Ability to support different types of events (alarms, logs,=20
> configuration snippets, etc)
> - XML encoding (not a big driver, but certainly a major industry
> direction)
>=20
> The thing I struggle with in syslog is the well-deployed=20
> syslog versus the new stuff we designed. I think some of the=20
> changes made recently to add new features on top of legacy=20
> (or that is at least my
> interpretation) will help compared to the original plan, but=20
> I worry that if we change syslog too much we lose any=20
> benefits of using an existing solution. We then end up with a=20
> new protocol that we still call syslog for sentimental=20
> reasons, but not one that integrates well with either legacy=20
> syslog or other management functions being supported by=20
> solutions like Netconf.
>=20
> The same applies to trying to modify SNMP to do this as well.=20
>=20
> Sharon
>=20
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Wednesday, March 29, 2006 9:16 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
>=20
>=20
> Sharon,=20
>=20
> > <Rainer>
> > *If* the primary motivation to include notifications is to replace=20
> > syslog, I think a shared effort with the syslog community would be=20
> > benefitial. </Rainer>
> >=20
> > That isn't our primary motivation. It is just that some
> > people feel that
> > some of the requirements can be met by this existing=20
> > solution, which is
> > why it comes up.
>=20
> From following the list (but sometimes briefly), I have to=20
> admit that I
> do not have a clear impression on what the primary motivation=20
> is and why
> a separate event logging protocol is needed. I think it would help
> immensely if there would be description of what is intended and why
> syslog can not do the job. That would also help focus the document on
> these topics. Besides, it might be easy to modify syslog to solve
> issues...
>=20
> I am aware that there is a requirements/motivation discussion. I think
> this discussion is useful for the reasons outlined above.
>=20
> Rainer
>=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

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



From owner-netconf@ops.ietf.org Wed Mar 29 11:16:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdLa-0006w1-Rj
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:16:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdLZ-00048k-9L
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:16:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdEN-0001eK-UE
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:09:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOdEK-0001e5-Hu
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:09:08 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 95033668
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 18:09:07 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 18:09:06 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 29 Mar 2006 18:09:06 +0200
Message-ID: <442AB122.50502@ericsson.com>
Date: Wed, 29 Mar 2006 18:09:06 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: notification motivation and requirements
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com> <20060329084801.GC972@boskop.local> <20060329091351.GC1181@boskop.local> <20060329144919.GE486@boskop.local>
In-Reply-To: <20060329144919.GE486@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2006 16:09:06.0769 (UTC) FILETIME=[1B065410:01C6534B]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

I believe the possibility to have a reliable transport of notifications is also a 
requirement. (Not just simple UDP without acknowledgment.)

Balazs



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Wed Mar 29 11:19:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdNt-0001U2-3N
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:19:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdNs-0004ID-Pm
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:19:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdKE-000245-JD
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:15:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOdKD-00023t-Ur
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:15:14 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2TGDwMX025629
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:13:59 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2TFwve9022869
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 10:58:58 -0500 (EST)
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: Why are we doing netconf?
Date: Wed, 29 Mar 2006 18:15:06 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BD9F@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAclpMQAAe8XsAAAW9QUAAEiNsA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
        "Sharon Chisholm" <schishol@nortel.com>, <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Maybe this is part of the discussion suggested by Dave Harrington about
'a strategic vision about converging aspects of the various NM protocols
and NM security solutions' discussion that needs to be conducted by the
management and security communities altogether.=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Rainer Gerhards
> Sent: Wednesday, March 29, 2006 4:16 PM
> To: Sharon Chisholm; netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
>=20
> Sharon,=20
>=20
> > <Rainer>
> > *If* the primary motivation to include notifications is to replace=20
> > syslog, I think a shared effort with the syslog community would be=20
> > benefitial.
> > </Rainer>
> >=20
> > That isn't our primary motivation. It is just that some people feel=20
> > that some of the requirements can be met by this existing solution,=20
> > which is why it comes up.
>=20
> From following the list (but sometimes briefly), I have to=20
> admit that I do not have a clear impression on what the=20
> primary motivation is and why a separate event logging=20
> protocol is needed. I think it would help immensely if there=20
> would be description of what is intended and why syslog can=20
> not do the job. That would also help focus the document on=20
> these topics. Besides, it might be easy to modify syslog to=20
> solve issues...
>=20
> I am aware that there is a requirements/motivation=20
> discussion. I think this discussion is useful for the reasons=20
> outlined above.
>=20
> Rainer
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Wed Mar 29 11:24:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdTZ-00061z-Tp
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:24:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdTY-0004Tn-IH
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:24:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdP9-0002Up-4d
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:20:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOdP8-0002Ua-C7
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:20:18 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2TGIiUw014921
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:18:44 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2TGH7EV029215
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:17:07 -0500 (EST)
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: Why are we doing netconf?
Date: Wed, 29 Mar 2006 18:20:15 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BDAE@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSoZeEdbN42o2KTTqkvz9OAVTwDwAqluaA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "David Harrington" <dharrington@huawei.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d



=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David Harrington

>=20
> I have suggested that the O&M and Security communities should=20
> work at establishing a strategic vision about converging=20
> aspects of the various NM protocols and NM security=20
> solutions. If this is a path worth taking, it should be a=20
> deliberate decision to do so because there are some real=20
> problems associated with a convergence approach.
>=20

I sympathize with this kind of approach, but we also need to recognize
that this type of approach is ambitious, and speaks about a longer term
vision, which may take time to start and complete. I am reluctant to
declare a stop in all new protocol design and applicability statements
for existing protocol in management while waiting for that vision to
happen. I would say let us start preparing the strategic vision
discussion with at least a I-D to be discussed at the O&M Area Meeting
in Montreal. At the same time let us continue existing work that has
enough consensus and warm bodies to push for it - this will provide us
solutions in more contained spaces that will play as pieces in the
puzzle of the 'vision'.=20

Dan




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



From owner-netconf@ops.ietf.org Wed Mar 29 11:27:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdWZ-0008Qy-62
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:27:59 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdWX-0004ji-S8
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:27:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdSW-0002lV-Vl
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:23:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOdSV-0002lE-Tv
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:23:48 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 1D10055E07;
	Wed, 29 Mar 2006 18:23:47 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 24336-07; Wed, 29 Mar 2006 18:23:45 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 69DCF55DAF;
	Wed, 29 Mar 2006 18:23:45 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 090F064F36D; Wed, 29 Mar 2006 18:23:42 +0200 (CEST)
Date: Wed, 29 Mar 2006 18:23:42 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Sharon Chisholm <schishol@nortel.com>
Cc: netconf@ops.ietf.org
Subject: Re: Why are we doing netconf?
Message-ID: <20060329162342.GD773@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Sharon Chisholm <schishol@nortel.com>,
	netconf@ops.ietf.org
References: <713043CE8B8E1348AF3C546DBE02C1B40798F8E6@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40798F8E6@zcarhxm2.corp.nortel.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

On Wed, Mar 29, 2006 at 10:08:33AM -0500, Sharon Chisholm wrote:
> Here are some of the requirements . 
> 
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification

What are the classes you have in mind? Can you elaborate a bit more?

> - Structured content
> - Predictable content

What is predictable content?

> - reliable delivery (or ability to detect when things go wrong)
> - event replay

Why is that a requirement? What is this good for in operational
environments?

> - Ability to support different types of events (alarms, logs,
> configuration snippets, etc)

Is "configuration snippets" and event type? Is logs == syslog
messages?

> - XML encoding (not a big driver, but certainly a major industry
> direction)

If XML encoding is a requirement, is then not structured content
superfluous? Since netconf content is XML, is even the XML requirement
superfluous?

I am asking these questions simply because I want to understand what
people mean when they throw in some terms.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 11:30:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdYz-00042k-Bl
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:30:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOdYz-00055f-2O
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 11:30:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOdUv-00031S-Vh
	for netconf-data@psg.com; Wed, 29 Mar 2006 16:26:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOdUu-00031D-Sq
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 16:26:17 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2TGOhbS022541
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:24:43 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2TGN5di000350
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 11:23:06 -0500 (EST)
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: Why are we doing netconf?
Date: Wed, 29 Mar 2006 18:26:14 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BDC5@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSog7JG4Q4kVrMQe61wWIWQ7TahwAioHpQAAgKdIA=
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Sharon Chisholm" <schishol@nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa



=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, March 29, 2006 3:06 PM
> To: Netconf (E-mail)
> Subject: RE: Why are we doing netconf?
>=20
> hi
>=20
> Thanks Dave for the well-thought through post.
>=20
> I think the 'restriction' on Netconf for configuration has=20
> always been an artificial one, but it has served us well. One=20
> of the big problems we ran into with SNMP was we kept picking=20
> off the easier problem of monitoring and never giving=20
> configuration enough focus. By limiting the focusing=20
> primarily on configuration for Netconf 1.0, we have ended up=20
> with a great technical solution that is seeing some good=20
> market uptake.

It also was intended to meet the needs of the operators as they were
scanned by 2001-2002. They told us then that they can leave well with
the alarms and performance monitoring mechanisms in SNMP, but consider
configuration by SNMP a dead horse.=20

So maybe the solution that we are looking for is not necessarily one
protocol to fit all sizes, sorry - management functions but a framework
where different protocols meet different functions, maybe even more than
one per function according to costs vs. complexity, linked together by
one access and security model.=20

This is a contributor view, in an discussion where all views are allowed
in the hope that they will converge some time in the future.=20

Dan


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



From owner-netconf@ops.ietf.org Wed Mar 29 12:23:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOeOE-0003C3-9C
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 12:23:26 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOeOB-0007MH-Un
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 12:23:26 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOeIV-0006Iy-0v
	for netconf-data@psg.com; Wed, 29 Mar 2006 17:17:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOeIU-0006IG-1y
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 17:17:30 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2THHPv19966
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 12:17:25 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Wed, 29 Mar 2006 12:17:05 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4079FE443@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZTTSt5iS+aowMTQ9uVm/wLbfU7OQABcQ3A
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976

hi

<Juergen>

On Wed, Mar 29, 2006 at 10:08:33AM -0500, Sharon Chisholm wrote:
> Here are some of the requirements .
>=20
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification

What are the classes you have in mind? Can you elaborate a bit more?
</Juergen>

This is like the event class concept in the draft. The idea that we
define a set of big buckets that both allow intelligent filtering as
well serve as a predictor of the content of the notification. So,
examples are configuration, audit, security, etc.


<Juergen>
> - Structured content
> - Predictable content

What is predictable content?
</Juergen>

Predictable is that the consumer of the message based only on the
protocol definition and a definition of the data model associated with
the notification (XML Schema, for example) are able to predict what
information will be in the notification and how it will be formatted.

<Juergen>
> - reliable delivery (or ability to detect when things go wrong)
> - event replay

Why is that a requirement? What is this good for in operational
environments?
</Juergen>

I should mention that I consider event replay something we can add
later. We did not include it in the draft. Event replay is a mechanism
that allows you when you first start talking to a device to learn about
interesting events that have happened to it within the immediate past.
Ideally, this information will be in the same format as it would have
been if you had actually been there it hear it.

<Juergen>
> - Ability to support different types of events (alarms, logs,=20
> configuration snippets, etc)

Is "configuration snippets" and event type? Is logs =3D=3D syslog =
messages?
</Juergen>

A configuration snippet would be part of a configuration either as part
of an audit trial or a configuration mirroring thing. I think
configuration might be the actual event class. Logs could be the same
sort of information that is currently done in syslog, yes.=20

<Juergen>
> - XML encoding (not a big driver, but certainly a major industry
> direction)

If XML encoding is a requirement, is then not structured content
superfluous? Since netconf content is XML, is even the XML requirement
superfluous?
</Juergen>

Well, it is a way to do structured data, so perhaps it is a
sub-requirement? I listed them separately as a nod to that fact that
there are other ways to structure data but also to acknowledge the fact
that there are people who very much want XML explicitly.

Sharon

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



From owner-netconf@ops.ietf.org Wed Mar 29 12:35:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOeaI-0006bo-WA
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 12:35:55 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOeaH-0007jv-In
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 12:35:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOeSq-0006wv-JL
	for netconf-data@psg.com; Wed, 29 Mar 2006 17:28:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FOeSp-0006wk-Vg
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 17:28:12 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2THSBan010699
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 09:28:11 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2THSBR5010694
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 09:28:11 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 29 Mar 2006 09:28:11 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements 
Message-ID: <Pine.LNX.4.10.10603290922350.26409-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

HI,

Here are a couple to add to the list....

*) notifications to report unexpected consequences of
   a configuration change
*) notifications so that state changes can be followed
   due to configuration changes. (Background: some 
   configuration changes can result in destalization
   followed by transition through several states to
   the desired stable state. It is important to know
   the cause of a "service affecting event", and to
   know if the config change has resulted in a new
   stable and desired configuration. If not, then
   the config change, most likely, should be rolled
   back to the previous settings.) 

Regards,
/david t. perkins


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



From owner-netconf@ops.ietf.org Wed Mar 29 13:01:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOezW-0004VW-1n
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 13:01:58 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOezU-0000xp-Ot
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 13:01:58 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOevB-0008vn-OO
	for netconf-data@psg.com; Wed, 29 Mar 2006 17:57:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FOevB-0008vS-1N
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 17:57:29 +0000
Received: from sj-core-4.cisco.com ([171.68.223.138])
  by sj-iport-5.cisco.com with ESMTP; 29 Mar 2006 09:57:29 -0800
X-IronPort-AV: i="4.03,144,1141632000"; 
   d="scan'208"; a="265234257:sNHT32330322"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2THvSYg018637;
	Wed, 29 Mar 2006 09:57:28 -0800 (PST)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp47.cisco.com [10.61.64.47])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2THvwLj030915;
	Wed, 29 Mar 2006 09:57:58 -0800
Message-ID: <442ACA85.6040200@cisco.com>
Date: Wed, 29 Mar 2006 19:57:25 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BDC5@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BDC5@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=804; t=1143655079; x=1144087279;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20Why=20are=20we=20doing=20netconf?
	|To:=22Romascanu,=20Dan=20\(Dan\)=22=20<dromasca@avaya.com>;
	X=v=3Dmtcc.com=3B=20h=3DfHY3/nFpSKTKOVmh9Ue5bAxi7Lw=3D; b=lAkWioRWZLc7g4ullP7EQV/wLJXG70PyhrZwDMxJCpRlvRbn/3WgoFEfys38fYtgSHK4O3Ha
	6cpSSLeAXtn9Kdk85VtQvc3lx1sWpZo1tnDsbTEOMmfafraCR+MbN+EYYdVJGYyt3Qej+VJjnWr
	OmLaPWsV1Rlfl57EVBRFh+Zk=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Hi Dan,

> It also was intended to meet the needs of the operators as they were
> scanned by 2001-2002. They told us then that they can leave well with
> the alarms and performance monitoring mechanisms in SNMP, but consider
> configuration by SNMP a dead horse. 
>   

Actually, for fault management management and alarms some consider SNMP
a dead horse.  Most enterprises in particular prefer SYSLOG and ASCII. 
SPs say they like SNMP but then they use tools like Netcool/CIC, and so
SYSLOG does very well for them as well.  In the end I think we'd find
agreement between the two groups that standardized events should tail
differentiation.

I also think one of the reasons they considered SNMP a dead horse was
lousy integration with their existing AAA.  ISMS may help this.

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 Wed Mar 29 14:01:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOfvC-0000Ie-VB
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:01:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOfvB-00041l-Jh
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:01:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOfqn-000DAk-FF
	for netconf-data@psg.com; Wed, 29 Mar 2006 18:57:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOfqm-000DAV-FK
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 18:57:00 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2TItQ9V009383
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 13:55:26 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2TIrnk5028733
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 13:53:50 -0500 (EST)
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: Why are we doing netconf?
Date: Wed, 29 Mar 2006 20:56:57 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43BE92@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZTWkDtRPOj+UYBSEC8m9WPATG4iQAB/QhA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Eliot Lear" <lear@cisco.com>
Cc: "Sharon Chisholm" <schishol@nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

I was not necessarily pleading in favor or against a specific protocol,
but rather making the case that back in 2002 and even more today there
may be room for looking for a consistent security framework, that brings
together different protocols each better suited for specific management
functions rather than design one protocol to perform all management
operations.

Dan


=20
=20

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]=20
> Sent: Wednesday, March 29, 2006 7:57 PM
> To: Romascanu, Dan (Dan)
> Cc: Sharon Chisholm; Netconf (E-mail)
> Subject: Re: Why are we doing netconf?
>=20
> Hi Dan,
>=20
> > It also was intended to meet the needs of the operators as=20
> they were=20
> > scanned by 2001-2002. They told us then that they can leave=20
> well with=20
> > the alarms and performance monitoring mechanisms in SNMP,=20
> but consider=20
> > configuration by SNMP a dead horse.
> >  =20
>=20
> Actually, for fault management management and alarms some=20
> consider SNMP a dead horse.  Most enterprises in particular=20
> prefer SYSLOG and ASCII.=20
> SPs say they like SNMP but then they use tools like=20
> Netcool/CIC, and so SYSLOG does very well for them as well. =20
> In the end I think we'd find agreement between the two groups=20
> that standardized events should tail differentiation.
>=20
> I also think one of the reasons they considered SNMP a dead=20
> horse was lousy integration with their existing AAA.  ISMS=20
> may help this.
>=20
> Eliot
>=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 Wed Mar 29 14:33:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOgPk-00014t-Lp
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:33:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOgPk-00059d-CM
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:33:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOgLl-000Fe0-1d
	for netconf-data@psg.com; Wed, 29 Mar 2006 19:29:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.69] (helo=pop-savannah.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FOgLj-000Fdn-LJ
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 19:29:00 +0000
Received: from h-68-166-188-37.snvacaid.dynamic.covad.net ([68.166.188.37] helo=oemcomputer)
	by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FOgLd-0001iQ-00
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 14:28:53 -0500
Message-ID: <00ac01c65367$6d10eb00$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com> <043001c651e7$2cdb42a0$6401a8c0@oemcomputer> <44286228.5070709@andybierman.com> <442906B3.2080406@ericsson.com>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
Date: Wed, 29 Mar 2006 11:31:48 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Hi -

> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Tuesday, March 28, 2006 1:49 AM
> Subject: Re: (unofficial issue 2) Subscription versus never-ending command
>
> Do we allow one user to use multiple subscriptions ? I would say yes.

Of course.
 
> If we connect the notification subscription strictly to a user identity we force the user 
> to specify security data multiple times to be able to use multiple subscriptions. Is this 

User identity is obviously not the only interesting attribute of a subscription.
Think how SNMP notification subscriptions work.  The user identity is necessary
for access control (both of the subscription itself as well as in constraining what
is permitted to be sent).  One also needs information describing *where* the
information should be sent on behalf of that user, among other things.

> our aim or am I missing something ? (In our management system different functional parts 
> are interested in different notifications, but I see no need for a security point of view 
> to require multiple user identities for them.)
...

No disagreement.  Indeed, this is yet another argument against binding the
subscription to a connection.  Consider the scenario where there are multiple
"interested" systems or applications, and the devices to be managed are
intermittently reachable.  Is it better for the managed device to establish a
connection if/when needed, or have the applications futilely attempting to make
connections to all the devices that happen to be unreachable at the moment?
Think netconf for cellphones and PDAs.

Randy


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



From owner-netconf@ops.ietf.org Wed Mar 29 14:57:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOgms-0004Vh-AL
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:57:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOgmr-0005ui-Qg
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 14:57:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOgj7-000HS6-40
	for netconf-data@psg.com; Wed, 29 Mar 2006 19:53:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [217.12.11.62] (helo=smtp008.mail.ukl.yahoo.com)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <vincent.cridlig@loria.fr>)
	id 1FOgj5-000HRr-QF
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 19:53:08 +0000
Received: (qmail 1649 invoked from network); 29 Mar 2006 19:53:06 -0000
Received: from unknown (HELO ?192.168.0.2?) (cridligv@213.44.82.97 with plain)
  by smtp008.mail.ukl.yahoo.com with SMTP; 29 Mar 2006 19:53:06 -0000
Message-ID: <442AE5EE.9070600@loria.fr>
Date: Wed, 29 Mar 2006 21:54:22 +0200
From: Cridlig Vincent <vincent.cridlig@loria.fr>
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: "David T. Perkins" <dperkins@dsperkins.com>
CC:  netconf@ops.ietf.org
Subject: Re: Notifications with config change
References: <Pine.LNX.4.10.10603290932070.26409-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10603290932070.26409-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6


>
> A second related issue is that the authorization to modify
> the notification delivery part of the configuration is
> an upgrade in capabilities of a configuration application
> which could be abused. In very small systems, the 
> capability to view and/or modify config is all or
> nothing. The next step up in granularity is separating
> the config into the "admin part" and the "operational
> part", and then having separate apps (and authorized
> identities) for managing the admin and operational
> parts of the config. (The admin part determines the
> list of authorized identities and what each is
> authorized to do, including receive notifications.
> To receive notifications the following must be
> configured: the target address, credentials to use in
> creating the session to deliver the notifications,
> the filters for the session, and access to a log
> in case the notifications can not be delivered.)
> The next step up is dividing the config into
> further pieces so that applications can be
> restricted to modifying only the needed parts.
>   
This is where Role-Based Access Control comes into action.
Dividing the config into further pieces is exactly the same as defining 
a set of roles for identities (users or appplications), each role being 
granted some permissions.
When a user activates a role, he is allowed to update only a limited 
part of the config, which helps a lot for reducing misconfiguration.

In your example, you would instead define a adminRole and an 
operationalRole. OperationRole, for instance, would be granted the 
permission to modify a specific subtree of the Netconf data model 
related to operational configuration. adminRole would be allowed to 
modify the security policy of the management interface (Netconf itself).
A monitorRole would be granted the permission to receive notifications.
And so on...

Vincent

> So, in summary, I believe that providing a notification
> channel that is created and shares fate with a session
> that includes a configuration channel is a desired
> feature because:
> 1) it eliminates what appear like two config changes
> 2) it results in better system security
>
> Note that I realize that the above benefits come
> with costs, and they include:
> 1) an increase in complexity of the NETCONF protocol
> 2) a change in mindset of existing developers and
>    users of existing approachs
>
> I believe that the benefits far exceed the costs.
>
> Regards,
> /david t. perkins   
>
>
>
>
>
>
>
> --
> 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/>
>   


	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com


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



From owner-netconf@ops.ietf.org Wed Mar 29 15:05:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOgvI-0000HK-8L
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 15:05:44 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOfoj-0003fw-1d
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 13:54:53 -0500
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FOfeU-0003sb-PY
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 13:44:21 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOfZF-000BiK-2g
	for netconf-data@psg.com; Wed, 29 Mar 2006 18:38:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FOfZE-000Bi6-GM
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 18:38:52 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2TIcqFC028020
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 10:38:52 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2TIcqxg028017
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 10:38:52 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 29 Mar 2006 10:38:51 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: netconf@ops.ietf.org
Subject: Notifications with config change
Message-ID: <Pine.LNX.4.10.10603290932070.26409-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8

HI,

At the WG NETCONF meeting at the Dallas IETF conference,
I tried to make a point about event reporting (notifications)
during a config change. I didn't seem to be understood,
so let me try again...

First, I believe that delivery of event reports is needed
during config change. (The reasons are currently being
collected.)
I also believe that each config change needs to be
recorded and reported. (This is for auditing, to determine
if a config change resulted in a problem, to check that
each config change was authorized, to correlate changes
in config to changes in behavior in the system (such
as changes in performance, changes in service instance
capacity, etc).)

So, if configuration of notification delivery is not
a part of config change, then an application that
does config change and wants to receive notifications
must do the following:
1) config the system to send the app appropriate notifications.
2) perform the config change (and receive any appropriate
   notifications associated with the config change)
3) config the system to no longer send the app notifications

At a macro level this looks like three config changes,
even though the 3rd config change undoes the 1st change.
If a config app gets delivery of notifications as part
of the creation of the "session" for config change, then
there would be no config change #1 and #3.

A second related issue is that the authorization to modify
the notification delivery part of the configuration is
an upgrade in capabilities of a configuration application
which could be abused. In very small systems, the 
capability to view and/or modify config is all or
nothing. The next step up in granularity is separating
the config into the "admin part" and the "operational
part", and then having separate apps (and authorized
identities) for managing the admin and operational
parts of the config. (The admin part determines the
list of authorized identities and what each is
authorized to do, including receive notifications.
To receive notifications the following must be
configured: the target address, credentials to use in
creating the session to deliver the notifications,
the filters for the session, and access to a log
in case the notifications can not be delivered.)
The next step up is dividing the config into
further pieces so that applications can be
restricted to modifying only the needed parts.

So, in summary, I believe that providing a notification
channel that is created and shares fate with a session
that includes a configuration channel is a desired
feature because:
1) it eliminates what appear like two config changes
2) it results in better system security

Note that I realize that the above benefits come
with costs, and they include:
1) an increase in complexity of the NETCONF protocol
2) a change in mindset of existing developers and
   users of existing approachs

I believe that the benefits far exceed the costs.

Regards,
/david t. perkins   







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



From owner-netconf@ops.ietf.org Wed Mar 29 15:13:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOh2Q-0002fK-Q7
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 15:13:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOh2Q-0006l0-Co
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 15:13:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOgyN-000IZ9-KW
	for netconf-data@psg.com; Wed, 29 Mar 2006 20:08:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_SOFTFAIL autolearn=no version=3.1.1
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FOgyM-000IYy-Vp
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 20:08:55 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by test-iport-1.cisco.com with ESMTP; 29 Mar 2006 12:08:54 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2TK8s7r006497
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 12:08:54 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 29 Mar 2006 12:08:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: notification motivation and requirements
Date: Wed, 29 Mar 2006 12:08:53 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB019A1586@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: notification motivation and requirements
Thread-Index: AcZTQA+nJ9nFhDWLSt+4sToUvydwTAAGZ8tQ
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 29 Mar 2006 20:08:54.0598 (UTC) FILETIME=[9AD6CE60:01C6536C]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c

=20

Here're some requirements/motivations/comments for having NETCONF
notifications

It may not be possible/feasible, at least now, to have a single
management interface that satisfies every need. However, IMO having a
management protoco/interface restricted to a single task (e.g.
configuration) is a significant limitation. So...
=20

- Two areas with large voids (configuration and event notifications).
NETCONF could fill this void. Need a management interface which can be
used for configuration and monitoring of notifications resulting from
those configuration changes.=20

- First priority for notifications: configuration change notifications=20

- Need the following capabilities for event notifications: subscription,
filtering



Comments

- Adding notification support to NETCONF (i.e. just the protocol) is not
the end goal but it is the first and necessary step. Adding this support
provides a more useful management interface & adds features not found in
other protocols

- The next step is to define protocol independent event notification
messages (types & contents). Without this there is little value in
adding event notifications to NETCONF. But repeating the above, adding
protocol support is the first step=20

- If the above work is done either as part of NETCONF WG or elsewhere,
on-going work in this area should be leveraged.=20

- Some people consider adding notification support to NETCONF as
re-inventing things. The problem is that existing solutions are not
adequate (i.e. SNMP & syslog)=20



Motivations

- SNMP is not used for configuration and it hardly provides an adequate
solution for event notifications. SNMP has been around for a long long
time and it's time to look at alternatives =20
- Syslog messages are unstructured & protocol has limitations (e.g. size
limitations, filtering, subscription, etc.)
- The new syslog-protocol ID addresses the structured data but there are
no standarized SD fields (ok maybe 2 or 3).   =20
- Need to provide better ways for delivering event notifications. Many
industry segments moving to Web services (e.g. WS-management, WSDM,
converged standard). Network devices need to evolve as well.=20
- Adding notification support to NETCONF & standarizing event
definitions allow vendors as well as users to choose how the want to
receive event notifications. If some prefer syslog protocol then use it.
The NETCONF notifications could be used as a migration from syslog to
NETCONF notifications for those who need a multi-purpose protocol.  =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 Wed Mar 29 15:23:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOhC7-0001eR-VP
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 15:23:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOhC7-0007Cc-Iq
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 15:23:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOh8w-000JKQ-Bv
	for netconf-data@psg.com; Wed, 29 Mar 2006 20:19:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FOh8v-000JKF-N4
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 20:19:49 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2TKJfEH020498;
	Wed, 29 Mar 2006 12:19:41 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2TKJfBr020495;
	Wed, 29 Mar 2006 12:19:41 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 29 Mar 2006 12:19:41 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Cridlig Vincent <vincent.cridlig@loria.fr>
cc: netconf@ops.ietf.org
Subject: Re: Notifications with config change
In-Reply-To: <442AE5EE.9070600@loria.fr>
Message-ID: <Pine.LNX.4.10.10603291207000.4052-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6

HI,

So, I'm confused by your response because it doesn't seem
to address whether or not there is a benefit that exceeds
the cost from "providing a notification channel that is
created and shares fate with a session that includes a
configuration channel".

As regards to "role based management", it is one,
but not the only approach for implementing authorizations.
That is, I don't see it as a requirement, and instead
see it a one potential solution in managing authorizations.

(see inline comment below)
On Wed, 29 Mar 2006, Cridlig Vincent wrote:
> > A second related issue is that the authorization to modify
> > the notification delivery part of the configuration is
> > an upgrade in capabilities of a configuration application
> > which could be abused. In very small systems, the 
> > capability to view and/or modify config is all or
> > nothing. The next step up in granularity is separating
> > the config into the "admin part" and the "operational
> > part", and then having separate apps (and authorized
> > identities) for managing the admin and operational
> > parts of the config. (The admin part determines the
> > list of authorized identities and what each is
> > authorized to do, including receive notifications.
> > To receive notifications the following must be
> > configured: the target address, credentials to use in
> > creating the session to deliver the notifications,
> > the filters for the session, and access to a log
> > in case the notifications can not be delivered.)
> > The next step up is dividing the config into
> > further pieces so that applications can be
> > restricted to modifying only the needed parts.
> >   
> This is where Role-Based Access Control comes into action.
> Dividing the config into further pieces is exactly the same as defining 
> a set of roles for identities (users or appplications), each role being 
> granted some permissions.
> When a user activates a role, he is allowed to update only a limited 
> part of the config, which helps a lot for reducing misconfiguration.
> 
> In your example, you would instead define a adminRole and an 
> operationalRole. OperationRole, for instance, would be granted the 
> permission to modify a specific subtree of the Netconf data model 
> related to operational configuration. adminRole would be allowed to 
> modify the security policy of the management interface (Netconf itself).
> A monitorRole would be granted the permission to receive notifications.
> And so on...
So, using role-based access control (which is one possible
approaches to specifying authorization) it doesn't seem to
eliminate the 1st and 3rd config changes, nor does it eliminate
an upgrade in authorization. I'm I messing something?

> 
> Vincent
> 
> > So, in summary, I believe that providing a notification
> > channel that is created and shares fate with a session
> > that includes a configuration channel is a desired
> > feature because:
> > 1) it eliminates what appear like two config changes
> > 2) it results in better system security
> >
> > Note that I realize that the above benefits come
> > with costs, and they include:
> > 1) an increase in complexity of the NETCONF protocol
> > 2) a change in mindset of existing developers and
> >    users of existing approachs
> >
> > I believe that the benefits far exceed the costs.
> >
> > Regards,
> > /david t. perkins   

Regards,
/david t. perkins


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



From owner-netconf@ops.ietf.org Wed Mar 29 16:07:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOht9-0004FJ-6G
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 16:07:35 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOht7-0000ey-Mb
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 16:07:35 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOhp6-000N3n-QP
	for netconf-data@psg.com; Wed, 29 Mar 2006 21:03:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOhp5-000N3b-Cq
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 21:03:23 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 9E5C755D59;
	Wed, 29 Mar 2006 23:03:22 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 18002-09; Wed, 29 Mar 2006 23:03:21 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 06FBA55D2E;
	Wed, 29 Mar 2006 23:03:21 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 1C44B64F4CD; Wed, 29 Mar 2006 23:03:18 +0200 (CEST)
Date: Wed, 29 Mar 2006 23:03:18 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "David T. Perkins" <dperkins@dsperkins.com>
Cc: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
Message-ID: <20060329210318.GA1043@noname>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "David T. Perkins" <dperkins@dsperkins.com>,
	netconf@ops.ietf.org
References: <Pine.LNX.4.10.10603290922350.26409-100000@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.10.10603290922350.26409-100000@shell4.bayarea.net>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

On Wed, Mar 29, 2006 at 09:28:11AM -0800, David T. Perkins wrote:
 
> *) notifications to report unexpected consequences of
>    a configuration change

How does a device distinguish between expected and unexpected
consequences of a configuration change?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 17:35:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjFn-0002Lq-7D
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:35:03 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjFk-0003uk-QQ
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:35:03 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjAP-0004pT-FZ
	for netconf-data@psg.com; Wed, 29 Mar 2006 22:29:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOjAO-0004pE-6k
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 22:29:28 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 332A355D8B;
	Thu, 30 Mar 2006 00:29:27 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 24400-10; Thu, 30 Mar 2006 00:29:25 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 4B5F255C77;
	Thu, 30 Mar 2006 00:29:25 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id ECD0764F59D; Thu, 30 Mar 2006 00:29:22 +0200 (CEST)
Date: Thu, 30 Mar 2006 00:29:22 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Sharon Chisholm <schishol@nortel.com>
Cc: netconf@ops.ietf.org
Subject: Re: Why are we doing netconf?
Message-ID: <20060329222922.GB1132@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Sharon Chisholm <schishol@nortel.com>,
	netconf@ops.ietf.org
References: <713043CE8B8E1348AF3C546DBE02C1B4079FE443@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4079FE443@zcarhxm2.corp.nortel.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

On Wed, Mar 29, 2006 at 12:17:05PM -0500, Sharon Chisholm wrote:
 
> Predictable is that the consumer of the message based only on the
> protocol definition and a definition of the data model associated with
> the notification (XML Schema, for example) are able to predict what
> information will be in the notification and how it will be formatted.

I assume that any reasonable data modeling language should have the
property that notifications defined with the data modeling language
are predictable.

I fail to see a requirement here for the development of a NETCONF
_protocol_ extension. If I am wrong, can you please help me phrase
this as a protocol requirement?

> <Juergen>
> > - reliable delivery (or ability to detect when things go wrong)
> > - event replay
> 
> Why is that a requirement? What is this good for in operational
> environments?
> </Juergen>
> 
> I should mention that I consider event replay something we can add
> later. We did not include it in the draft. Event replay is a mechanism
> that allows you when you first start talking to a device to learn about
> interesting events that have happened to it within the immediate past.
> Ideally, this information will be in the same format as it would have
> been if you had actually been there it hear it.

Thanks for the clarification. So then I will not list event "event
replay" as a requirement.
 
> <Juergen>
> > - Ability to support different types of events (alarms, logs, 
> > configuration snippets, etc)
> 
> Is "configuration snippets" and event type? Is logs == syslog messages?
> </Juergen>
> 
> A configuration snippet would be part of a configuration either as part
> of an audit trial or a configuration mirroring thing. I think
> configuration might be the actual event class. Logs could be the same
> sort of information that is currently done in syslog, yes. 

So what is the distinction between an event class and an event type?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Wed Mar 29 17:45:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjQ3-0008H9-Ap
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:45:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjQ2-00049W-St
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:45:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjMc-00068r-G2
	for netconf-data@psg.com; Wed, 29 Mar 2006 22:42:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOjMZ-00068a-MC
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 22:42:03 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2TMg2vW001764
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 17:42:02 -0500
Received: (qmail 16828 invoked by uid 78); 29 Mar 2006 22:42:02 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 29 Mar 2006 22:42:02 -0000
Message-ID: <442B0D33.4070808@andybierman.com>
Date: Wed, 29 Mar 2006 14:41:55 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: no interim meeting -- read the rules
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com>
In-Reply-To: <442A3E03.3000006@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Balazs Lengyel wrote:
> Hi,
> For us notifications are needed mostly not as a logging mechanism but as:
> - a way to notify about configuration changes
> - a way to notify the management system about delayed results of an RPC 
> (e.g. when an RPC initiated action takes 10 minutes to complete we send 
> an immediate reply <started> and a late reply <finished>)



When you explained this the first time it sounded like you
broke the RPC model, but you didn't.  Your 1st RFC can be
seen as a request to start a background task.  Exactly 1 rfc-reply
is sent for this request.  Later you send notifications to
provide status of the background task.  Looks like a good use
of notifications to me.

All of your use cases make sense I think.
You could probably do this with syslog or snmp notifications,
but it also makes sense to use netconf notifications.

Andy


> - to notify the network management system (NMS) about things that might 
> need operator action. (While alarm handling is mostly SNMP there is a 
> need for some other events to be handled by the NMS.)


> 
> 
> For these reasons we do need a notification mechanism. We could use
> - SNMP: but if we have an XML based hierarchical data model with 
> meaningful names using SNMP is not my choice.
> - Syslog: but the message size limit of less then 480 octets seems a 
> problem. Also I like subscription. Adding XML to syslog needs some work. 
> We have to care about a second transport/security mechanism TLS (I don't 
> know if this is a real problem).
> - Netconf-notifications: This would mean a somewhat unified structure 
> within Netconf. Using our XML-based hierarchical data model would be 
> natural.
> 
> regards Balazs
> 
> Andy Bierman wrote:
>> As Dan and Dave H. pointed out, we need to agree on what
>> we are doing and why we are doing it.  Several people
>> have told me (and mentioned on the list) that they
>> don't understand why we are reinventing syslog instead
>> of working on network configuration.
>>
>> So let's write down all the reasons why we need notifications
>> in NETCONF, and why using or extending existing standards
>> instead won't work.
>  >
>> Andy
> 
> 


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



From owner-netconf@ops.ietf.org Wed Mar 29 17:57:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjbe-0005Ye-4q
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:57:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjbd-0004cG-EL
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 17:57:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjXf-0007Ff-VJ
	for netconf-data@psg.com; Wed, 29 Mar 2006 22:53:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOjXe-0007FO-D4
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 22:53:30 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2TMrSts028300
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 17:53:28 -0500
Received: (qmail 8166 invoked by uid 78); 29 Mar 2006 22:53:27 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 29 Mar 2006 22:53:27 -0000
Message-ID: <442B0FE0.7040104@andybierman.com>
Date: Wed, 29 Mar 2006 14:53:20 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?
References: <713043CE8B8E1348AF3C546DBE02C1B40798F5F9@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40798F5F9@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935

Sharon Chisholm wrote:
> hi

To all the people who want netconf to be a replacement
for syslog, snmp, ipfix, or whatever:

How about if we solve network configuration first,
then replace every other MGMT protocol in the world
with our new protocol?  (!)

I don't think the WG agrees that notifications in the
NETCONF protocol is a critical missing component,
let alone the most important critical missing component.

For NETCONF to be truly content-independent, the notification
delivery mechanism needs to be totally decoupled from
notification content.  There are a lot of different
ideas on this content, and who should standardize it.

I am totally opposed to the NETCONF WG working on syslog
content.  We need syslog experts (and the Chair) for that.
Sounds like a BOF in the works, but no NETCONF work item here.

I am also totally opposed to working on anything but
the bare minimum number of standard notifications
(like config-change) at this time.  You want a data model,
how about creating a writable interfaces table and an access control
model?  These are critical missing data models.


Andy

> 
> Thanks Dave for the well-thought through post.
> 
> I think the 'restriction' on Netconf for configuration has always been
> an artificial one, but it has served us well. One of the big problems we
> ran into with SNMP was we kept picking off the easier problem of
> monitoring and never giving configuration enough focus. By limiting the
> focusing primarily on configuration for Netconf 1.0, we have ended up
> with a great technical solution that is seeing some good market uptake.
> 
> I think actual implementations of Netconf are not limiting themselves to
> just configuration. The CLI never did. For deployments, the high cost of
> having to integrate information from different sources gets weighed
> against the cost of having to replace legacy systems. Sometimes it wins.
> Sometimes it doesn't. For the most part, all this can be done using the
> existing framework. The gaps that people run into when trying to do this
> are, I believe, the same ones they run into while trying to use Netconf
> for configuration - access control, data model and notifications.
> Another gap might be 'operational' commands such as rebooting and
> maintenance, but the universal requirements there are not yet clear to
> me.
> 
> I've personally been working both the data modeling and the notification
> issue. I'd work access control, but other then a sense that I'd like
> something simpler then we've seen in the past, I have no idea what we
> would need. They are all important, both for configuration-only
> implementations and configuration-plus ones.  I've focused more on the
> notification work lately because I was getting a lot of pushback on the
> data model work from certain people, but I'm willing to put time on that
> topic again. I think though, that for people looking to be able to pick
> up third-party Netconf stacks, there are some big advantages to being
> able to standardize on any extended protocol operations sooner rather
> then later.
> 
> As far as whether if we said from day one that netconf would do more
> than configuration and things would have been designed differently, I
> don't now if that is the case. As far as being forced to solve problems
> at some point in the future related to performance management if we
> don't somehow engineer/re-engineer the protocol so it can't be used for
> things like that, I don't think that would be helpful.   At that day in
> the future the community can decide whether it wants to spend time on
> that particular problem. Plus, unless at that point in the future we
> learned that they were not also using Netconf for configuration, this
> would be a sign of success.
> 
> So, in summary, I think the current notification work absolutely is
> necessary for configuration management. I don't see the value of
> precluding its use for other functions and I believe for the other
> functions all we need to do is provide the ability to specify the
> correct event class. I'm also willing to work on the other gaps.
> 
> Sharon
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of David Harrington
> Sent: Tuesday, March 28, 2006 1:26 PM
> To: 'Netconf (E-mail)'
> Subject: Why are we doing netconf?
> 
> 
> Hi,
> 
> I would like a better understasnding of why we are doing notifications.
> I am struck by what appears to me to be two very different drivers for
> netconf, and the "why are we doing notifications?" question relates to
> these different motivations.
> 
> I have suggested that the O&M and Security communities should work at
> establishing a strategic vision about converging aspects of the various
> NM protocols and NM security solutions. If this is a path worth taking,
> it should be a deliberate decision to do so because there are some real
> problems associated with a convergence approach.
> 
> For this reason, I would like to understand what we are trying to
> achieve with netconf and the current proposal for notifications, to
> determine if the goals are compatible.
> 
> If the purpose of netconf is to provide a machine-friendly, standardized
> protocol to eliminate the need for screen scraping CLI expect scripts, I
> am not convinced we need notifications in the netconf protocol. I think
> the netconf WG has done a reasonably good job of standardizing the
> operations, but to achieve the goals, we also need to improve the
> parseability of the data that now needs to be screen scraped. The
> parseability of the data contained in the responses coming back must be
> addressed. If vendors simply take their existing screens of data and
> surround them with <cli></cli> tags, then I think we've failed to
> eliminate the screen-scraping problem, and other problems identified by
> operators at the IAB NM workshop:
> 
>    -  Some command line interfaces lack a common data model.  It is very
>       well possible that the same command on different devices, even
>       from the same vendor, behaves differently.
> 
>    -  The command line interface is primarily targeted to humans which
>       can adapt to minor syntax and format changes easily.  Using
>       command line interfaces as a programmatic interface is troublesome
>       because of parsing complexities.
> 
>    -  Command line interfaces often lack proper version control for the
>       syntax and the semantics.  It is therefore time consuming and
>       error prone to maintain programs or scripts that interface with
>       different versions of a command line interface.
> 
>    -  Since command line interfaces are proprietary, they can not be
>       used efficiently to automate processes in an environment with a
>       heterogenous set of devices.
> 
>    -  The access control facilities, if present at all, are often ad-hoc
>       and sometimes insufficient.
> 
> Netconf does not seem to resolve these operational disadvantages of the
> CLI, and notifications aren't even mentioned as a problem to be solved.
> 
> If the purpose of netconf is to standardzie existing practice, and
> existing practice is defined as screen scraping CLI expect scripts plus
> syslog notifications, then I question whether we need to include syslog
> notifications in netconf; syslog works well in its special niche, and
> really doesn't need to be added to netconf.
> 
> The Syslog (-security) WG has been working to standardize the message
> header format. The syslog community has not reached consensus on the
> need to standard message content, except to add a structured data
> component. The WG had difficulty even reaching agreement on
> standardizing their message header format beyond starting the message
> with <PRI>. I do not believe that netconf would be more successful at
> standardizing syslog content than the syslog community, so I do not
> believe that standardizing syslog message content should be a
> justification for adding notifications to netconf, without a long
> discussion about the feasibility of accomplishing this goal. I think the
> standardization of syslog belongs in a (O&M) syslog WG, not the netconf
> WG (and not the syslog security WG).
> 
> If the purpose of netconf is to assimilate the functionality of older
> protocols like syslog and SNMP - to integrate them into a collective
> netconf structure, and to eventually replace the old protocols with a
> new general purpose management protocol minus the known problems, then
> netconf has a higher bar to meet in its design requirements than have
> been acknowledged. SNMPv3 is complex because it needed to deal with
> security issues and troubleshooting requirements and other things;
> syslog does not have a standard content format because there are a wide
> number of vendors protecting their space, and the demand for backwards
> compatibility to all or most existing header formats has prevented
> progress in the syslog (security) WG. Faced with requirements comparable
> to those faced by the older protocols during their design, I expect
> netconf would fail to assimilate them properly. Therefore, if the
> purpose of netconf is to be a general purpose NM protocol, we need to
> have a serious discussion about the requirements that must be met to
> achieve successful assimilation.
> 
> I find the existing proposal has plans to assimilate other protocols -
> "The purpose of this [syslog-to-netconf] mapping is to provide an
> unambiguous mapping to enable consistent multi-protocol implementations
> as well as to enable future migration." and to attempt to standardize
> that which the syslog community has failed to standardize - "The intent
> is to promote the use of the NETCONF interface and not to simply provide
> a wrapper and additional delivery mechanism for syslog messages.
> NETCONF events are intended to be well defined and structured, therefore
> providing an advantage over the unstructured and often times arbitrarily
> defined syslog messages (i.e. the message field)."
> 
> I am a strong supporter of judicious reuse of NM and security solutions
> across NM interfaces, but I believe apparent convergence opportunities
> need to be discussed and for  each convergence we need to consider the
> requirements met by each protocol and whether a converged solution
> continues to meet those requirements or deliberately does not meet some
> requirements.
> 
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that even
> more stuff, also possibly not related to configuration, will be carried
> in a new event message format. Operators at the IAB Network Management
> Workshop apparently did not find syslog sufficiently broken to request
> that a new event messaging capability be designed, so I have concerns
> that the current proposal includes a brand-new notification solution.
> 
> If netconf will become the new general purpose mgmt protocol for the
> IETF, we should do this deliberately, not as a side-effect of adding a
> notification operation to netconf.
> 
> David Harrington
> FutureWei Technologies, a Huawei company
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
>> Sent: Monday, March 27, 2006 5:20 AM
>> To: Andy Bierman
>> Cc: Netconf (E-mail)
>> Subject: RE: Interim attendance survey
>>
>> [...] I am aware that this good shape is
>> apparent, and there is little agreement on the problem space, and
> too
>> little review of the draft that includes a proposed solution even to 
>> determine the level of agreement. I would encourage the WG to focus
> on
>> discussing the problem space (why are we doing notifications?) and
> the
>> draft and other options for solutions more intensively on the
>> list. Let
>> us see in the next couple of weeks if we can reach more convergence
> on
>> the 'why' and 'how' questions.
>>
>> If we do have contributions about the scope and reviews of
>> the draft and
>> solutions on the list we have a chance to better converge and reach
>> agreement. If the level of apathy stays the same, I am not sure that
> a
>> partially attended interim meeting would help.
>>
> 
> 
> 
> 
> 
> --
> 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 Wed Mar 29 18:05:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjit-0000Pc-QQ
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:05:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjis-00057n-HB
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:05:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjg6-0007y4-O3
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:02:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOjg5-0007xp-NI
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:02:14 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2TN2CZj028857
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 18:02:12 -0500
Received: (qmail 11139 invoked by uid 78); 29 Mar 2006 23:02:12 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 29 Mar 2006 23:02:12 -0000
Message-ID: <442B11ED.5000808@andybierman.com>
Date: Wed, 29 Mar 2006 15:02:05 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: netconf@ops.ietf.org
Subject: Re: Why are we doing netconf?
References: <713043CE8B8E1348AF3C546DBE02C1B40798F62F@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40798F62F@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Sharon Chisholm wrote:
> hi
> 
> <Rainer>
> 
> *If* the primary motivation to include notifications is to replace
> syslog, I think a shared effort with the syslog community would be
> benefitial.
> </Rainer>
> 
> That isn't our primary motivation. It is just that some people feel that
> some of the requirements can be met by this existing solution, which is
> why it comes up.


Probably because we started out on Day One saying
our notification solution was syslog over beep.
Now that ssh is our mandatory transport, be need
to change that plan.  But that doesn't mean abandon
syslog content and reinvent it.


As Chris pointed out, replacing syslog would be a massive
undertaking, one that many people don't prioritize very high.
IMO, except for the list posted by Balazs, there have not been any
interesting or compelling use cases for notifications in the
netconf protocol.


> 
> Sharon

Andy


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



From owner-netconf@ops.ietf.org Wed Mar 29 18:09:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjnT-0002ZW-Up
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:09:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjnT-0005Wq-HR
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:09:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjj2-0008E7-NN
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:05:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOjj1-0008Dt-R5
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:05:15 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2TN5EQ3001324
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 18:05:14 -0500
Received: (qmail 24622 invoked by uid 78); 29 Mar 2006 23:05:14 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 29 Mar 2006 23:05:14 -0000
Message-ID: <442B12A3.1000604@andybierman.com>
Date: Wed, 29 Mar 2006 15:05:07 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: netconf@ops.ietf.org
Subject: Re: Why are we doing netconf?
References: <713043CE8B8E1348AF3C546DBE02C1B40798F8E6@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40798F8E6@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43

Sharon Chisholm wrote:
> Here are some of the requirements . 
> 
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification
> - Structured content
> - Predictable content
> - reliable delivery (or ability to detect when things go wrong)
> - event replay 
> - Ability to support different types of events (alarms, logs,
> configuration snippets, etc)
> - XML encoding (not a big driver, but certainly a major industry
> direction)


Why are all these features important?
The agent people in the WG think there is too much
complexity in your proposal.  The NMS people think
there is not enough features in any of the simple
proposals.

We are deadlocked.
It is going to take detailed technical justifications
to move either side at this point.  Not a bullet list.


Andy

> 
> The thing I struggle with in syslog is the well-deployed syslog versus
> the new stuff we designed. I think some of the changes made recently to
> add new features on top of legacy (or that is at least my
> interpretation) will help compared to the original plan, but I worry
> that if we change syslog too much we lose any benefits of using an
> existing solution. We then end up with a new protocol that we still call
> syslog for sentimental reasons, but not one that integrates well with
> either legacy syslog or other management functions being supported by
> solutions like Netconf.
> 
> The same applies to trying to modify SNMP to do this as well. 
> 
> Sharon
> 
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Wednesday, March 29, 2006 9:16 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org
> Subject: RE: Why are we doing netconf?
> 
> 
> Sharon, 
> 
>> <Rainer>
>> *If* the primary motivation to include notifications is to replace 
>> syslog, I think a shared effort with the syslog community would be 
>> benefitial. </Rainer>
>>
>> That isn't our primary motivation. It is just that some
>> people feel that
>> some of the requirements can be met by this existing 
>> solution, which is
>> why it comes up.
> 
>>From following the list (but sometimes briefly), I have to admit that I
> do not have a clear impression on what the primary motivation is and why
> a separate event logging protocol is needed. I think it would help
> immensely if there would be description of what is intended and why
> syslog can not do the job. That would also help focus the document on
> these topics. Besides, it might be easy to modify syslog to solve
> issues...
> 
> I am aware that there is a requirements/motivation discussion. I think
> this discussion is useful for the reasons outlined above.
> 
> Rainer
> 
> 
> --
> 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 Wed Mar 29 18:22:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjzX-0005PH-68
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:22:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjzT-0006nm-RW
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:22:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOjwK-0009Ue-Qz
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:19:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOjwK-0009UR-1I
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:19:00 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2TNIwkQ027358
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 18:18:58 -0500
Received: (qmail 14227 invoked by uid 78); 29 Mar 2006 23:18:58 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 29 Mar 2006 23:18:58 -0000
Message-ID: <442B15DB.7080703@andybierman.com>
Date: Wed, 29 Mar 2006 15:18:51 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "David T. Perkins" <dperkins@dsperkins.com>
CC: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
References: <Pine.LNX.4.10.10603290922350.26409-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10603290922350.26409-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

David T. Perkins wrote:
> HI,
> 
> Here are a couple to add to the list....
> 
> *) notifications to report unexpected consequences of
>    a configuration change

How is the agent supposed to know what the NMS really
wanted to do?  Why do we need this?

> *) notifications so that state changes can be followed
>    due to configuration changes. (Background: some 
>    configuration changes can result in destalization
>    followed by transition through several states to
>    the desired stable state. It is important to know
>    the cause of a "service affecting event", and to
>    know if the config change has resulted in a new
>    stable and desired configuration. If not, then
>    the config change, most likely, should be rolled
>    back to the previous settings.) 

You should write a draft with the data model
that you are implying here.  IMO, the notification
capability should not drag in a bunch of data models.

There should be absolutely no content requirements
for notifications -- just like there are none
for configuration data models.
I want <cli> and <huge-bgp-model> to be on equal footing
in our content-independent protocol.  Same thing
applies to notification content.


> 
> Regards,
> /david t. perkins

Andy

> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Wed Mar 29 18:44:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOkL7-0004IC-In
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:44:37 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOkL7-0007cs-6I
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:44:37 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOkHg-000Bq1-Pi
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:41:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOkHf-000Bpd-RZ
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:41:04 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2TNevQ3022790
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 18:40:59 -0500
Received: (qmail 8680 invoked by uid 78); 29 Mar 2006 23:40:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 29 Mar 2006 23:40:56 -0000
Message-ID: <442B1B01.1090203@andybierman.com>
Date: Wed, 29 Mar 2006 15:40:49 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com> <043001c651e7$2cdb42a0$6401a8c0@oemcomputer> <44286228.5070709@andybierman.com> <442906B3.2080406@ericsson.com> <00ac01c65367$6d10eb00$6401a8c0@oemcomputer>
In-Reply-To: <00ac01c65367$6d10eb00$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

Randy Presuhn wrote:
> Hi -
> 
>> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
>> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
>> Sent: Tuesday, March 28, 2006 1:49 AM
>> Subject: Re: (unofficial issue 2) Subscription versus never-ending command
>>
>> Do we allow one user to use multiple subscriptions ? I would say yes.
> 
> Of course.


Do you mean multiple subscriptions per session?
If so I don't agree.  (Note that this is not the
same as a single subscription + modify-subscription feature.)

It might make sense to support multiple subscriptions
per session if netconf had multi-user sessions, but it doesn't.
Why (in the name of Good Engineering) would you ever want
the agent to spend lots of time classifying events, and
sending multiple copies of the same notification on the
same single-user session?

This isn't an snmp notification or syslog demuxer,
so why try to turn it into one?


Andy


>  
>> If we connect the notification subscription strictly to a user identity we force the user 
>> to specify security data multiple times to be able to use multiple subscriptions. Is this 
> 
> User identity is obviously not the only interesting attribute of a subscription.
> Think how SNMP notification subscriptions work.  The user identity is necessary
> for access control (both of the subscription itself as well as in constraining what
> is permitted to be sent).  One also needs information describing *where* the
> information should be sent on behalf of that user, among other things.
> 
>> our aim or am I missing something ? (In our management system different functional parts 
>> are interested in different notifications, but I see no need for a security point of view 
>> to require multiple user identities for them.)
> ...
> 
> No disagreement.  Indeed, this is yet another argument against binding the
> subscription to a connection.  Consider the scenario where there are multiple
> "interested" systems or applications, and the devices to be managed are
> intermittently reachable.  Is it better for the managed device to establish a
> connection if/when needed, or have the applications futilely attempting to make
> connections to all the devices that happen to be unreachable at the moment?
> Think netconf for cellphones and PDAs.
> 
> Randy
> 
> 
> --
> 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 Wed Mar 29 18:45:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOkMA-0006Wh-0x
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:45:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOkM8-0007fy-OV
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:45:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOkIs-000BwI-V8
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:42:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FOkIs-000Bw5-CS
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:42:18 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2TNgGYM010192;
	Wed, 29 Mar 2006 15:42:16 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2TNgFwo010185;
	Wed, 29 Mar 2006 15:42:16 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 29 Mar 2006 15:42:15 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
cc: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
In-Reply-To: <20060329210318.GA1043@noname>
Message-ID: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

HI,

The wording is bad in my description below since it implies that
present day devices can determine when resulting conditions or
events are unexpected consequences of a config change.

So, please change it to the following:
 *) notifications that report changes in device state, or
    transient events so that the mmgmt app can determine
    any unexpected consequences of a configuration change.

Thanks for catching my sloppy wording.

On Wed, 29 Mar 2006, Juergen Schoenwaelder wrote:
> On Wed, Mar 29, 2006 at 09:28:11AM -0800, David T. Perkins wrote:
>  
> > *) notifications to report unexpected consequences of
> >    a configuration change
> 
> How does a device distinguish between expected and unexpected
> consequences of a configuration change?
> 
> /js

Regards,
/david t. perkins


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



From owner-netconf@ops.ietf.org Wed Mar 29 18:50:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOkQx-0002ju-CG
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:50:39 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOkQw-0007yL-Hn
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 18:50:39 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOkNX-000CQG-T5
	for netconf-data@psg.com; Wed, 29 Mar 2006 23:47:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.70] (helo=pop-borzoi.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FOkNV-000CQ3-TP
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 23:47:07 +0000
Received: from h-68-166-188-37.snvacaid.dynamic.covad.net ([68.166.188.37] helo=oemcomputer)
	by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FOkNU-0000lA-00
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 18:47:05 -0500
Message-ID: <001001c6538b$8325f420$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <713043CE8B8E1348AF3C546DBE02C1B407926D49@zcarhxm2.corp.nortel.com> <043001c651e7$2cdb42a0$6401a8c0@oemcomputer> <44286228.5070709@andybierman.com> <442906B3.2080406@ericsson.com> <00ac01c65367$6d10eb00$6401a8c0@oemcomputer> <442B1B01.1090203@andybierman.com>
Subject: Re: (unofficial issue 2) Subscription versus never-ending command
Date: Wed, 29 Mar 2006 15:50:06 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

Hi -

The context of the quoted message was the discussion of why binding
subscriptions to sessions doesn't make sense to some of us.  In that
context, I have trouble making sense of Andy's questions.  Indeed, they
seem to be hinting at further reasons why binding subscriptions to
sessions may be undesirable.

Randy

----- Original Message ----- 
From: "Andy Bierman" <ietf@andybierman.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Wednesday, March 29, 2006 3:40 PM
Subject: Re: (unofficial issue 2) Subscription versus never-ending command


> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
> >> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> >> Sent: Tuesday, March 28, 2006 1:49 AM
> >> Subject: Re: (unofficial issue 2) Subscription versus never-ending command
> >>
> >> Do we allow one user to use multiple subscriptions ? I would say yes.
> > 
> > Of course.
> 
> 
> Do you mean multiple subscriptions per session?
> If so I don't agree.  (Note that this is not the
> same as a single subscription + modify-subscription feature.)
> 
> It might make sense to support multiple subscriptions
> per session if netconf had multi-user sessions, but it doesn't.
> Why (in the name of Good Engineering) would you ever want
> the agent to spend lots of time classifying events, and
> sending multiple copies of the same notification on the
> same single-user session?
> 
> This isn't an snmp notification or syslog demuxer,
> so why try to turn it into one?
> 
> 
> Andy
> 
> 
> >  
> >> If we connect the notification subscription strictly to a user identity we force the user 
> >> to specify security data multiple times to be able to use multiple subscriptions. Is this 
> > 
> > User identity is obviously not the only interesting attribute of a subscription.
> > Think how SNMP notification subscriptions work.  The user identity is necessary
> > for access control (both of the subscription itself as well as in constraining what
> > is permitted to be sent).  One also needs information describing *where* the
> > information should be sent on behalf of that user, among other things.
> > 
> >> our aim or am I missing something ? (In our management system different functional parts 
> >> are interested in different notifications, but I see no need for a security point of view 
> >> to require multiple user identities for them.)
> > ...
> > 
> > No disagreement.  Indeed, this is yet another argument against binding the
> > subscription to a connection.  Consider the scenario where there are multiple
> > "interested" systems or applications, and the devices to be managed are
> > intermittently reachable.  Is it better for the managed device to establish a
> > connection if/when needed, or have the applications futilely attempting to make
> > connections to all the devices that happen to be unreachable at the moment?
> > Think netconf for cellphones and PDAs.
> > 
> > Randy
> > 
> > 
> > --
> > 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 Wed Mar 29 19:07:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOkgt-0003Km-2i
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 19:07:07 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOkgt-0001o9-0k
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 19:07:07 -0500
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FOkei-0005zy-Te
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 19:04:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOkas-000DyD-VG
	for netconf-data@psg.com; Thu, 30 Mar 2006 00:00:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FOkas-000Dxx-DR
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 00:00:54 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2U00q62014833;
	Wed, 29 Mar 2006 16:00:52 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2U00kb8014813;
	Wed, 29 Mar 2006 16:00:47 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 29 Mar 2006 16:00:46 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Andy Bierman <ietf@andybierman.com>
cc: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
In-Reply-To: <442B15DB.7080703@andybierman.com>
Message-ID: <Pine.LNX.4.10.10603291548010.6146-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

HI,

see inline.
On Wed, 29 Mar 2006, Andy Bierman wrote:
> David T. Perkins wrote:
> > HI,
> > 
> > Here are a couple to add to the list....
> > 
> > *) notifications to report unexpected consequences of
> >    a configuration change
> 
> How is the agent supposed to know what the NMS really
> wanted to do?  Why do we need this?
This is sloppily worded. How about the following....
 *) notifications for areas outside the area being changed
    that report changes in device state to error states,
    or transient error events so that the mmgmt app can
    determine any unexpected consequences of a configuration
    change.
 
> > *) notifications so that state changes can be followed
> >    due to configuration changes. (Background: some 
> >    configuration changes can result in destalization
> >    followed by transition through several states to
> >    the desired stable state. It is important to know
> >    the cause of a "service affecting event", and to
> >    know if the config change has resulted in a new
> >    stable and desired configuration. If not, then
> >    the config change, most likely, should be rolled
> >    back to the previous settings.) 
> 
> You should write a draft with the data model
> that you are implying here.  IMO, the notification
> capability should not drag in a bunch of data models.
I really need to write a book!

Anticipating your followup....
The difference between the first and second is that
the second is about notifications that are "expected".
For example, if I change some bridge spanning tree
configuration values, this might result in a change
of the spanning tree topology, and a notification will
be generated of topology change. The first set of
notifications are unexpected, such as when I change
the bridge spanning tree config, I get a notification
that a system process (the spanning tree process)
crashed and rebooted.

> There should be absolutely no content requirements
> for notifications -- just like there are none
> for configuration data models.
> I want <cli> and <huge-bgp-model> to be on equal footing
> in our content-independent protocol.  Same thing
> applies to notification content.
I don't really understand what you are saying, and
don't understand how it relates to why getting
notifications during a config change session
adds value to config management.

Regards,
/david t. perkins


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



From owner-netconf@ops.ietf.org Wed Mar 29 20:02:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOlYk-0007Df-4l
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:02:46 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOlYi-0003zZ-RL
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:02:46 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOlVQ-000K9Y-1t
	for netconf-data@psg.com; Thu, 30 Mar 2006 00:59:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOlVO-000K9M-P4
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 00:59:19 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2U0xHkQ019421
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 19:59:17 -0500
Received: (qmail 25279 invoked by uid 78); 30 Mar 2006 00:59:16 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 30 Mar 2006 00:59:16 -0000
Message-ID: <442B2D58.8040206@andybierman.com>
Date: Wed, 29 Mar 2006 16:59:04 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "David T. Perkins" <dperkins@dsperkins.com>
CC: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>, netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
References: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

David T. Perkins wrote:
> HI,
> 
> The wording is bad in my description below since it implies that
> present day devices can determine when resulting conditions or
> events are unexpected consequences of a config change.
> 
> So, please change it to the following:
>  *) notifications that report changes in device state, or
>     transient events so that the mmgmt app can determine
>     any unexpected consequences of a configuration change.

Isn't this just a special-case of the general
requirement to provide enough info in each <notification>
so that it can be analyzed by an application independently
of the notification transport mechanism?  (Maybe that is a
new requirement.)

Maybe this is what Randy means by not binding to notification
delivery parameters to the session.

Andy

> 
> Thanks for catching my sloppy wording.
> 
> On Wed, 29 Mar 2006, Juergen Schoenwaelder wrote:
>> On Wed, Mar 29, 2006 at 09:28:11AM -0800, David T. Perkins wrote:
>>  
>>> *) notifications to report unexpected consequences of
>>>    a configuration change
>> How does a device distinguish between expected and unexpected
>> consequences of a configuration change?
>>
>> /js
> 
> Regards,
> /david t. perkins
> 
> 
> --
> 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 Wed Mar 29 20:29:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOlyo-0003Y1-K5
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:29:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOlyn-0005j9-Aw
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:29:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOlwA-000Mph-Mf
	for netconf-data@psg.com; Thu, 30 Mar 2006 01:26:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOlw9-000MoC-CQ
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 01:26:58 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2U1QtZj013331
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 20:26:56 -0500
Received: (qmail 8757 invoked by uid 78); 30 Mar 2006 01:26:55 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 30 Mar 2006 01:26:55 -0000
Message-ID: <442B33D8.4010507@andybierman.com>
Date: Wed, 29 Mar 2006 17:26:48 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: one more requirement
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Hi Juergen,

Thanks for starting this list.

I think we should start with the requirement
that we add just enough complexity to support
our charter of network configuration, and no more.

If netconf is to become some sort of replacement
for other NM protocols, then as Dave H. said,
we will do it with forethought and design,
not as a side-effect of the notification work.

In the meantime, our charter is network configuration,
so we need to limit the scope of our feature set accordingly.

It doesn't matter if proprietary netconf extensions exist to
do more than configuration. We have to prioritize our
work according to the WG charter.


Andy




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



From owner-netconf@ops.ietf.org Wed Mar 29 20:29:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOlyr-0003YE-SI
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:29:45 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOlyr-0005jK-If
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 20:29:45 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOlvc-000MmL-32
	for netconf-data@psg.com; Thu, 30 Mar 2006 01:26:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.68] (helo=pop-cowbird.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FOlvZ-000Mm5-HA
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 01:26:23 +0000
Received: from h-68-166-188-37.snvacaid.dynamic.covad.net ([68.166.188.37] helo=oemcomputer)
	by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FOlvY-0003a1-00
	for netconf@ops.ietf.org; Wed, 29 Mar 2006 20:26:20 -0500
Message-ID: <000801c65399$6406b260$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net> <442B2D58.8040206@andybierman.com>
Subject: Re: notification motivation and requirements
Date: Wed, 29 Mar 2006 17:29:28 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

Hi -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "David T. Perkins" <dperkins@dsperkins.com>
> Cc: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>; <netconf@ops.ietf.org>
> Sent: Wednesday, March 29, 2006 4:59 PM
> Subject: Re: notification motivation and requirements
>
> David T. Perkins wrote:
> > HI,
> > 
> > The wording is bad in my description below since it implies that
> > present day devices can determine when resulting conditions or
> > events are unexpected consequences of a config change.
> > 
> > So, please change it to the following:
> >  *) notifications that report changes in device state, or
> >     transient events so that the mmgmt app can determine
> >     any unexpected consequences of a configuration change.
> 
> Isn't this just a special-case of the general
> requirement to provide enough info in each <notification>
> so that it can be analyzed by an application independently
> of the notification transport mechanism?  (Maybe that is a
> new requirement.)
> 
> Maybe this is what Randy means by not binding to notification
> delivery parameters to the session.
...

No, David is talking about something else.  He described a
scenario in which some way of associating a notification with
a particular configuration request would be valuable - if we employ
heuristics that might reasonably detected "unintended consequences"
of configuration requests.

Where this does fit together with what I was saying is whether we
consider it necessary for such a notification to be delivered on the
same connection as the configuration request that caused the potential
problems.  If we do, it's effectively an "oh, by the way, I noticed side-effects
X, Y, and Z" after the response to a configuration request.  If we separate
the subscription from the connection, it become "operation foo on
netconf connection bar seems to have precipitated side-effects X, Y, and Z".

Of course, this presumes that we have a way in protocol to talk about a
particular netconf connection.

Randy


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



From owner-netconf@ops.ietf.org Wed Mar 29 21:44:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOn8y-0001oX-DK
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 21:44:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOn8x-0000tE-0k
	for netconf-archive@lists.ietf.org; Wed, 29 Mar 2006 21:44:16 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOn2k-0003x7-Iq
	for netconf-data@psg.com; Thu, 30 Mar 2006 02:37:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOn2j-0003ws-PU
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 02:37:49 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2U2bmvW025336
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 21:37:48 -0500
Received: (qmail 16825 invoked by uid 78); 30 Mar 2006 02:37:47 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 30 Mar 2006 02:37:47 -0000
Message-ID: <442B4474.40007@andybierman.com>
Date: Wed, 29 Mar 2006 18:37:40 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
References: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net> <442B2D58.8040206@andybierman.com> <000801c65399$6406b260$6401a8c0@oemcomputer>
In-Reply-To: <000801c65399$6406b260$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <ietf@andybierman.com>
>> To: "David T. Perkins" <dperkins@dsperkins.com>
>> Cc: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>; <netconf@ops.ietf.org>
>> Sent: Wednesday, March 29, 2006 4:59 PM
>> Subject: Re: notification motivation and requirements
>>
>> David T. Perkins wrote:
>>> HI,
>>>
>>> The wording is bad in my description below since it implies that
>>> present day devices can determine when resulting conditions or
>>> events are unexpected consequences of a config change.
>>>
>>> So, please change it to the following:
>>>  *) notifications that report changes in device state, or
>>>     transient events so that the mmgmt app can determine
>>>     any unexpected consequences of a configuration change.
>> Isn't this just a special-case of the general
>> requirement to provide enough info in each <notification>
>> so that it can be analyzed by an application independently
>> of the notification transport mechanism?  (Maybe that is a
>> new requirement.)
>>
>> Maybe this is what Randy means by not binding to notification
>> delivery parameters to the session.
> ...
> 
> No, David is talking about something else.  He described a
> scenario in which some way of associating a notification with
> a particular configuration request would be valuable - if we employ
> heuristics that might reasonably detected "unintended consequences"
> of configuration requests.
> 
> Where this does fit together with what I was saying is whether we
> consider it necessary for such a notification to be delivered on the
> same connection as the configuration request that caused the potential
> problems.  If we do, it's effectively an "oh, by the way, I noticed side-effects
> X, Y, and Z" after the response to a configuration request.  If we separate
> the subscription from the connection, it become "operation foo on
> netconf connection bar seems to have precipitated side-effects X, Y, and Z".
> 
> Of course, this presumes that we have a way in protocol to talk about a
> particular netconf connection.

Why do you need the agent to do anything fancy at all?
You lock the configuration.
You make changes with edit-config.  You wait a few seconds.
You look at any notifications that get generated.
If it's related to configuration, it's yours.

If it's not, then neither netconf or anything else can
be sure -- and what good does guessing do?  E.g.,
if I change the bridging configuration, and some notification
related to spanning tree comes up, it could just be a
coincidence, and the problem may be caused by another device.



> 
> Randy

Andy

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



From owner-netconf@ops.ietf.org Thu Mar 30 04:18:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOtIP-0000MU-PD
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 04:18:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOtIO-0001I6-1L
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 04:18:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOtBf-000637-J2
	for netconf-data@psg.com; Thu, 30 Mar 2006 09:11:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOtBd-00062t-Uu
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 09:11:26 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBDD04F003D
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 11:11:24 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 11:11:24 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 11:11:24 +0200
Message-ID: <442BA0BB.50902@ericsson.com>
Date: Thu, 30 Mar 2006 11:11:23 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: Re: Notifications with config change
References: <Pine.LNX.4.10.10603290932070.26409-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10603290932070.26409-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2006 09:11:24.0125 (UTC) FILETIME=[EAF018D0:01C653D9]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

If we agree that Netconf based network managers do need notifications I wonder if the 
"increase in complexity" is really true. Yes netconf itself will be more complicated, but 
on the other hand for a manager to do configuration via netconf and receive notifications 
via something else (e.g. syslog) seems complicated as well.
Balazs

David T. Perkins wrote:
> Note that I realize that the above benefits come
> with costs, and they include:
> 1) an increase in complexity of the NETCONF protocol

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Thu Mar 30 05:04:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOu0X-0006kU-CX
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 05:04:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOu0W-0002nx-Ss
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 05:04:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOtwF-0008zm-Cf
	for netconf-data@psg.com; Thu, 30 Mar 2006 09:59:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOtwE-0008zY-9C
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 09:59:34 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F0F16C8
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 11:58:59 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 11:58:58 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 11:58:58 +0200
Message-ID: <442BABE1.6050703@ericsson.com>
Date: Thu, 30 Mar 2006 11:58:57 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: predictable content
References: <713043CE8B8E1348AF3C546DBE02C1B4079FE443@zcarhxm2.corp.nortel.com> <20060329222922.GB1132@boskop.local>
In-Reply-To: <20060329222922.GB1132@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2006 09:58:58.0614 (UTC) FILETIME=[90588D60:01C653E0]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

For me this also means that the content of the notifications should be defined as well. A 
full definition is not possible but at least a set of basic data (notification type, 
category?, sender, timestamp, human readable info string ?, alarmID etc.) could be defined 
by the protocol. (Like sender, notification type and timestamp is included in SNMP as I 
remember.)

So even if the NMS doesn't know the specific data model he can do some useful things with 
it e.g. present it, search for specific string values etc.

Balazs

Juergen Schoenwaelder wrote:
> On Wed, Mar 29, 2006 at 12:17:05PM -0500, Sharon Chisholm wrote:
>  
>> Predictable is that the consumer of the message based only on the
>> protocol definition and a definition of the data model associated with
>> the notification (XML Schema, for example) are able to predict what
>> information will be in the notification and how it will be formatted.
> 
> I assume that any reasonable data modeling language should have the
> property that notifications defined with the data modeling language
> are predictable.
> 
> I fail to see a requirement here for the development of a NETCONF
> _protocol_ extension. If I am wrong, can you please help me phrase
> this as a protocol requirement?
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Thu Mar 30 05:53:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOumF-0002NR-S0
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 05:53:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOumE-0005A6-Ir
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 05:53:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOuhb-000BZl-3o
	for netconf-data@psg.com; Thu, 30 Mar 2006 10:48:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <andy@andybierman.com>)
	id 1FOl19-000GrW-C0
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 00:28:03 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2U0S1Q3017405
	for <netconf@ops.ietf.org>; Wed, 29 Mar 2006 19:28:01 -0500
Received: (qmail 29725 invoked by uid 78); 30 Mar 2006 00:28:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 30 Mar 2006 00:28:01 -0000
Message-ID: <442B2609.7000106@andybierman.com>
Date: Wed, 29 Mar 2006 16:27:53 -0800
From: Andy Bierman <andy@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: one more requirement
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

Hi Juergen,

Thanks for starting this list.

I think we should start with the requirement
that we add just enough complexity to support
our charter of network configuration, and no more.

If netconf is to become some sort of replacement
for other NM protocols, then as Dave H. said,
we will do it with forethought and design,
not as a side-effect of the notification work.

In the meantime, our charter is network configuration,
so we need to limit the scope of our feature set accordingly.

It doesn't matter if proprietary netconf extensions exist to
do more than configuration. We have to prioritize our
work according to the WG charter.


Andy





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



From owner-netconf@ops.ietf.org Thu Mar 30 06:10:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOv2i-0007lw-5x
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:10:20 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOv2h-0005ud-Ii
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:10:20 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOuun-000COq-RC
	for netconf-data@psg.com; Thu, 30 Mar 2006 11:02:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOuum-000COf-BQ
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 11:02:08 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E3754F0001
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 13:02:07 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 13:02:06 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 13:02:06 +0200
Message-ID: <442BBAAE.6080109@ericsson.com>
Date: Thu, 30 Mar 2006 13:02:06 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
CC:  netconf@ops.ietf.org
Subject: Re: notification motivation and requirements
References: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net> <442B2D58.8040206@andybierman.com> <000801c65399$6406b260$6401a8c0@oemcomputer>
In-Reply-To: <000801c65399$6406b260$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2006 11:02:06.0485 (UTC) FILETIME=[6217CC50:01C653E9]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

Why are we speaking ONLY about unintended consequences ?

As I see it:

1) I configure something <rpc  edit-config>
2) I get back a reply <rpc-reply OK>
later
3) Due to the previous operation something happened.
Something can be a confirmation about a long running action's success (e.g. backup) or 
something unintended or anything else.

For me the question is: if the device knows that this something is connected to the 
original <rpc> it would be good if it would reference the <rpc>.

If we put the notification on the same channel as the <rpc> we can just use the 
message-id. If the <rpc> and the <notification> are on different channels than we need to 
somehow refer to the <rpc> channel (how ?) or include some device specific reference in 
the device's data model.

regards Balazs

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <ietf@andybierman.com>
>> To: "David T. Perkins" <dperkins@dsperkins.com>
>> Cc: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>; <netconf@ops.ietf.org>
>> Sent: Wednesday, March 29, 2006 4:59 PM
>> Subject: Re: notification motivation and requirements
>>
>> David T. Perkins wrote:
>>> HI,
>>>
>>> The wording is bad in my description below since it implies that
>>> present day devices can determine when resulting conditions or
>>> events are unexpected consequences of a config change.
>>>
>>> So, please change it to the following:
>>>  *) notifications that report changes in device state, or
>>>     transient events so that the mmgmt app can determine
>>>     any unexpected consequences of a configuration change.
>> Isn't this just a special-case of the general
>> requirement to provide enough info in each <notification>
>> so that it can be analyzed by an application independently
>> of the notification transport mechanism?  (Maybe that is a
>> new requirement.)
>>
>> Maybe this is what Randy means by not binding to notification
>> delivery parameters to the session.
> ...
> 
> No, David is talking about something else.  He described a
> scenario in which some way of associating a notification with
> a particular configuration request would be valuable - if we employ
> heuristics that might reasonably detected "unintended consequences"
> of configuration requests.
> 
> Where this does fit together with what I was saying is whether we
> consider it necessary for such a notification to be delivered on the
> same connection as the configuration request that caused the potential
> problems.  If we do, it's effectively an "oh, by the way, I noticed side-effects
> X, Y, and Z" after the response to a configuration request.  If we separate
> the subscription from the connection, it become "operation foo on
> netconf connection bar seems to have precipitated side-effects X, Y, and Z".
> 
> Of course, this presumes that we have a way in protocol to talk about a
> particular netconf connection.
> 
> Randy
> 
> 
> --
> 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/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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



From owner-netconf@ops.ietf.org Thu Mar 30 06:22:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOvEf-0005nJ-63
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:22:41 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOvEd-0006Ja-Q9
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:22:41 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOv7p-000DBf-6k
	for netconf-data@psg.com; Thu, 30 Mar 2006 11:15:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FOv7o-000DBR-6q
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 11:15:36 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 66769748
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 13:15:35 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 13:15:32 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 30 Mar 2006 13:15:31 +0200
Message-ID: <442BBDD3.2@ericsson.com>
Date: Thu, 30 Mar 2006 13:15:31 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Interest in notifications
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2006 11:15:32.0043 (UTC) FILETIME=[423E31B0:01C653EB]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

As I count the mails, at least we see that there is some interest in notifications.
Balazs

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



From owner-netconf@ops.ietf.org Thu Mar 30 06:42:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOvYF-0002Be-3u
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:42:55 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOvYE-0007Ea-Kd
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 06:42:55 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOvS8-000ESn-FL
	for netconf-data@psg.com; Thu, 30 Mar 2006 11:36:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [62.241.163.6] (helo=astro.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1FOvS7-000ESZ-8i
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 11:36:35 +0000
Received: from pc6 (1Cust53.tnt21.lnd4.gbr.da.uu.net [62.188.150.53])
	by astro.systems.pipex.net (Postfix) with SMTP id 9536CE0003CE;
	Thu, 30 Mar 2006 12:36:25 +0100 (BST)
Message-ID: <000901c653e5$8670e680$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>,
	"Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <44296CBC.1070606@andybierman.com> <442A3E03.3000006@ericsson.com>
Subject: real problem? was Re: no interim meeting -- read the rules
Date: Thu, 30 Mar 2006 12:33:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Wednesday, March 29, 2006 9:57 AM
Subject: Re: no interim meeting -- read the rules

> Hi,
> For us notifications are needed mostly not as a logging mechanism but as:
> - a way to notify about configuration changes
> - a way to notify the management system about delayed results of an RPC (e.g.
when an RPC
> initiated action takes 10 minutes to complete we send an immediate reply
<started> and a
> late reply <finished>)
> - to notify the network management system (NMS) about things that might need
operator
> action. (While alarm handling is mostly SNMP there is a need for some other
events to be
> handled by the NMS.)
>
> For these reasons we do need a notification mechanism. We could use
> - SNMP: but if we have an XML based hierarchical data model with meaningful
names using
> SNMP is not my choice.
> - Syslog: but the message size limit of less then 480 octets seems a problem.
Also I like
> subscription. Adding XML to syslog needs some work. We have to care about a
second
> transport/security mechanism TLS (I don't know if this is a real problem).

Yes, I suspect it is.  In a secure, distributed system, particularly one with a
large number of unattended boxes, I believe that the distribution and
maintenance of security credentials is a real problem, much complexity and
expense.

So (netconf over) ssh for configuration with the necessary notifications coming
back (over syslog) over tls.  I don't know anyone doing security that way so I
imagine it is significantly  more complex than just ssh or tls (or ipsec or
....).  Anyone know otherwise?

Agreeing with the reasons above why notifications are needed, I see this as the
reasonwhy they should be part of netconf.
If security is not needed, then no problem - lots of choice.

Tom Petch

<snip>


--
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 Mar 30 07:22:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOwAr-0004Rc-2T
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 07:22:49 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOwAp-0000b0-Hr
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 07:22:49 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOw5W-000HMk-FW
	for netconf-data@psg.com; Thu, 30 Mar 2006 12:17:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOw5V-000HMR-Cm
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 12:17:17 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UCG21A002130
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 07:16:02 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2UC13tA001969
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 07:01:04 -0500 (EST)
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: Interest in notifications
Date: Thu, 30 Mar 2006 14:17:12 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C2E9@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interest in notifications
Thread-Index: AcZT69OstrFnEynGTHS+BJyjqMOD6AAB8jZg
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

There certainly seems to be interest in discussing about notifications.
Let us see how this translates into doing work on requirements and
solutions for notifications - meaning writing drafts, reviewing and
working to get consensus until the documents are ready to ship.=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
> Sent: Thursday, March 30, 2006 1:16 PM
> To: Netconf (E-mail)
> Subject: Interest in notifications
>=20
> As I count the mails, at least we see that there is some=20
> interest in notifications.
> Balazs
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Thu Mar 30 08:16:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOx15-0004bO-Es
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:16:47 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOx14-0003Ds-1t
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:16:47 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOwxH-000KvA-1r
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:12:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FOwxG-000Kuw-Bs
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:12:50 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 434056D
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 15:12:49 +0200 (CEST)
Date: Thu, 30 Mar 2006 15:12:40 +0200 (CEST)
Message-Id: <20060330.151240.52886150.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: get-config and :url
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hi,

I don't think this has been up before.  It's another schema/text
mismatch.

In the XSD, get-config's source is defined as:

     <xs:complexType name="getConfigSourceType">
       <xs:choice>
         <xs:element ref="config-name"/>
         <xs:element name="url" type="configURIType"/>
       </xs:choice>
     </xs:complexType>

I.e. an <url> is acceptable.  However, the text doesn't mention this,
neither in 7.1 nor 8.8.

I suspect the text is correct?


/martin

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



From owner-netconf@ops.ietf.org Thu Mar 30 08:17:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOx1y-00050K-QU
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:17:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOx1y-0003Jf-HC
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:17:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOwyi-000L1g-S6
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:14:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOwyh-000L1R-G6
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:14:19 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2UDEGG28106
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 08:14:16 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Second Example in section 7.2 of netconf-proto
Date: Thu, 30 Mar 2006 08:14:15 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Second Example in section 7.2 of netconf-proto
Thread-Index: AcZDiKbaQojv6Q07Q62fULBiPoa2SAP0En3A
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

hi

Did we agree we were adding this clarifying text as a note to the RFC
editor?

Also, another clarifying question. If I have a record with a key and I
send it a replace command, are the non-key fields not included in the
replace snippet deleted or just not modified? I've seen one
implementations that does the latter, and I think based on the following
excerpt it is what is expected, but I wanted to confirm.

"Unlike a <copy-config> operation, which replaces
the entire target configuration, only the configuration
actually present in the config parameter is affected."

<bowler>
<name>Fred</name>
<location>Bedrock</location>
<status>single</status>
</bowler>

+

<bowler operation=3D"replace">
<name>Fred</name>
<status>married</status>
</bowler>

=3D

<bowler>
<name>Fred</name>
<location>Bedrock</location>
<status>married</status>
</bowler>

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Thursday, March 09, 2006 9:50 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Second Example in section 7.2 of netconf-proto


Sharon Chisholm wrote:
> hi
>
> In section 7.2, the second example indicates it will add an interface,

> but uses the operator of replace. The definition of replace does not=20
> actually say that if the entry does not exist, it is created. Should=20
> it, or should the operator of create be used instead in this example?
>
> I also wonder with these examples if there is an implicit assumption=20
> that the key is name and this somehow defines whether something exists

> or not?
>
>  =20

How about some text that says:

"The manager must understand the data model being used.
In these examples, the manager knows a priori that the 'name' element is
used for instance identification to distinguish multiple instances of
the 'interface' element.


<clip>

--
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 Mar 30 08:22:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOx6X-0000cu-0r
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:22:25 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOx6W-0003RS-Nu
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:22:25 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOx0H-000LAV-D4
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:15:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOx0G-000LAI-Oi
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:15:56 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UDEh4j023712
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 08:14:44 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2UCxeXF013790
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 07:59:41 -0500 (EST)
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: real problem? was Re: no interim meeting -- read the rules
Date: Thu, 30 Mar 2006 15:15:49 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C381@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: real problem? was Re: no interim meeting -- read the rules
Thread-Index: AcZT7l4UksDM17lgQHmJ+QyXWZ6P1AADSwCA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>,
        "Balazs Lengyel" <balazs.lengyel@ericsson.com>,
        "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f



=20
=20

> -----Original Message-----
>> We have to care=20
> > about a
> second
> > transport/security mechanism TLS (I don't know if this is a=20
> real problem).
>=20
> Yes, I suspect it is.  In a secure, distributed system,=20
> particularly one with a large number of unattended boxes, I=20
> believe that the distribution and maintenance of security=20
> credentials is a real problem, much complexity and expense.
>=20
> So (netconf over) ssh for configuration with the necessary=20
> notifications coming back (over syslog) over tls.  I don't=20
> know anyone doing security that way so I imagine it is=20
> significantly  more complex than just ssh or tls (or ipsec or=20
> ....).  Anyone know otherwise?
>=20

What exactly are the security credentials for? Is this about
authentication of the notification sender with the receiver? If so, this
is similar with the case that we encountered recently with the
authentication of the data sources with the collectors in raqmon. Andy
knows it too well.=20

Dan


--
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 Mar 30 08:31:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxEz-0005EB-G8
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:31:09 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxEx-0003oF-Vz
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:31:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOx9Z-000LsB-RR
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:25:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOx9Y-000Lrq-9f
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:25:32 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 88E2F55E5A;
	Thu, 30 Mar 2006 15:25:31 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 28389-09; Thu, 30 Mar 2006 15:25:29 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 8659C55E4D;
	Thu, 30 Mar 2006 15:25:28 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 1086464FB9A; Thu, 30 Mar 2006 15:25:26 +0200 (CEST)
Date: Thu, 30 Mar 2006 15:25:26 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: netconf@ops.ietf.org
Subject: Re: predictable content
Message-ID: <20060330132526.GA1840@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
	netconf@ops.ietf.org
References: <713043CE8B8E1348AF3C546DBE02C1B4079FE443@zcarhxm2.corp.nortel.com> <20060329222922.GB1132@boskop.local> <442BABE1.6050703@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <442BABE1.6050703@ericsson.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

On Thu, Mar 30, 2006 at 11:58:57AM +0200, Balazs Lengyel wrote:

> For me this also means that the content of the notifications should
> be defined as well. A full definition is not possible but at least a
> set of basic data (notification type, category?, sender, timestamp,
> human readable info string ?, alarmID etc.) could be defined by the
> protocol. (Like sender, notification type and timestamp is included
> in SNMP as I remember.)

SNMPv1 indeed did this but the idea was weakened with the introduction
of SNMPv2 PDU formats some 12+ years ago since only the notification
name (its OID) and the sysUpTime timestamp is required to be shipped
in the varbind list (and note that sysUpTime is the time since the
network management portion of the system was last re-initialized).
The identification of the sender got reintroduced in SNMPv3 by means
of the (context-engine-id, context-name) pair, in particular to handle
proxy situations (but I hope NETCONF avoids dealing with proxies).
 
> So even if the NMS doesn't know the specific data model he can do
> some useful things with it e.g. present it, search for specific
> string values etc.

You are proposing to hard-wire a portion of a data model into the
protocol. So far, NETCONF tried to avoid this and the question would
be where to stop.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Thu Mar 30 08:41:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxP1-0008O2-Sz
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:41:31 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxP0-00047Y-DB
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:41:31 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOxL2-000Md1-De
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:37:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FOxL1-000Mck-FQ
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:37:23 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2UDZkSe020047
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 08:35:46 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2UDYCFA004579
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 08:34:12 -0500 (EST)
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: Second Example in section 7.2 of netconf-proto
Date: Thu, 30 Mar 2006 15:37:20 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C3C0@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Second Example in section 7.2 of netconf-proto
Thread-Index: AcZDiKbaQojv6Q07Q62fULBiPoa2SAP0En3AACmG19A=
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Sharon Chisholm" <schishol@nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365

The note that was sent to the RFC editor reads like this:

Page 39, bottom:

OLD:

   Example:

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:

NEW:

   Example:

       The <edit-config> examples in this section utilize a simple
       data model, in which multiple instances of the 'interface'
       element may be present, and an instance is distinguished
       by the 'name' element within each 'interface' element.

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:

I believe that it passes the message, although it is placed differently
than initially discussed (the first example in 7.2 rather than the
second)

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Thursday, March 30, 2006 3:14 PM
> To: Netconf (E-mail)
> Subject: RE: Second Example in section 7.2 of netconf-proto
>=20
> hi
>=20
> Did we agree we were adding this clarifying text as a note to=20
> the RFC editor?
>=20
> Also, another clarifying question. If I have a record with a=20
> key and I send it a replace command, are the non-key fields=20
> not included in the replace snippet deleted or just not=20
> modified? I've seen one implementations that does the latter,=20
> and I think based on the following excerpt it is what is=20
> expected, but I wanted to confirm.
>=20
> "Unlike a <copy-config> operation, which replaces the entire=20
> target configuration, only the configuration actually present=20
> in the config parameter is affected."
>=20
> <bowler>
> <name>Fred</name>
> <location>Bedrock</location>
> <status>single</status>
> </bowler>
>=20
> +
>=20
> <bowler operation=3D"replace">
> <name>Fred</name>
> <status>married</status>
> </bowler>
>=20
> =3D
>=20
> <bowler>
> <name>Fred</name>
> <location>Bedrock</location>
> <status>married</status>
> </bowler>
>=20
> Sharon
>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Thursday, March 09, 2006 9:50 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Cc: Netconf (E-mail)
> Subject: Re: Second Example in section 7.2 of netconf-proto
>=20
>=20
> Sharon Chisholm wrote:
> > hi
> >
> > In section 7.2, the second example indicates it will add an=20
> interface,
>=20
> > but uses the operator of replace. The definition of replace=20
> does not=20
> > actually say that if the entry does not exist, it is=20
> created. Should=20
> > it, or should the operator of create be used instead in=20
> this example?
> >
> > I also wonder with these examples if there is an implicit=20
> assumption=20
> > that the key is name and this somehow defines whether=20
> something exists
>=20
> > or not?
> >
> >  =20
>=20
> How about some text that says:
>=20
> "The manager must understand the data model being used.
> In these examples, the manager knows a priori that the 'name'=20
> element is
> used for instance identification to distinguish multiple instances of
> the 'interface' element.
>=20
>=20
> <clip>
>=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

--
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 Mar 30 08:59:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxgr-00061P-5w
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:59:57 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxgq-0004nb-TX
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 08:59:57 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOxbd-000NmY-G4
	for netconf-data@psg.com; Thu, 30 Mar 2006 13:54:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOxbc-000NmK-GG
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:54:32 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2UDsSu24161
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 08:54:28 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Thu, 30 Mar 2006 08:54:12 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4079FEF6D@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZTgJd/l6Yw8FwQSK2fnFblcEX99gAgHAGg
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

hi

<Juergen>

I assume that any reasonable data modeling language should have the
property that notifications defined with the data modeling language are
predictable.

I fail to see a requirement here for the development of a NETCONF
_protocol_ extension. If I am wrong, can you please help me phrase this
as a protocol requirement?
</Juergen>

Well, there are people who will be evaluating existing solutions against
these requirements, so I'd prefer to have it in there with a note that
in Netconf this is part of the content layer, not the protocol
operations. We will need to have a sense of *how* predictable content
comes into being, even if it is does in the data model.


<Juergen>

So what is the distinction between an event class and an event type?

</Juergen>
There isn't one.

Sharon

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



From owner-netconf@ops.ietf.org Thu Mar 30 09:12:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxsr-0001bP-IK
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 09:12:21 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxsq-0005hP-8a
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 09:12:21 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOxoT-000Ody-Lr
	for netconf-data@psg.com; Thu, 30 Mar 2006 14:07:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FOxoS-000Odl-Qi
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 14:07:48 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 2651E55CA6;
	Thu, 30 Mar 2006 16:07:48 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 00586-05; Thu, 30 Mar 2006 16:07:46 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 66DD455BD8;
	Thu, 30 Mar 2006 16:07:46 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 0033E64FC70; Thu, 30 Mar 2006 16:07:44 +0200 (CEST)
Date: Thu, 30 Mar 2006 16:07:44 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Sharon Chisholm <schishol@nortel.com>
Cc: netconf@ops.ietf.org
Subject: Re: Why are we doing netconf?
Message-ID: <20060330140744.GB1960@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Sharon Chisholm <schishol@nortel.com>,
	netconf@ops.ietf.org
References: <713043CE8B8E1348AF3C546DBE02C1B4079FEF6D@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4079FEF6D@zcarhxm2.corp.nortel.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

On Thu, Mar 30, 2006 at 08:54:12AM -0500, Sharon Chisholm wrote:
 
> <Juergen>
> 
> I assume that any reasonable data modeling language should have the
> property that notifications defined with the data modeling language are
> predictable.
> 
> I fail to see a requirement here for the development of a NETCONF
> _protocol_ extension. If I am wrong, can you please help me phrase this
> as a protocol requirement?
> </Juergen>
> 
> Well, there are people who will be evaluating existing solutions against
> these requirements, so I'd prefer to have it in there with a note that
> in Netconf this is part of the content layer, not the protocol
> operations. We will need to have a sense of *how* predictable content
> comes into being, even if it is does in the data model.

So are you saying you want to have a requirement which says:

* solution should leave the definition of notification formats 
  to the data models

I am not really sure I captured the idea here...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Thu Mar 30 09:14:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxvL-0002cb-61
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 09:14:55 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxvK-0005sV-TI
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 09:14:55 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOxrm-000Oty-2w
	for netconf-data@psg.com; Thu, 30 Mar 2006 14:11:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FOxrl-000Otn-9w
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 14:11:13 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2UEBAG07569
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 09:11:10 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why are we doing netconf?
Date: Thu, 30 Mar 2006 09:11:10 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4079FEFE3@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZUA1atc2Hwr91BSJiizYBynmsBSwAADh5g
From: "Sharon Chisholm" <schishol@nortel.com>
To: <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

<Juergen>
> Well, there are people who will be evaluating existing solutions=20
> against these requirements, so I'd prefer to have it in there with a=20
> note that in Netconf this is part of the content layer, not the=20
> protocol operations. We will need to have a sense of *how* predictable

> content comes into being, even if it is does in the data model.

So are you saying you want to have a requirement which says:

* solution should leave the definition of notification formats=20
  to the data models

I am not really sure I captured the idea here...

</Juergen>

More like

* solutions should provide the ability to specify the content of
notifications to ensure predictability. This can be done via a data
model definition.

Sharon

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



From owner-netconf@ops.ietf.org Thu Mar 30 11:09:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOzhu-0006BO-Qi
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:09:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOzhu-0003ec-Gi
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:09:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOzdK-0005rb-Qa
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:04:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <andy@andybierman.com>)
	id 1FOyqN-0002tL-UB
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 15:13:52 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UF1Tts019702
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 10:01:29 -0500
Received: (qmail 24774 invoked by uid 78); 30 Mar 2006 15:01:29 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 30 Mar 2006 15:01:29 -0000
Message-ID: <442BF2C1.5060001@andybierman.com>
Date: Thu, 30 Mar 2006 07:01:21 -0800
From: Andy Bierman <andy@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: requirement: agent initiated session support
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

Hi,

The current subscribe model does not support agent
initiated sessions at all.  There are 2 use cases
I think are important:

1) notification generator application
   Traditional model as in SNMP.
   Agent SW dedicated to notification generation
   (maybe an aggregator for multiple sub-agents)
   Agent connects to the notification receiver application
   and sends notifications as they are generated.

2) bootstrap (thin agent)
   Agent is initially configured with a
  (username, password, cofig-server-IP-addr) tuple.
  Agent boots and immediately connects to the config-server
  (manager role in netconf), and issues a <configure-me>
  notification (perhaps with some parameters). The config
  server then issues <rpc> edit-config or copy-config
  commands to finish bootstrapping the agent.


Boot-up Problem with Subscribe model:

Using the client-subscribe model, all of the initial
notifications generated upon system reboot will be
lost because the agent isn't connected to a manager
yet, and we have no NOTIFICATION-LOG-MIB.  Requiring
the agent to save all notifications because a manager
might connect someday and request them is a huge
memory burden and not likely to be supported.

In general, I don't really see the subscription model
as an improvement over the traditional configuration
data model approach.  Even when used in the client-initiated
mode, it isn't as efficient because the manager has to
re-enter the config-data every time (in the form of a
start-notifications RPC).  If the profile wasn't opaque
that could be used instead.

Andy






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



From owner-netconf@ops.ietf.org Thu Mar 30 11:14:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOzmb-0007ei-6X
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:14:01 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOzma-0003yV-Sn
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:14:01 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOzdU-0005rz-3f
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:04:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FOyvV-0003Cs-AI
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 15:19:09 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UFJ7kQ016830
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 10:19:08 -0500
Received: (qmail 22264 invoked by uid 78); 30 Mar 2006 15:19:07 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 30 Mar 2006 15:19:07 -0000
Message-ID: <442BF6E3.90606@andybierman.com>
Date: Thu, 30 Mar 2006 07:18:59 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: requirement: agent initiated session support
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

Hi,

The current subscribe model does not support agent
initiated sessions at all.  There are 2 use cases
I think are important:

1) notification generator application
   Traditional model as in SNMP.
   Agent SW dedicated to notification generation
   (maybe an aggregator for multiple sub-agents)
   Agent connects to the notification receiver application
   and sends notifications as they are generated.

2) bootstrap (thin agent)
   Agent is initially configured with a
  (username, password, cofig-server-IP-addr) tuple.
  Agent boots and immediately connects to the config-server
  (manager role in netconf), and issues a <configure-me>
  notification (perhaps with some parameters). The config
  server then issues <rpc> edit-config or copy-config
  commands to finish bootstrapping the agent.


Boot-up Problem with Subscribe model:

Using the client-subscribe model, all of the initial
notifications generated upon system reboot will be
lost because the agent isn't connected to a manager
yet, and we have no NOTIFICATION-LOG-MIB.  Requiring
the agent to save all notifications because a manager
might connect someday and request them is a huge
memory burden and not likely to be supported.

In general, I don't really see the subscription model
as an improvement over the traditional configuration
data model approach.  Even when used in the client-initiated
mode, it isn't as efficient because the manager has to
re-enter the config-data every time (in the form of a
start-notifications RPC).  If the profile wasn't opaque
that could be used instead.

Andy







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



From owner-netconf@ops.ietf.org Thu Mar 30 11:26:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOzyG-0005dM-QD
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:26:04 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOzyG-0004Vy-DD
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:26:04 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FOzt3-0006xA-GK
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:20:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FOzt0-0006wS-HI
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 16:20:38 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 9510D6B;
	Thu, 30 Mar 2006 18:20:37 +0200 (CEST)
Date: Thu, 30 Mar 2006 18:20:28 +0200 (CEST)
Message-Id: <20060330.182028.133006965.mbj@tail-f.com>
To: schishol@nortel.com
Cc: netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

"Sharon Chisholm" <schishol@nortel.com> wrote:
> Also, another clarifying question. If I have a record with a key and I
> send it a replace command, are the non-key fields not included in the
> replace snippet deleted or just not modified? I've seen one
> implementations that does the latter, and I think based on the following
> excerpt it is what is expected, but I wanted to confirm.
> 
> "Unlike a <copy-config> operation, which replaces
> the entire target configuration, only the configuration
> actually present in the config parameter is affected."
> 
> <bowler>
> <name>Fred</name>
> <location>Bedrock</location>
> <status>single</status>
> </bowler>
> 
> +
> 
> <bowler operation="replace">
> <name>Fred</name>
> <status>married</status>
> </bowler>
> 
> =
> 
> <bowler>
> <name>Fred</name>
> <location>Bedrock</location>
> <status>married</status>
> </bowler>


Ok, I'll share my interpretation.

I think it should delete the non-present part (provided they are
optional of course).  What you're doing above would be the result of a
"merge" operation.

This also hold if you have more levels in your config:

<bowler>
  <name>Fred</name>
  <status>married</status>
  <cars>
    <car>
      <id>ABC-123</id>
      <make>volvo</make>
    </car>
  </cars>
</bowler>

+

<bowler operation="replace">
  <name>Fred</name>
  <status>married</status>
  <cars>
    <car>
      <id>DEF-456</id>
      <make>saab</make>
    </car>
  </cars>
</bowler>

=

<bowler operation="replace">
  <name>Fred</name>
  <status>married</status>
  <cars>
    <car>
      <id>DEF-456</id>
      <make>saab</make>
    </car>
  </cars>
</bowler>



/martin

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



From owner-netconf@ops.ietf.org Thu Mar 30 11:47:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0JG-0001aW-J3
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:47:46 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0JG-0005Od-6d
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:47:46 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0Fi-0008Wt-6u
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:44:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP0Fh-0008Wg-CN
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 16:44:05 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UGi3Q3011217
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 11:44:04 -0500
Received: (qmail 18926 invoked by uid 78); 30 Mar 2006 16:44:03 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 30 Mar 2006 16:44:03 -0000
Message-ID: <442C0AC6.3020804@andybierman.com>
Date: Thu, 30 Mar 2006 08:43:50 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com> <20060330.182028.133006965.mbj@tail-f.com>
In-Reply-To: <20060330.182028.133006965.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027

Martin Bjorklund wrote:

IMO:

If the agent data model has sub-trees that are
not included in the 'replace' subtrees, then they
are not touched.  Only the agent data model subtrees
explicitly included in the replace-subtrees are touched.

At least that's what I meant when I wrote the original text.

Both of the examples below are correct.

In order to remove optional subtrees in the same edit-config,
appropriately placed operation="delete" attributes are needed.

Andy


> "Sharon Chisholm" <schishol@nortel.com> wrote:
>> Also, another clarifying question. If I have a record with a key and I
>> send it a replace command, are the non-key fields not included in the
>> replace snippet deleted or just not modified? I've seen one
>> implementations that does the latter, and I think based on the following
>> excerpt it is what is expected, but I wanted to confirm.
>>
>> "Unlike a <copy-config> operation, which replaces
>> the entire target configuration, only the configuration
>> actually present in the config parameter is affected."
>>
>> <bowler>
>> <name>Fred</name>
>> <location>Bedrock</location>
>> <status>single</status>
>> </bowler>
>>
>> +
>>
>> <bowler operation="replace">
>> <name>Fred</name>
>> <status>married</status>
>> </bowler>
>>
>> =
>>
>> <bowler>
>> <name>Fred</name>
>> <location>Bedrock</location>
>> <status>married</status>
>> </bowler>
> 
> 
> Ok, I'll share my interpretation.
> 
> I think it should delete the non-present part (provided they are
> optional of course).  What you're doing above would be the result of a
> "merge" operation.
> 
> This also hold if you have more levels in your config:
> 
> <bowler>
>   <name>Fred</name>
>   <status>married</status>
>   <cars>
>     <car>
>       <id>ABC-123</id>
>       <make>volvo</make>
>     </car>
>   </cars>
> </bowler>
> 
> +
> 
> <bowler operation="replace">
>   <name>Fred</name>
>   <status>married</status>
>   <cars>
>     <car>
>       <id>DEF-456</id>
>       <make>saab</make>
>     </car>
>   </cars>
> </bowler>
> 
> =
> 
> <bowler operation="replace">
>   <name>Fred</name>
>   <status>married</status>
>   <cars>
>     <car>
>       <id>DEF-456</id>
>       <make>saab</make>
>     </car>
>   </cars>
> </bowler>
> 
> 
> 
> /martin
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 30 11:59:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0UO-0001In-41
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:59:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0UM-0005wU-RK
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 11:59:16 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0RM-0009RX-QX
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:56:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP0RL-0009RG-Lq
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 16:56:07 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2UGu6Zj029924
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 11:56:06 -0500
Received: (qmail 19056 invoked by uid 78); 30 Mar 2006 16:56:05 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 30 Mar 2006 16:56:05 -0000
Message-ID: <442C0D9E.3070401@andybierman.com>
Date: Thu, 30 Mar 2006 08:55:58 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: NETCONF over TLS?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

Hi,

Somebody sent me an email and asked if the WG was
interested in NETCONF over TLS.  I said probably
not.  This morning I saw this I-D in Last Call
to supply a user name to TLS, an obvious missing
component is you want to support a user-based
access-control model (and I do).

http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-04.txt

So now I am curious (but not enough to standardize
anything) if the secure syslog integration with netconf
over TLS makes security and operational sense.


Andy


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



From owner-netconf@ops.ietf.org Thu Mar 30 12:01:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0WE-0004IS-7K
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:01:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0WD-00060o-UF
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:01:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0TC-0009aD-IY
	for netconf-data@psg.com; Thu, 30 Mar 2006 16:58:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FP0TB-0009Zy-SS
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 16:58:01 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by test-iport-1.cisco.com with ESMTP; 30 Mar 2006 08:58:01 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2UGw1Gv008511;
	Thu, 30 Mar 2006 08:58:01 -0800 (PST)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4358.cisco.com [10.61.81.5])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2UGwSub008691;
	Thu, 30 Mar 2006 08:58:28 -0800
Message-ID: <442C0E16.3010608@cisco.com>
Date: Thu, 30 Mar 2006 18:57:58 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: NETCONF over TLS?
References: <442C0D9E.3070401@andybierman.com>
In-Reply-To: <442C0D9E.3070401@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=853; t=1143737909; x=1144170109;
	c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20NETCONF=20over=20TLS?
	|To:Andy=20Bierman=20<ietf@andybierman.com>;
	X=v=3Dmtcc.com=3B=20h=3D/Pi95qArLRsV/KpBwvTYQswsifc=3D; b=Y92iMeDWmcAGCo0BL7PxK/f4q9v+SaipMSgh/6lFh8PFZ6eNZA0Xwbiwc4V7ntbIdz07So54
	8qNst6A94kP4aGoohsadaLIiWEzmB8NZwi6N8J7wQfPeAUduPnUD6Ct7SQ+poH+j68C9zqzPz1i
	UOFDUtCdELyXXfAE7RA1CKfs=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

There's no reason you couldn't do this with TLS/BEEP, right?

Eliot

Andy Bierman wrote:
> Hi,
>
> Somebody sent me an email and asked if the WG was
> interested in NETCONF over TLS.  I said probably
> not.  This morning I saw this I-D in Last Call
> to supply a user name to TLS, an obvious missing
> component is you want to support a user-based
> access-control model (and I do).
>
> http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-04.txt
>
> So now I am curious (but not enough to standardize
> anything) if the secure syslog integration with netconf
> over TLS makes security and operational sense.
>
>
> Andy
>
>
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Thu Mar 30 12:04:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0Zf-0005xS-C6
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:04:43 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0Ze-0006Fu-VP
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:04:43 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0W4-0009qe-8B
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:01:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FP0W2-0009qM-Un
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:00:59 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 13C236B;
	Thu, 30 Mar 2006 19:00:58 +0200 (CEST)
Date: Thu, 30 Mar 2006 19:00:49 +0200 (CEST)
Message-Id: <20060330.190049.00470349.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <442C0AC6.3020804@andybierman.com>
References: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com>
	<20060330.182028.133006965.mbj@tail-f.com>
	<442C0AC6.3020804@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> 
> IMO:
> 
> If the agent data model has sub-trees that are
> not included in the 'replace' subtrees, then they
> are not touched.  Only the agent data model subtrees
> explicitly included in the replace-subtrees are touched.
> 
> At least that's what I meant when I wrote the original text.

An example:

  <bowler xmlns="urn:foo">
    <name>Fred</name>
    <status>married</status>
    <cars>
      <car>
        <id>ABC-123</id>
        <make>volvo</make>
      </car>
    </cars>
  </bowler>
  <interfaces>
    <interface>
       <name>eth0</name>
       <ip>10.0.0.1</ip>
    </interface>
  </interfaces>
    
+
 
 <bowler operation="replace">
   <name>Fred</name>
   <status>divorced</status>
 </bowler>

= 

  <bowler xmlns="urn:foo">
    <name>Fred</name>
    <status>divorced</status>
  </bowler>
  <interfaces>
    <interface>
       <name>eth0</name>
       <ip>10.0.0.1</ip>
    </interface>
  </interfaces>

I.e. the subtree "interfaces" is left untouched, but the "bowler"
subtree completely replaced.

Is this what you meant?  (that's what I meant anyway...)



/martin




> 
> Andy
> 
> 
> > "Sharon Chisholm" <schishol@nortel.com> wrote:
> >> Also, another clarifying question. If I have a record with a key and I
> >> send it a replace command, are the non-key fields not included in the
> >> replace snippet deleted or just not modified? I've seen one
> >> implementations that does the latter, and I think based on the following
> >> excerpt it is what is expected, but I wanted to confirm.
> >>
> >> "Unlike a <copy-config> operation, which replaces
> >> the entire target configuration, only the configuration
> >> actually present in the config parameter is affected."
> >>
> >> <bowler>
> >> <name>Fred</name>
> >> <location>Bedrock</location>
> >> <status>single</status>
> >> </bowler>
> >>
> >> +
> >>
> >> <bowler operation="replace">
> >> <name>Fred</name>
> >> <status>married</status>
> >> </bowler>
> >>
> >> =
> >>
> >> <bowler>
> >> <name>Fred</name>
> >> <location>Bedrock</location>
> >> <status>married</status>
> >> </bowler>
> > 
> > 
> > Ok, I'll share my interpretation.
> > 
> > I think it should delete the non-present part (provided they are
> > optional of course).  What you're doing above would be the result of a
> > "merge" operation.
> > 
> > This also hold if you have more levels in your config:
> > 
> > <bowler>
> >   <name>Fred</name>
> >   <status>married</status>
> >   <cars>
> >     <car>
> >       <id>ABC-123</id>
> >       <make>volvo</make>
> >     </car>
> >   </cars>
> > </bowler>
> > 
> > +
> > 
> > <bowler operation="replace">
> >   <name>Fred</name>
> >   <status>married</status>
> >   <cars>
> >     <car>
> >       <id>DEF-456</id>
> >       <make>saab</make>
> >     </car>
> >   </cars>
> > </bowler>
> > 
> > =
> > 
> > <bowler operation="replace">
> >   <name>Fred</name>
> >   <status>married</status>
> >   <cars>
> >     <car>
> >       <id>DEF-456</id>
> >       <make>saab</make>
> >     </car>
> >   </cars>
> > </bowler>
> > 
> > 
> > 
> > /martin
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <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 Thu Mar 30 12:04:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0Zv-00066k-7D
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:04:59 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0Zu-0006GS-UN
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:04:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0Wi-0009uV-Bu
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:01:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP0Wf-0009u6-Ry
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:01:38 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UH1ZQ3002424
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 12:01:35 -0500
Received: (qmail 2927 invoked by uid 78); 30 Mar 2006 17:01:35 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 30 Mar 2006 17:01:35 -0000
Message-ID: <442C0EE8.3020204@andybierman.com>
Date: Thu, 30 Mar 2006 09:01:28 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: NETCONF over TLS?
References: <442C0D9E.3070401@andybierman.com> <442C0E16.3010608@cisco.com>
In-Reply-To: <442C0E16.3010608@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

Eliot Lear wrote:
> There's no reason you couldn't do this with TLS/BEEP, right?

Right.
So we already have this covered, except you
have to implement BEEP.  I think that was
the point of the original question.  Like I said,
just curious -- not trying to create new work at all.


> 
> Eliot

Andy

> 
> Andy Bierman wrote:
>> Hi,
>>
>> Somebody sent me an email and asked if the WG was
>> interested in NETCONF over TLS.  I said probably
>> not.  This morning I saw this I-D in Last Call
>> to supply a user name to TLS, an obvious missing
>> component is you want to support a user-based
>> access-control model (and I do).
>>
>> http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-04.txt
>>
>> So now I am curious (but not enough to standardize
>> anything) if the secure syslog integration with netconf
>> over TLS makes security and operational sense.
>>
>>
>> Andy
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <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 Thu Mar 30 12:09:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0do-0007h1-Bf
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:09:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0dn-0006Rh-0F
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:09:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0Zk-000AB3-PK
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:04:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FP0Zk-000AAo-4H
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:04:48 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2UH4l1Z036981;
	Thu, 30 Mar 2006 09:04:47 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2UH4l593845;
	Thu, 30 Mar 2006 09:04:47 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2UHA0YE065379;
	Thu, 30 Mar 2006 12:10:00 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603301710.k2UHA0YE065379@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
cc: netconf@ops.ietf.org
Subject: Re: get-config and :url 
In-Reply-To: Your message of "Thu, 30 Mar 2006 15:12:40 +0200."
             <20060330.151240.52886150.mbj@tail-f.com> 
Date: Thu, 30 Mar 2006 12:10:00 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Yup, looks like the schema's in error.  You can copy-config
an url, but not get-config it.

Thanks,
 Phil

Martin Bjorklund writes:
>Hi,
>
>I don't think this has been up before.  It's another schema/text
>mismatch.
>
>In the XSD, get-config's source is defined as:
>
>     <xs:complexType name="getConfigSourceType">
>       <xs:choice>
>         <xs:element ref="config-name"/>
>         <xs:element name="url" type="configURIType"/>
>       </xs:choice>
>     </xs:complexType>
>
>I.e. an <url> is acceptable.  However, the text doesn't mention this,
>neither in 7.1 nor 8.8.
>
>I suspect the text is correct?
>
>
>/martin
>
>--
>to unsubscribe send a message to netconf-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <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 Thu Mar 30 12:12:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0hc-0000tT-6L
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:12:56 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0hb-0006eP-T2
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:12:56 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0e1-000AdK-QY
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:09:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP0e1-000Ad8-5y
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:09:13 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UH9BkQ002089
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 12:09:11 -0500
Received: (qmail 27672 invoked by uid 78); 30 Mar 2006 17:09:11 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 30 Mar 2006 17:09:11 -0000
Message-ID: <442C10AB.7060501@andybierman.com>
Date: Thu, 30 Mar 2006 09:08:59 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <713043CE8B8E1348AF3C546DBE02C1B4079FEEB0@zcarhxm2.corp.nortel.com>	<20060330.182028.133006965.mbj@tail-f.com>	<442C0AC6.3020804@andybierman.com> <20060330.190049.00470349.mbj@tail-f.com>
In-Reply-To: <20060330.190049.00470349.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>
>> IMO:
>>
>> If the agent data model has sub-trees that are
>> not included in the 'replace' subtrees, then they
>> are not touched.  Only the agent data model subtrees
>> explicitly included in the replace-subtrees are touched.
>>
>> At least that's what I meant when I wrote the original text.
> 
> An example:
> 
>   <bowler xmlns="urn:foo">
>     <name>Fred</name>
>     <status>married</status>
>     <cars>
>       <car>
>         <id>ABC-123</id>
>         <make>volvo</make>
>       </car>
>     </cars>
>   </bowler>
>   <interfaces>
>     <interface>
>        <name>eth0</name>
>        <ip>10.0.0.1</ip>
>     </interface>
>   </interfaces>
>     
> +
>  
>  <bowler operation="replace">
>    <name>Fred</name>
>    <status>divorced</status>
>  </bowler>



To come up the the result that follows,
you need to do:

   <bowler operation="replace">
    <name>Fred</name>
    <status>divorced</status>
    <cars operation="delete"/>
   </bowler>


Otherwise the 'cars' element is untouched.
The 'interfaces' data model (and all the other
sibling subtrees not included in the replace-subtrees)
are not affected whatsoever by an operation="replace".
This is the whole point of using an operation attribute
placed in the root of the subtree to be affected.


> 
> = 
> 
>   <bowler xmlns="urn:foo">
>     <name>Fred</name>
>     <status>divorced</status>
>   </bowler>
>   <interfaces>
>     <interface>
>        <name>eth0</name>
>        <ip>10.0.0.1</ip>
>     </interface>
>   </interfaces>
> 
> I.e. the subtree "interfaces" is left untouched, but the "bowler"
> subtree completely replaced.
> 
> Is this what you meant?  (that's what I meant anyway...)
> 
> 
> 
> /martin
> 
> 
> 

Andy

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



From owner-netconf@ops.ietf.org Thu Mar 30 12:21:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0pj-0002Hz-I4
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:21:19 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0pj-0006uX-9V
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:21:19 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0lx-000BJw-Qr
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:17:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FP0lw-000BJV-5m
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:17:24 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 9CD566D
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 19:17:22 +0200 (CEST)
Date: Thu, 30 Mar 2006 19:17:14 +0200 (CEST)
Message-Id: <20060330.191714.19863895.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: another schema issue
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

I didn't quite understand all implications of configInlineType:

     <!--
       Type for <config> element
       -->
     <xs:complexType name="configInlineType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="config" type="configInlineType"/>


so I tried to validate an edit-config message with the schema in the
draft and xmllint.

It complained and said that the <config> element's type is empty,
which makes sense I suppose.  There's a restriction on anyType which
restricts it to nothing.


Shouldn't the "config" element (all all others alike) be defined as:

         <xs:element name="config" type="xs:anyType"/>


What do I miss?


/martin





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



From owner-netconf@ops.ietf.org Thu Mar 30 12:24:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0sM-0002bd-SE
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:24:02 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0sM-00072n-IV
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:24:02 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0pH-000Bfw-Be
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:20:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FP0pG-000Bfl-Lj
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:20:50 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id DAE406B;
	Thu, 30 Mar 2006 19:20:49 +0200 (CEST)
Date: Thu, 30 Mar 2006 19:20:41 +0200 (CEST)
Message-Id: <20060330.192041.28794077.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <442C10AB.7060501@andybierman.com>
References: <442C0AC6.3020804@andybierman.com>
	<20060330.190049.00470349.mbj@tail-f.com>
	<442C10AB.7060501@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> Martin Bjorklund wrote:
> >>
> >> IMO:
> >>
> >> If the agent data model has sub-trees that are
> >> not included in the 'replace' subtrees, then they
> >> are not touched.  Only the agent data model subtrees
> >> explicitly included in the replace-subtrees are touched.
> >>
> >> At least that's what I meant when I wrote the original text.
> > 
> > An example:
> > 
> >   <bowler xmlns="urn:foo">
> >     <name>Fred</name>
> >     <status>married</status>
> >     <cars>
> >       <car>
> >         <id>ABC-123</id>
> >         <make>volvo</make>
> >       </car>
> >     </cars>
> >   </bowler>
> >   <interfaces>
> >     <interface>
> >        <name>eth0</name>
> >        <ip>10.0.0.1</ip>
> >     </interface>
> >   </interfaces>
> >     
> > +
> >  
> >  <bowler operation="replace">
> >    <name>Fred</name>
> >    <status>divorced</status>
> >  </bowler>
> 
> 
> 
> To come up the the result that follows,
> you need to do:
> 
>    <bowler operation="replace">
>     <name>Fred</name>
>     <status>divorced</status>
>     <cars operation="delete"/>
>    </bowler>
> 
> 
> Otherwise the 'cars' element is untouched.

If this is the case, how is 'replace' different from 'merge'??

> The 'interfaces' data model (and all the other
> sibling subtrees not included in the replace-subtrees)
> are not affected whatsoever by an operation="replace".

That means that	in order to actually completely *replace* an entire
subtree (i.e. not the entire config), a manager would have to first
do a get-config to figure out all instances of all objects, then do an
edit-config where all of these instances are marked as delete, and at
the same time add the new instances?

> This is the whole point of using an operation attribute
> placed in the root of the subtree to be affected.

I agree that the operation attribute is very useful.


/martin

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



From owner-netconf@ops.ietf.org Thu Mar 30 12:30:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP0yz-00006W-7Y
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:30:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP0yx-0007Pu-TY
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:30:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0vU-000CCq-Uq
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:27:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FP0vT-000CCc-Sr
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:27:16 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k2UHRBYH026350;
	Thu, 30 Mar 2006 09:27:11 -0800
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k2UHRBAJ026339;
	Thu, 30 Mar 2006 09:27:11 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Thu, 30 Mar 2006 09:27:10 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
cc: Balazs Lengyel <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
Subject: Re: predictable content
In-Reply-To: <20060330132526.GA1840@boskop.local>
Message-ID: <Pine.LNX.4.10.10603300920580.8518-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

HI,

I think you accidentialy used an incorrect characterization
of SNMPv3's the  (context-engine-id, context-name) pair.
It is not the identity of the "sender". It is the
source of the notification. An observer can send
a NOTIFICATION reporting that an event occured on
another system, and when so would use the that
system's identifier as the source.

A proxy also uses the identification of the source
system and not it's identity.

Regards,
/david t. perkins

On Thu, 30 Mar 2006, Juergen Schoenwaelder wrote:

> On Thu, Mar 30, 2006 at 11:58:57AM +0200, Balazs Lengyel wrote:
> 
> > For me this also means that the content of the notifications should
> > be defined as well. A full definition is not possible but at least a
> > set of basic data (notification type, category?, sender, timestamp,
> > human readable info string ?, alarmID etc.) could be defined by the
> > protocol. (Like sender, notification type and timestamp is included
> > in SNMP as I remember.)
> 
> SNMPv1 indeed did this but the idea was weakened with the introduction
> of SNMPv2 PDU formats some 12+ years ago since only the notification
> name (its OID) and the sysUpTime timestamp is required to be shipped
> in the varbind list (and note that sysUpTime is the time since the
> network management portion of the system was last re-initialized).
> The identification of the sender got reintroduced in SNMPv3 by means
> of the (context-engine-id, context-name) pair, in particular to handle
> proxy situations (but I hope NETCONF avoids dealing with proxies).
>  
> > So even if the NMS doesn't know the specific data model he can do
> > some useful things with it e.g. present it, search for specific
> > string values etc.
> 
> You are proposing to hard-wire a portion of a data model into the
> protocol. So far, NETCONF tried to avoid this and the question would
> be where to stop.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


--
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 Mar 30 12:33:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP11V-00021R-FU
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:33:29 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP11V-0007So-2y
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:33:29 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP0wi-000CIa-N7
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:28:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP0wh-000CIM-Uj
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:28:32 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UHSUQ3002524
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 12:28:30 -0500
Received: (qmail 27191 invoked by uid 78); 30 Mar 2006 17:28:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 30 Mar 2006 17:28:30 -0000
Message-ID: <442C1532.1090407@andybierman.com>
Date: Thu, 30 Mar 2006 09:28:18 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <442C0AC6.3020804@andybierman.com>	<20060330.190049.00470349.mbj@tail-f.com>	<442C10AB.7060501@andybierman.com> <20060330.192041.28794077.mbj@tail-f.com>
In-Reply-To: <20060330.192041.28794077.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>> Andy Bierman <ietf@andybierman.com> wrote:
>>>> Martin Bjorklund wrote:
>>>>
>>>> IMO:
>>>>
>>>> If the agent data model has sub-trees that are
>>>> not included in the 'replace' subtrees, then they
>>>> are not touched.  Only the agent data model subtrees
>>>> explicitly included in the replace-subtrees are touched.
>>>>
>>>> At least that's what I meant when I wrote the original text.
>>> An example:
>>>
>>>   <bowler xmlns="urn:foo">
>>>     <name>Fred</name>
>>>     <status>married</status>
>>>     <cars>
>>>       <car>
>>>         <id>ABC-123</id>
>>>         <make>volvo</make>
>>>       </car>
>>>     </cars>
>>>   </bowler>
>>>   <interfaces>
>>>     <interface>
>>>        <name>eth0</name>
>>>        <ip>10.0.0.1</ip>
>>>     </interface>
>>>   </interfaces>
>>>     
>>> +
>>>  
>>>  <bowler operation="replace">
>>>    <name>Fred</name>
>>>    <status>divorced</status>
>>>  </bowler>
>>
>>
>> To come up the the result that follows,
>> you need to do:
>>
>>    <bowler operation="replace">
>>     <name>Fred</name>
>>     <status>divorced</status>
>>     <cars operation="delete"/>
>>    </bowler>
>>
>>
>> Otherwise the 'cars' element is untouched.
> 
> If this is the case, how is 'replace' different from 'merge'??


Depends on the data model.
What if the data model allowed duplicate entries?
What if some subtrees allow duplicates or have
some additive properties (defined in the object semantics)?
Then merge and replace act very differently.
They don't in your example though.


> 
>> The 'interfaces' data model (and all the other
>> sibling subtrees not included in the replace-subtrees)
>> are not affected whatsoever by an operation="replace".
> 
> That means that	in order to actually completely *replace* an entire
> subtree (i.e. not the entire config), a manager would have to first
> do a get-config to figure out all instances of all objects, then do an
> edit-config where all of these instances are marked as delete, and at
> the same time add the new instances?

We have copy-config for course-grained clobbering
of config data.  Edit-config is for fine-grained operations,
so yes, you would have to explicitly delete subtrees by
including the root of the subtree in the request.


> 
>> This is the whole point of using an operation attribute
>> placed in the root of the subtree to be affected.
> 
> I agree that the operation attribute is very useful.
> 
> 
> /martin
> 
> 

Andy


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



From owner-netconf@ops.ietf.org Thu Mar 30 12:40:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP18c-0005bE-99
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:40:50 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP18a-0007ir-Rs
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:40:50 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP15I-000D3G-NS
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:37:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FP15H-000D33-La
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:37:23 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id B22E965;
	Thu, 30 Mar 2006 19:37:22 +0200 (CEST)
Date: Thu, 30 Mar 2006 19:37:14 +0200 (CEST)
Message-Id: <20060330.193714.40015566.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <442C1532.1090407@andybierman.com>
References: <442C10AB.7060501@andybierman.com>
	<20060330.192041.28794077.mbj@tail-f.com>
	<442C1532.1090407@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

Andy Bierman <ietf@andybierman.com> wrote:
> > If this is the case, how is 'replace' different from 'merge'??
> 
> 
> Depends on the data model.
> What if the data model allowed duplicate entries?
> What if some subtrees allow duplicates or have
> some additive properties (defined in the object semantics)?
> Then merge and replace act very differently.

So if the datamodel does not allow duplicates, then 'replace' and
'merge' behave the same?

> We have copy-config for course-grained clobbering
> of config data.  Edit-config is for fine-grained operations,

But copy-config replaces the *entire* configuration, which also means
that you have to have write-access to *all* config data in order to
use copy-config at all.

> so yes, you would have to explicitly delete subtrees by
> including the root of the subtree in the request.

This seems quite complicated...  Maybe an operation
"really-REALLY-replace" would be useful :)


/martin

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



From owner-netconf@ops.ietf.org Thu Mar 30 12:50:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP1I2-00017J-1Q
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:50:34 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP1Hz-000871-NF
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 12:50:34 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP1Ea-000DvI-Id
	for netconf-data@psg.com; Thu, 30 Mar 2006 17:47:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FP1EZ-000Dub-GU
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 17:46:59 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id A4C2A55E39;
	Thu, 30 Mar 2006 19:46:58 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 22742-10; Thu, 30 Mar 2006 19:46:57 +0200 (CEST)
Received: from noname.localhost (unknown [10.222.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id DFFA555C71;
	Thu, 30 Mar 2006 19:46:56 +0200 (CEST)
Received: by noname.localhost (Postfix, from userid 501)
	id 1079264FF7C; Thu, 30 Mar 2006 19:46:56 +0200 (CEST)
Date: Thu, 30 Mar 2006 19:46:55 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "David T. Perkins" <dperkins@dsperkins.com>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com>,
	netconf@ops.ietf.org
Subject: Re: predictable content
Message-ID: <20060330174655.GA2541@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "David T. Perkins" <dperkins@dsperkins.com>,
	Balazs Lengyel <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
References: <20060330132526.GA1840@boskop.local> <Pine.LNX.4.10.10603300920580.8518-100000@shell4.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.10.10603300920580.8518-100000@shell4.bayarea.net>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

On Thu, Mar 30, 2006 at 09:27:10AM -0800, David T. Perkins wrote:
 
> I think you accidentialy used an incorrect characterization
> of SNMPv3's the  (context-engine-id, context-name) pair.
> It is not the identity of the "sender". It is the
> source of the notification. An observer can send
> a NOTIFICATION reporting that an event occured on
> another system, and when so would use the that
> system's identifier as the source.
> 
> A proxy also uses the identification of the source
> system and not it's identity.

Correct.

I simply assumed that when Balazs Lengyel wrote "sender" that he
actually meant the source of the notification in the sense of the
(context-engine-id, context-name) pair.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Thu Mar 30 13:17:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP1hm-0005HC-CW
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 13:17:10 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP1hl-0001A5-VU
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 13:17:10 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP1cq-000G3F-MM
	for netconf-data@psg.com; Thu, 30 Mar 2006 18:12:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FP1cp-000G2t-NU
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 18:12:03 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2UIC1vW021932
	for <netconf@ops.ietf.org>; Thu, 30 Mar 2006 13:12:02 -0500
Received: (qmail 9756 invoked by uid 78); 30 Mar 2006 18:12:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 30 Mar 2006 18:12:01 -0000
Message-ID: <442C1F65.2090603@andybierman.com>
Date: Thu, 30 Mar 2006 10:11:49 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
References: <442C10AB.7060501@andybierman.com>	<20060330.192041.28794077.mbj@tail-f.com>	<442C1532.1090407@andybierman.com> <20060330.193714.40015566.mbj@tail-f.com>
In-Reply-To: <20060330.193714.40015566.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>>> If this is the case, how is 'replace' different from 'merge'??
>>
>> Depends on the data model.
>> What if the data model allowed duplicate entries?
>> What if some subtrees allow duplicates or have
>> some additive properties (defined in the object semantics)?
>> Then merge and replace act very differently.
> 
> So if the datamodel does not allow duplicates, then 'replace' and
> 'merge' behave the same?

Yes

> 
>> We have copy-config for course-grained clobbering
>> of config data.  Edit-config is for fine-grained operations,
> 
> But copy-config replaces the *entire* configuration, which also means
> that you have to have write-access to *all* config data in order to
> use copy-config at all.
> 
>> so yes, you would have to explicitly delete subtrees by
>> including the root of the subtree in the request.
> 
> This seems quite complicated...  Maybe an operation
> "really-REALLY-replace" would be useful :)

I don't think so.  Clearly the operation attribute
has no affect whatsoever on sibling nodes, so you
can't clobber the entire config just because you
replace something in one subtree.

The issue here is unspecified subtrees under the
node that contains an operation="replace" attribute.
Not sure if the spec is unclear on this topic.
IMO, you should not touch anything not explicitly
mentioned in the replace-subtree.  That is how I
interpret the text.  I can see how there could be
exceptions.

For example, let's say you had a data model that
was essentially a discriminated union.  In this case,
the agent knows the data model semantics, and
knows that if you change the discriminator that
a different sibling in the union will be selected.

(Sorry for the psuedo-C; IMO it's easier to read than XSD.
Real data model is more complicated; this is just a subset
of my RFC 4001 data model):


     struct InetAddr {
       InetAddressType addr-type;
       choice {
         InetAddressIPv4  ipv4-addr;
         InetAddressIPv6  ipv6-addr;
         InetAddressDns   dns-addr;
       }
     }

What if you want to change the IP address on an interface:

   struct Interface {
      IfNameType name;
      InetAddr   addr;
      ...
   }

  <interfaces>
     <interface operation="replace">
       <name>eth0</name>
       <addr>
         <addr-type>ipv4</addr-type>
         <ipv4-addr>192.168.0.1</ipv4-addr>
       </addr>
       <adminStatus>up</adminStatus>
     </interface>
   </interfaces>

+

   <interfaces>
     <interface operation="replace">
       <name>eth0</name>
       <addr>       # operation=replace should really go here
         <addr-type>dns</addr-type>
         <dns-addr>myhost.example.com</dns-addr>
       </addr>
     </interface>
   </interfaces>

=

   <interfaces>
     <interface operation="replace">
       <name>eth0</name>
       <addr>
         <addr-type>dns</addr-type>
         <dns-addr>myhost.example.com</dns-addr>
       </addr>
       <adminStatus>up</adminStatus>
     </interface>
   </interfaces>


AdminStatus is not an optional element.
It must have some value.  Since <addr> contains
a choice, the agent knows to remove <ipv4-addr>
and replace it with <dns-addr>.  (So choices are special.)

I think your interpretation of operation=replace
is cleaner and more strict -- you would return an error here
and not make any changes, because the <adminStatus>
element is not allowed to be missing.  This forces
the manager to put the operation attribute exactly
where it belongs, including everything in the subtree,
or get an error.

My interpretation is more forgiving of sloppy managers,
but would require the operation="delete" if the manager
really did want to delete a subtree.

I don't know which is right or wrong, or if they
are both right (or wrong ;-).



> 
> 
> /martin
> 
> 

Andy

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



From owner-netconf@ops.ietf.org Thu Mar 30 13:52:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP2Fa-00042I-C9
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 13:52:06 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP2FZ-0002ya-26
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 13:52:06 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP29p-000IVE-1D
	for netconf-data@psg.com; Thu, 30 Mar 2006 18:46:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.62] (helo=pop-altamira.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FP29m-000IUy-N7
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 18:46:08 +0000
Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer)
	by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FP29l-0005JC-00
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 13:46:05 -0500
Message-ID: <009601c6542a$9d5cc4a0$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10603291534440.6146-100000@shell4.bayarea.net> <442B2D58.8040206@andybierman.com> <000801c65399$6406b260$6401a8c0@oemcomputer> <442B4474.40007@andybierman.com>
Subject: Re: notification motivation and requirements
Date: Thu, 30 Mar 2006 10:49:01 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

Hi Andy -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <netconf@ops.ietf.org>
> Sent: Wednesday, March 29, 2006 6:37 PM
> Subject: Re: notification motivation and requirements
...
> Why do you need the agent to do anything fancy at all?

I don't.  I was only explaining how what David Perkins was
describing and what I were describing were very different
things, only peripherally related.

...
> If it's not, then neither netconf or anything else can
> be sure -- and what good does guessing do?  E.g.,
> if I change the bridging configuration, and some notification
> related to spanning tree comes up, it could just be a
> coincidence, and the problem may be caused by another device.
...

That's why I characterized it as a heuristic.  I'm not arguing for or
against what David described.  I was just explaining that your
attempt to lump our statements together didn't make sense.

Randy


--
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 Mar 30 14:14:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP2bU-0007FX-Tj
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 14:14:44 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP2bU-0003uX-IU
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 14:14:44 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP2VQ-0000cC-Kg
	for netconf-data@psg.com; Thu, 30 Mar 2006 19:08:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FP2VP-0000bz-95
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 19:08:27 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-3.cisco.com with ESMTP; 30 Mar 2006 11:01:35 -0800
X-IronPort-AV: i="4.03,147,1141632000"; 
   d="scan'208"; a="421495721:sNHT31804090"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2UJ1X7r029033;
	Thu, 30 Mar 2006 11:01:35 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 30 Mar 2006 11:01:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: requirement: agent initiated session support
Date: Thu, 30 Mar 2006 11:01:30 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB019A1973@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZUE9sV2dAqg7srQKKskXegRPYPLgAFnegw
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 30 Mar 2006 19:01:31.0646 (UTC) FILETIME=[5B7709E0:01C6542C]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6


The main body of the netconf-notif doc does not describe this but
Appendix B.4 discusses potential protocol enhancements to support
NETCONF server session initiation. One of the use cases mentioned there
is "call home".=20

The same appendix also mentions the subscription info persistency issue
that you talk about below. It is suggested as a potential enhnacement
but if you want "simple" then this is not a needed feature. The document
does not discuss a notification logging feature because it is not a
protocol feature (it is a system/model capability)- although it could be
added. So, I agree w/your comment about this being a problem but if
we're limited to protocol discussion then can't be addressed in the doc.


Hector





> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, March 30, 2006 8:19 AM
> To: Netconf (E-mail)
> Subject: requirement: agent initiated session support
>=20
> Hi,
>=20
> The current subscribe model does not support agent initiated=20
> sessions at all.  There are 2 use cases I think are important:
>=20
> 1) notification generator application
>    Traditional model as in SNMP.
>    Agent SW dedicated to notification generation
>    (maybe an aggregator for multiple sub-agents)
>    Agent connects to the notification receiver application
>    and sends notifications as they are generated.
>=20
> 2) bootstrap (thin agent)
>    Agent is initially configured with a
>   (username, password, cofig-server-IP-addr) tuple.
>   Agent boots and immediately connects to the config-server
>   (manager role in netconf), and issues a <configure-me>
>   notification (perhaps with some parameters). The config
>   server then issues <rpc> edit-config or copy-config
>   commands to finish bootstrapping the agent.
>=20
>=20
> Boot-up Problem with Subscribe model:
>=20
> Using the client-subscribe model, all of the initial=20
> notifications generated upon system reboot will be lost=20
> because the agent isn't connected to a manager yet, and we=20
> have no NOTIFICATION-LOG-MIB.  Requiring the agent to save=20
> all notifications because a manager might connect someday and=20
> request them is a huge memory burden and not likely to be supported.
>=20
> In general, I don't really see the subscription model as an=20
> improvement over the traditional configuration data model=20
> approach.  Even when used in the client-initiated mode, it=20
> isn't as efficient because the manager has to re-enter the=20
> config-data every time (in the form of a start-notifications=20
> RPC).  If the profile wasn't opaque that could be used instead.
>=20
> Andy
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org=20
> with the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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 Thu Mar 30 14:38:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP2y9-0000WS-Mz
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 14:38:09 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FP2y8-0004VZ-EW
	for netconf-archive@lists.ietf.org; Thu, 30 Mar 2006 14:38:09 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FP2v0-0003Iu-24
	for netconf-data@psg.com; Thu, 30 Mar 2006 19:34:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FP2uz-0003Ii-0s
	for netconf@ops.ietf.org; Thu, 30 Mar 2006 19:34:53 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k2UJ3E1Z038279;
	Thu, 30 Mar 2006 11:03:14 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k2UJ36517266;
	Thu, 30 Mar 2006 11:03:06 -0800 (PST)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k2UJ8JYE065999;
	Thu, 30 Mar 2006 14:08:20 -0500 (EST)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200603301908.k2UJ8JYE065999@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
cc: ietf@andybierman.com, schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto 
In-Reply-To: Your message of "Thu, 30 Mar 2006 19:37:14 +0200."
             <20060330.193714.40015566.mbj@tail-f.com> 
Date: Thu, 30 Mar 2006 14:08:19 -0500
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c

Martin Bjorklund writes:
>So if the datamodel does not allow duplicates, then 'replace' and
>'merge' behave the same?

That's not the way we do it for JUNOS.  A replace operation replaces
the subtree at the level the operation appears where it matches
the given key elements (identifiers).

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 Fri Mar 31 01:33:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPDCk-0002Ak-Sh
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 01:33:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPDCi-0007WK-9i
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 01:33:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPD5d-000Jjg-UB
	for netconf-data@psg.com; Fri, 31 Mar 2006 06:26:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [217.12.11.63] (helo=smtp009.mail.ukl.yahoo.com)
	by psg.com with smtp (Exim 4.60 (FreeBSD))
	(envelope-from <vincent.cridlig@loria.fr>)
	id 1FPD5c-000JjC-9g
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 06:26:32 +0000
Received: (qmail 16605 invoked from network); 31 Mar 2006 06:26:30 -0000
Received: from unknown (HELO ?192.168.0.2?) (cridligv@195.36.224.196 with plain)
  by smtp009.mail.ukl.yahoo.com with SMTP; 31 Mar 2006 06:26:30 -0000
Message-ID: <442CCC01.4070402@loria.fr>
Date: Fri, 31 Mar 2006 08:28:17 +0200
From: Cridlig Vincent <vincent.cridlig@loria.fr>
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>,  netconf@ops.ietf.org
Subject: Re: another schema issue
References: <20060330.191714.19863895.mbj@tail-f.com>
In-Reply-To: <20060330.191714.19863895.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Martin Bjorklund a écrit :
> I didn't quite understand all implications of configInlineType:
>
>      <!--
>        Type for <config> element
>        -->
>      <xs:complexType name="configInlineType">
>        <xs:complexContent>
>          <xs:restriction base="xs:anyType"/>
>        </xs:complexContent>
>      </xs:complexType>
>
>      <xs:element name="config" type="configInlineType"/>
>
>
> so I tried to validate an edit-config message with the schema in the
> draft and xmllint.
>
> It complained and said that the <config> element's type is empty,
> which makes sense I suppose.  There's a restriction on anyType which
> restricts it to nothing.
>   
Same for me. I validates in Java but not in libxml2 (C). I suspect Java 
is wrong but not sure.
This is the same problem as filter previously.
Add something like this solve the problem, instead of xs:complexContent:
<xs:sequence>
         <xs:any processContents="skip"/>
       </xs:sequence>
Also, if I remember well the xpath attribute of filter is not set to 
optional. I think it should.
Vincent

>
> Shouldn't the "config" element (all all others alike) be defined as:
>
>          <xs:element name="config" type="xs:anyType"/>
>
>
> What do I miss?
>
>
> /martin
>
>
>
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>   


	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com


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



From owner-netconf@ops.ietf.org Fri Mar 31 02:24:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPDyk-0003yi-Gg
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 02:23:30 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPDrO-0000ow-Pk
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 02:15:59 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPDnJ-000MnJ-16
	for netconf-data@psg.com; Fri, 31 Mar 2006 07:11:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FPDnH-000Mmw-Bw
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 07:11:39 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id F2CAC6B;
	Fri, 31 Mar 2006 09:11:37 +0200 (CEST)
Date: Fri, 31 Mar 2006 09:11:29 +0200 (CEST)
Message-Id: <20060331.091129.118292845.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Second Example in section 7.2 of netconf-proto
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <442C1F65.2090603@andybierman.com>
References: <442C1532.1090407@andybierman.com>
	<20060330.193714.40015566.mbj@tail-f.com>
	<442C1F65.2090603@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >>> If this is the case, how is 'replace' different from 'merge'??
> >>
> >> Depends on the data model.
> >> What if the data model allowed duplicate entries?
> >> What if some subtrees allow duplicates or have
> >> some additive properties (defined in the object semantics)?
> >> Then merge and replace act very differently.
> > 
> > So if the datamodel does not allow duplicates, then 'replace' and
> > 'merge' behave the same?
> 
> Yes

So the only reason for having a separate 'replace' operation is
because it behaves different from merge when the data model allows
duplicates? 

Could you give an example of a data model with duplicates, and how
replace and merge would behave in your interpretation?


> > This seems quite complicated...  Maybe an operation
> > "really-REALLY-replace" would be useful :)
> 
> I don't think so.  Clearly the operation attribute
> has no affect whatsoever on sibling nodes, so you
> can't clobber the entire config just because you
> replace something in one subtree.

Suppose you have a subtree 'system' with parameters 'dnsservers',
'ntpservers', 'syslogservers', ...  i.e. parameters which could be
common for many boxes in a network.  Now the manager wants to set all
these to the same value on all his boxes.  With my interpretation,
this can be done with the same edit-config to all boxes.  With your
interpretation, the manager has to query each box, and build a special
edit-config for each one.  Isn't that more complicated than necessary?

To elaborate unless my description isn't clear:

Suppose I want the end result to be:

  <dnsservers>
    <server>
      <host>10.0.0.1</host>
    </server>
  </dnsservers>

(simpler example to save space)

With my interpretation, I would send

  <dnsservers operation="replace">
    <server>
      <host>10.0.0.1</host>
    </server>
  </dnsservers>

to all boxes.

But suppose box A already has:

  <dnsservers>
    <server>
      <host>10.0.0.2</host>
    </server>
  </dnsservers>

with your interpretation (replace == merge) you would have to do:

  <dnsservers operation="replace">
    <server>
      <host>10.0.0.1</host>
    </server>
    <server operation="delete">
      <host>10.0.0.2</host>
    </server>
  </dnsservers>

... if I understand what you're saying correctly.


> What if you want to change the IP address on an interface:

>   <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>
>          <addr-type>ipv4</addr-type>
>          <ipv4-addr>192.168.0.1</ipv4-addr>
>        </addr>
>        <adminStatus>up</adminStatus>
>      </interface>
>    </interfaces>
> 
> +
> 
>    <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>       # operation=replace should really go here
>          <addr-type>dns</addr-type>
>          <dns-addr>myhost.example.com</dns-addr>
>        </addr>
>      </interface>
>    </interfaces>
> 
> =
> 
>    <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>
>          <addr-type>dns</addr-type>
>          <dns-addr>myhost.example.com</dns-addr>
>        </addr>
>        <adminStatus>up</adminStatus>
>      </interface>
>    </interfaces>
> 
> 
> AdminStatus is not an optional element.
> It must have some value.  Since <addr> contains
> a choice, the agent knows to remove <ipv4-addr>
> and replace it with <dns-addr>.  (So choices are special.)

I wouldn't use replace in this case, I'd use merge.

> I think your interpretation of operation=replace
> is cleaner and more strict -- you would return an error here
> and not make any changes, because the <adminStatus>
> element is not allowed to be missing.  This forces
> the manager to put the operation attribute exactly
> where it belongs, including everything in the subtree,
> or get an error.
> 
> My interpretation is more forgiving of sloppy managers,
> but would require the operation="delete" if the manager
> really did want to delete a subtree.

I think 'merge' is for the sloppy manager.

> I don't know which is right or wrong, or if they
> are both right (or wrong ;-).

Isn't it important for interopability that this issue is clear?


/martin

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



From owner-netconf@ops.ietf.org Fri Mar 31 02:48:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPEN8-0006t8-LN
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 02:48:42 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPEN5-0002fj-4l
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 02:48:42 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPEI9-000Oew-LS
	for netconf-data@psg.com; Fri, 31 Mar 2006 07:43:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_40_50,
	HTML_MESSAGE autolearn=ham version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FPEI8-000OeY-Hk
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 07:43:32 +0000
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2V7fqkp010833
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 02:41:52 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k2V7eKTu029675
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 02:40:21 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C65496.CCDD7180"
Subject: again about interim
Date: Fri, 31 Mar 2006 09:43:28 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: again about interim
Thread-Index: AcZUls2iiXO1DqwkTJyoHIEt1OBFHg==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65496.CCDD7180
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I raised the issue of a Netconf WG interim meeting in the IESG
teleconference yesterday. The request for an interim immediately after
the Montreal meeting was not received very sympathetically, to say it
mildly. It looks like the rules allow indeed for an interim meeting
immediately after the IETF meeting (not before), but this is perceived
rather as a loophole in the rules. The IESG prefers the participants in
an IETF meeting to be able to participate in more activities during the
IETF week, and if an interim is needed it rather be a real interim
during the three-four months between the IETF meetings. Also, the WG
will need to take care of the logistics, find a meeting place, pay for
the rooms, etc. The IETF may be able to find a meeting room on Friday
afternoon, but will not pay for Saturday or Sunday meeting rooms. It's
not a definite no, and if you want it and find the good arguments
meeting on Fri-Sat-Sun after the IETF may still be approved, as it fits
in the rules. Yet, you will need to find ways to fund it, as for any
interim.=20
=20
So, you may want to consider again options for an interim in May or
beginning of June. You also may ask for two meetings during the Montreal
session. Or you may insist for the interim-stuck-to-Montreal, and may
get it.=20
=20
The more important thing in my opinion is to continue the good
discussions happening on the list after Dallas, channel them into
contributions and try to work towards WG consensus.=20
=20
Dan
=20
=20
=20
=20
=20
=20

------_=_NextPart_001_01C65496.CCDD7180
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D375572307-31032006>I =
raised the issue=20
of a Netconf WG&nbsp;interim meeting in the IESG teleconference =
yesterday. The=20
request for an interim immediately after the Montreal meeting was not =
received=20
very sympathetically, to say it mildly. It looks like the rules allow =
indeed for=20
an interim meeting immediately after the IETF meeting (not before), but =
this is=20
perceived rather as a loophole in the rules. The IESG prefers the =
participants=20
in an IETF meeting to be able to participate in more activities during =
the IETF=20
week, and if an interim is needed it rather be a real =
interim&nbsp;during the=20
three-four months between the IETF meetings. Also, the WG will need to =
take care=20
of the logistics, find a meeting place, pay for the rooms, etc. The IETF =
may be=20
able to find a meeting room on Friday afternoon, but will not pay for =
Saturday=20
or Sunday meeting rooms. </SPAN></FONT><FONT face=3DArial size=3D2><SPAN =

class=3D375572307-31032006>It's not a definite no, and if you want it =
and find the=20
good arguments meeting on Fri-Sat-Sun after the IETF may still be =
approved, as=20
it fits in the rules. Yet, you will need to find ways to fund it, as for =
any=20
interim. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D375572307-31032006>So, =
you may want to=20
consider again options for an interim in May or beginning of June. You =
also may=20
ask for two meetings during the Montreal session. Or you may insist for =
the=20
interim-stuck-to-Montreal, and may get it. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D375572307-31032006>The =
more important=20
thing in my opinion is to continue the good discussions happening on the =
list=20
after Dallas, channel them into contributions and try to work towards WG =

consensus. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006>Dan</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D375572307-31032006></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C65496.CCDD7180--

--
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 Mar 31 03:04:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPEc3-0004je-V5
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 03:04:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPEVQ-00037n-7x
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 02:57:17 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPERZ-000PO7-8o
	for netconf-data@psg.com; Fri, 31 Mar 2006 07:53:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FPERY-000PNr-Fy
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 07:53:16 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 698676B;
	Fri, 31 Mar 2006 09:53:15 +0200 (CEST)
Date: Fri, 31 Mar 2006 09:53:06 +0200 (CEST)
Message-Id: <20060331.095306.67116379.mbj@tail-f.com>
To: vincent.cridlig@loria.fr
Cc: netconf@ops.ietf.org
Subject: Re: another schema issue
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <442CCC01.4070402@loria.fr>
References: <20060330.191714.19863895.mbj@tail-f.com>
	<442CCC01.4070402@loria.fr>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

Cridlig Vincent <vincent.cridlig@loria.fr> wrote:
> Martin Bjorklund a =E9crit :
> > I didn't quite understand all implications of configInlineType:
> >
> >      <!--
> >        Type for <config> element
> >        -->
> >      <xs:complexType name=3D"configInlineType">
> >        <xs:complexContent>
> >          <xs:restriction base=3D"xs:anyType"/>
> >        </xs:complexContent>
> >      </xs:complexType>
> >
> >      <xs:element name=3D"config" type=3D"configInlineType"/>
> >
> >
> > so I tried to validate an edit-config message with the schema in th=
e
> > draft and xmllint.
> >
> > It complained and said that the <config> element's type is empty,
> > which makes sense I suppose.  There's a restriction on anyType whic=
h
> > restricts it to nothing.
> >   =

> Same for me. I validates in Java but not in libxml2 (C). I suspect Ja=
va =

> is wrong but not sure.
> This is the same problem as filter previously.
> Add something like this solve the problem, instead of xs:complexConte=
nt:
> <xs:sequence>
>          <xs:any processContents=3D"skip"/>
>        </xs:sequence>

You have to do

   <xs:sequence>
          <xs:any processContents=3D"skip" maxOccurs=3D"unbounded"/>
   </xs:sequence>

To support e.g. this as a reply to get-config:

<rpc-reply>
  <data>
    <interfaces xmlns=3D"urn:ifMib:...">
      ...
    </interfaces>
    <system xmlns=3D"....">
      ...
    </system>
  </data>
</rpc-reply>


> Also, if I remember well the xpath attribute of filter is not set to =

> optional. I think it should.

It has a default value, so maybe 'use' is not required.  The XSD spec
isn't very easy to understand...  xmllint doesn't complain anyway.



/martin

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



From owner-netconf@ops.ietf.org Fri Mar 31 05:41:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPH3s-00088n-1N
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 05:41:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPH3r-0001w0-Om
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 05:41:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPGxx-000Bzn-Ls
	for netconf-data@psg.com; Fri, 31 Mar 2006 10:34:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.105] (helo=test-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FPGxx-000BzZ-4J
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 10:34:53 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by test-iport-2.cisco.com with ESMTP; 31 Mar 2006 02:34:53 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2VAYqw1024862;
	Fri, 31 Mar 2006 02:34:52 -0800 (PST)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp241.cisco.com [10.61.64.241])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2VAZGKa003181;
	Fri, 31 Mar 2006 02:35:17 -0800
Message-ID: <442D05CA.5040101@cisco.com>
Date: Fri, 31 Mar 2006 12:34:50 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: again about interim
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=917; t=1143801318; x=1144665318;
	c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20again=20about=20interim
	|To:=22Romascanu,=20Dan=20\(Dan\)=22=20<dromasca@avaya.com>;
	X=v=3Dcisco.com=3B=20h=3DersR6TddN9tWBh4kf73WkUfUoys=3D; b=RvazsEemphWwHZMkREEQAnX9Mq9Ga5CeWaL+8Siog3HN8uwDvqwcWKoZBREKT95kccXfe+8i
	rSaiXWD9UMU7/CoazeetWRZgto6e+0bCuBF0/re3ZQvKZx8cwyuNH2cb;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Dan,

I have to say that thus far I find arguments both for and against an
interim meeting unconvincing.  In my experience, the best use of an
interim is when you have clear questions to discuss - even if they're
big ones, whether to reuse SYSLOG or whether to use the same transport
connection or what if any data model should be used.  Having
presentations on the options is fair game, but there should be drafts
associated with those presentations so people can prepare.  We have none
of that yet but perhaps the lists that Sharon and Juergen are making
will crystallize soon...

On the other hand, I am flummoxed by the IESG's response.  If a WG has
those questions above, then if the chairs predict they'll need lots more
time to answer those questions than can be afforded during an IETF, why
should anybody insist on YET ANOTHER FLIGHT?  Some people must really
hate where they live.

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 Mar 31 05:43:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPH6Q-00012P-TR
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 05:43:38 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPH6P-00021h-AH
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 05:43:38 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPH21-000CM1-R2
	for netconf-data@psg.com; Fri, 31 Mar 2006 10:39:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FPH20-000CLl-5V
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 10:39:04 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id D4FCE55D0F;
	Fri, 31 Mar 2006 12:39:02 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 30312-05; Fri, 31 Mar 2006 12:39:01 +0200 (CEST)
Received: from boskop.local (unknown [10.71.237.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 264E155CEC;
	Fri, 31 Mar 2006 12:39:01 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 1E15C650873; Fri, 31 Mar 2006 12:38:59 +0200 (CEST)
Date: Fri, 31 Mar 2006 12:38:59 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
Message-ID: <20060331103859.GB3984@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <442BF6E3.90606@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <442BF6E3.90606@andybierman.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:

[...]

I just added

* solution should support preconfigured notification destinations [AB]

to the wiki page.

> In general, I don't really see the subscription model
> as an improvement over the traditional configuration
> data model approach.  Even when used in the client-initiated
> mode, it isn't as efficient because the manager has to
> re-enter the config-data every time (in the form of a
> start-notifications RPC).  If the profile wasn't opaque
> that could be used instead.

The subcription model helps to simplify management applications that
are not constantly running, such as a configuration tools that you
kick off once in a while (or periodically) to check and configure
things if the checks do not deliver the expected outcome.

The preconfigured approach requires that such an app 

(a) first finds a suitable notification receiver,
(b) authenticates with this notification receiver,
(c) subscribes to this notification receiver 

before it can actually start to do its job. In other words, such apps
will always have a subscription and the question is whether you force
such apps to go through an intermediary or provide the means to talk
directly to the box in question.

Perhaps you don't like such apps or you do not care much about the app
side of things. This is the old story of finding the right balance
between the "complexity" on the agent and the "complexity" on the
manager. My SNMP experience is that the lack of a common way to
subscribe to SNMP notifications has been a pain.

Sure, with SNMPv3 you can in principle subscribe by configuring the
target tables but this (a) requires appropriate authorization rules
and (b) there is no standardized way to cleanup dynamic targets so
crashing apps leave garbage around which is painful to try to clean as
well.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Fri Mar 31 09:01:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPKCF-0005hF-0l
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:01:51 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPKCE-0003aD-Mo
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:01:51 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPK78-0000K1-HO
	for netconf-data@psg.com; Fri, 31 Mar 2006 13:56:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPK77-0000Jp-Ay
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 13:56:33 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k2VDuWZj023560
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 08:56:32 -0500
Received: (qmail 27303 invoked by uid 78); 31 Mar 2006 13:56:31 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 31 Mar 2006 13:56:31 -0000
Message-ID: <442D3509.4040603@andybierman.com>
Date: Fri, 31 Mar 2006 05:56:25 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: again about interim
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Romascanu, Dan (Dan) wrote:
> I raised the issue of a Netconf WG interim meeting in the IESG 
> teleconference yesterday. The request for an interim immediately after 
> the Montreal meeting was not received very sympathetically, to say it 
> mildly. It looks like the rules allow indeed for an interim meeting 
> immediately after the IETF meeting (not before), but this is perceived 
> rather as a loophole in the rules. The IESG prefers the participants in 
> an IETF meeting to be able to participate in more activities during the 
> IETF week, and if an interim is needed it rather be a real 
> interim during the three-four months between the IETF meetings. Also, 
> the WG will need to take care of the logistics, find a meeting place, 
> pay for the rooms, etc. The IETF may be able to find a meeting room on 
> Friday afternoon, but will not pay for Saturday or Sunday meeting rooms. 
> It's not a definite no, and if you want it and find the good arguments 
> meeting on Fri-Sat-Sun after the IETF may still be approved, as it fits 
> in the rules. Yet, you will need to find ways to fund it, as for any 
> interim.
>  
> So, you may want to consider again options for an interim in May or 
> beginning of June. You also may ask for two meetings during the Montreal 
> session. Or you may insist for the interim-stuck-to-Montreal, and may 
> get it.
>  
> The more important thing in my opinion is to continue the good 
> discussions happening on the list after Dallas, channel them into 
> contributions and try to work towards WG consensus.

Here is the problem.
There was < 10% of the WG prepared to work in Dallas.
Except for the authors and co-chairs, there are about
2 or 3 people that can make it to an interim in Europe.

This just isn't worth it unless 10+ clueful people besides
the authors and chairs attend.  Especially since travel
is so expensive, and the issues deadlocking the WG are so big
and complex.

I really find it puzzling how an interim on Friday will
prevent people from "cross-area participation" on M-Th.
I find it disturbing that the IESG prioritizes cross
participation over progress.


>  
> Dan
>  
>  
>  
>  
>  
>  

Andy

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



From owner-netconf@ops.ietf.org Fri Mar 31 09:13:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPKNu-0002pf-H0
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:13:54 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPKNu-0004WO-3Q
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:13:54 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPKKS-0001Jb-BL
	for netconf-data@psg.com; Fri, 31 Mar 2006 14:10:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPKKR-0001JQ-Ec
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 14:10:19 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VEAHkQ006895
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 09:10:17 -0500
Received: (qmail 26427 invoked by uid 78); 31 Mar 2006 14:10:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 31 Mar 2006 14:10:17 -0000
Message-ID: <442D3842.9090506@andybierman.com>
Date: Fri, 31 Mar 2006 06:10:10 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <442BF6E3.90606@andybierman.com> <20060331103859.GB3984@boskop.local>
In-Reply-To: <20060331103859.GB3984@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

Juergen Schoenwaelder wrote:
> On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:
> 
> [...]
> 
> I just added
> 
> * solution should support preconfigured notification destinations [AB]
> 

What about the session and transport aspects, and losing
all the startup notifications if you use the subscription approach?
We have users and sessions in netconf, not host endpoints like snmp.


> to the wiki page.
> 
>> In general, I don't really see the subscription model
>> as an improvement over the traditional configuration
>> data model approach.  Even when used in the client-initiated
>> mode, it isn't as efficient because the manager has to
>> re-enter the config-data every time (in the form of a
>> start-notifications RPC).  If the profile wasn't opaque
>> that could be used instead.
> 
> The subcription model helps to simplify management applications that
> are not constantly running, such as a configuration tools that you
> kick off once in a while (or periodically) to check and configure
> things if the checks do not deliver the expected outcome.
> 

It doesn't work if the agent initiates the session.


> The preconfigured approach requires that such an app 
> 
> (a) first finds a suitable notification receiver,
> (b) authenticates with this notification receiver,
> (c) subscribes to this notification receiver 


How is this any different if the client initiates it?
It's the same amount of code either way.

I favor a combined approach:

1) profile table
    Each profile contains the configuration data for that
    named profile

2) get rid of all the parameters in the start-notifications
    or modify-subscription except the profileName (index)

This way agents and managers can both share the profiles
and the manager won't reenter the same data in the most
complex manner possible every time.  I can configure
the agent to connect to notification receiver X using
profile Y.  The manager can just subscribe using profile Y.

(An agent may not allow a profile in use to be modified.)


> 
> before it can actually start to do its job. In other words, such apps
> will always have a subscription and the question is whether you force
> such apps to go through an intermediary or provide the means to talk
> directly to the box in question.
> 
> Perhaps you don't like such apps or you do not care much about the app
> side of things. This is the old story of finding the right balance
> between the "complexity" on the agent and the "complexity" on the
> manager. My SNMP experience is that the lack of a common way to
> subscribe to SNMP notifications has been a pain.
> 
> Sure, with SNMPv3 you can in principle subscribe by configuring the
> target tables but this (a) requires appropriate authorization rules
> and (b) there is no standardized way to cleanup dynamic targets so
> crashing apps leave garbage around which is painful to try to clean as
> well.

What about the problem of losing all the startup notifications?
If apps care about that they better configure a notification
receiver in NVRAM.  What about discovery?  Does it really scale
for 100000 agents to come up, and 1 or a few managers find all
of them and check if they support notifications, and then
start subscriptions on all the appropriate boxes?  It sure
seems easier to just configure the subset of agents which are
notification generators to connect to a receiver upon reboot.

> 
> /js
> 

Andy

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



From owner-netconf@ops.ietf.org Fri Mar 31 09:32:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPKfX-00082T-KT
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:32:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPKfW-0005PO-70
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:32:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPKbe-0002IO-5m
	for netconf-data@psg.com; Fri, 31 Mar 2006 14:28:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FPKbb-0002I7-DX
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 14:28:03 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id B5E5255CE9;
	Fri, 31 Mar 2006 16:28:02 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 25032-06; Fri, 31 Mar 2006 16:28:00 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 7BCB055CA6;
	Fri, 31 Mar 2006 16:27:59 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 9B17A650FC6; Fri, 31 Mar 2006 16:27:57 +0200 (CEST)
Date: Fri, 31 Mar 2006 16:27:57 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
Message-ID: <20060331142757.GB4885@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <442BF6E3.90606@andybierman.com> <20060331103859.GB3984@boskop.local> <442D3842.9090506@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <442D3842.9090506@andybierman.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

On Fri, Mar 31, 2006 at 06:10:10AM -0800, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> >On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:
> >
> >[...]
> >
> >I just added
> >
> >* solution should support preconfigured notification destinations [AB]
> >
> 
> What about the session and transport aspects, and losing
> all the startup notifications if you use the subscription approach?
> We have users and sessions in netconf, not host endpoints like snmp.

I fail to see how your comment applies to the quoted text. I do not
understand why you wrote the last sentence at all.

> >The subcription model helps to simplify management applications that
> >are not constantly running, such as a configuration tools that you
> >kick off once in a while (or periodically) to check and configure
> >things if the checks do not deliver the expected outcome.
> 
> It doesn't work if the agent initiates the session.

He? Please help me understand what you mean. I fail to match you
comment to the quoted text.
 
> >The preconfigured approach requires that such an app 
> >
> >(a) first finds a suitable notification receiver,
> >(b) authenticates with this notification receiver,
> >(c) subscribes to this notification receiver 
> 
> How is this any different if the client initiates it?
> It's the same amount of code either way.
> 
> I favor a combined approach:
> 
> 1) profile table
>    Each profile contains the configuration data for that
>    named profile
> 
> 2) get rid of all the parameters in the start-notifications
>    or modify-subscription except the profileName (index)
> 
> This way agents and managers can both share the profiles
> and the manager won't reenter the same data in the most
> complex manner possible every time.  I can configure
> the agent to connect to notification receiver X using
> profile Y.  The manager can just subscribe using profile Y.
> 
> (An agent may not allow a profile in use to be modified.)

Show me the detailed profile information you have in mind and how this
can be tweaked by an app that comes and goes and I will then tell you
whether I consider a plain subscription "the most complex manner
possible".

> What about the problem of losing all the startup notifications?
> If apps care about that they better configure a notification
> receiver in NVRAM.  What about discovery?  Does it really scale
> for 100000 agents to come up, and 1 or a few managers find all
> of them and check if they support notifications, and then
> start subscriptions on all the appropriate boxes?  It sure
> seems easier to just configure the subset of agents which are
> notification generators to connect to a receiver upon reboot.

To quote myself:

> >I just added
> >
> >* solution should support preconfigured notification destinations [AB]

I do not understand your message.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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



From owner-netconf@ops.ietf.org Fri Mar 31 09:41:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPKoK-0002EP-Eu
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:41:12 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPKoK-0005W8-1F
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:41:12 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPKjm-0002ul-PH
	for netconf-data@psg.com; Fri, 31 Mar 2006 14:36:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPKjl-0002uY-IX
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 14:36:29 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VEaRDT013225
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 09:36:27 -0500
Received: (qmail 18485 invoked by uid 78); 31 Mar 2006 14:36:27 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 31 Mar 2006 14:36:27 -0000
Message-ID: <442D3E65.3040308@andybierman.com>
Date: Fri, 31 Mar 2006 06:36:21 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <442BF6E3.90606@andybierman.com> <20060331103859.GB3984@boskop.local> <442D3842.9090506@andybierman.com> <20060331142757.GB4885@boskop.local>
In-Reply-To: <20060331142757.GB4885@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4

Juergen Schoenwaelder wrote:
> On Fri, Mar 31, 2006 at 06:10:10AM -0800, Andy Bierman wrote:
>> Juergen Schoenwaelder wrote:
>>> On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:
>>>
>>> [...]
>>>
>>> I just added
>>>
>>> * solution should support preconfigured notification destinations [AB]
>>>
>> What about the session and transport aspects, and losing
>> all the startup notifications if you use the subscription approach?
>> We have users and sessions in netconf, not host endpoints like snmp.
> 
> I fail to see how your comment applies to the quoted text. I do not
> understand why you wrote the last sentence at all.

A destination is not enough in netconf, but I guess you meant
this is a generic sense


>>> The subcription model helps to simplify management applications that
>>> are not constantly running, such as a configuration tools that you
>>> kick off once in a while (or periodically) to check and configure
>>> things if the checks do not deliver the expected outcome.
>> It doesn't work if the agent initiates the session.
> 
> He? Please help me understand what you mean. I fail to match you
> comment to the quoted text.

I don't think it's a good idea to use a design
which excludes important use cases.

>  
>>> The preconfigured approach requires that such an app 
>>>
>>> (a) first finds a suitable notification receiver,
>>> (b) authenticates with this notification receiver,
>>> (c) subscribes to this notification receiver 
>> How is this any different if the client initiates it?
>> It's the same amount of code either way.
>>
>> I favor a combined approach:
>>
>> 1) profile table
>>    Each profile contains the configuration data for that
>>    named profile
>>
>> 2) get rid of all the parameters in the start-notifications
>>    or modify-subscription except the profileName (index)
>>
>> This way agents and managers can both share the profiles
>> and the manager won't reenter the same data in the most
>> complex manner possible every time.  I can configure
>> the agent to connect to notification receiver X using
>> profile Y.  The manager can just subscribe using profile Y.
>>
>> (An agent may not allow a profile in use to be modified.)
> 
> Show me the detailed profile information you have in mind and how this
> can be tweaked by an app that comes and goes and I will then tell you
> whether I consider a plain subscription "the most complex manner
> possible".

I'm not writing the data model now.
If you think the parameters in the current draft
are sufficient, then imagine those parameters
in a real data model instead of RPC parameters.


> 
>> What about the problem of losing all the startup notifications?
>> If apps care about that they better configure a notification
>> receiver in NVRAM.  What about discovery?  Does it really scale
>> for 100000 agents to come up, and 1 or a few managers find all
>> of them and check if they support notifications, and then
>> start subscriptions on all the appropriate boxes?  It sure
>> seems easier to just configure the subset of agents which are
>> notification generators to connect to a receiver upon reboot.
> 
> To quote myself:
> 
>>> I just added
>>>
>>> * solution should support preconfigured notification destinations [AB]
> 
> I do not understand your message.

You should add a requirement about scaling so it won't
get ignored.  The subscription model has some scaling
problems that don't exist in the traditional notification
generator application model.


> 
> /js
> 

Andy

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



From owner-netconf@ops.ietf.org Fri Mar 31 09:47:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPKtw-0008Gn-OE
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:47:00 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPKtw-0005d1-9J
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 09:47:00 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPKpS-0003JP-Eb
	for netconf-data@psg.com; Fri, 31 Mar 2006 14:42:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPKpR-0003J9-7A
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 14:42:21 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VEgJvW017198
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 09:42:19 -0500
Received: (qmail 21262 invoked by uid 78); 31 Mar 2006 14:42:19 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 31 Mar 2006 14:42:19 -0000
Message-ID: <442D3FC5.6040903@andybierman.com>
Date: Fri, 31 Mar 2006 06:42:13 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <6E21698722408147BEA594E073E2B0AB019A1973@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB019A1973@xmb-sjc-223.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4

Hector Trevino (htrevino) wrote:
> The main body of the netconf-notif doc does not describe this but
> Appendix B.4 discusses potential protocol enhancements to support
> NETCONF server session initiation. One of the use cases mentioned there
> is "call home". 
> 
> The same appendix also mentions the subscription info persistency issue
> that you talk about below. It is suggested as a potential enhnacement
> but if you want "simple" then this is not a needed feature. The document
> does not discuss a notification logging feature because it is not a
> protocol feature (it is a system/model capability)- although it could be
> added. So, I agree w/your comment about this being a problem but if
> we're limited to protocol discussion then can't be addressed in the doc.
> 

There's a lot of unspecified details in that appendix.
How does the manager know that some agent that initiates
the session wants it to invoke a <create-subscription> RPC?

The whole approach seems extra complicated for no apparent reason,
if I just want the agent to connect to a notification receiver
application using a pre-configured profile.

> 
> Hector


Andy

> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Thursday, March 30, 2006 8:19 AM
>> To: Netconf (E-mail)
>> Subject: requirement: agent initiated session support
>>
>> Hi,
>>
>> The current subscribe model does not support agent initiated 
>> sessions at all.  There are 2 use cases I think are important:
>>
>> 1) notification generator application
>>    Traditional model as in SNMP.
>>    Agent SW dedicated to notification generation
>>    (maybe an aggregator for multiple sub-agents)
>>    Agent connects to the notification receiver application
>>    and sends notifications as they are generated.
>>
>> 2) bootstrap (thin agent)
>>    Agent is initially configured with a
>>   (username, password, cofig-server-IP-addr) tuple.
>>   Agent boots and immediately connects to the config-server
>>   (manager role in netconf), and issues a <configure-me>
>>   notification (perhaps with some parameters). The config
>>   server then issues <rpc> edit-config or copy-config
>>   commands to finish bootstrapping the agent.
>>
>>
>> Boot-up Problem with Subscribe model:
>>
>> Using the client-subscribe model, all of the initial 
>> notifications generated upon system reboot will be lost 
>> because the agent isn't connected to a manager yet, and we 
>> have no NOTIFICATION-LOG-MIB.  Requiring the agent to save 
>> all notifications because a manager might connect someday and 
>> request them is a huge memory burden and not likely to be supported.
>>
>> In general, I don't really see the subscription model as an 
>> improvement over the traditional configuration data model 
>> approach.  Even when used in the client-initiated mode, it 
>> isn't as efficient because the manager has to re-enter the 
>> config-data every time (in the form of a start-notifications 
>> RPC).  If the profile wasn't opaque that could be used instead.
>>
>> Andy
>>
>>
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org 
>> with the word 'unsubscribe' in a single line as the message text body.
>> archive: <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 Mar 31 10:01:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPL8L-0004mH-16
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 10:01:53 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPL8J-00068G-Nm
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 10:01:53 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPL4T-0004Qh-VH
	for netconf-data@psg.com; Fri, 31 Mar 2006 14:57:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPL4R-0004QN-98
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 14:57:51 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VEvnts006345
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 09:57:50 -0500
Received: (qmail 2432 invoked by uid 78); 31 Mar 2006 14:57:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 31 Mar 2006 14:57:49 -0000
Message-ID: <442D4367.3070001@andybierman.com>
Date: Fri, 31 Mar 2006 06:57:43 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: requirement: notification content self-containment
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Hi,

It should be a requirement that the notification message
will contain enough header data to fully decode the
notification.  Info from the session, connection, or
other notifications must not be required for an application
to decode the notification contents.

This has 2 important implications:

1) There is no real reason the notifications need to come back
   on the same session that RPC operations occurred  which
   possibly caused the notifications.

2) Session parameters such as the subscription-id need to be
   replaced with parameters that have meaning to a general
   application.  This is important if the notifications are
   being logged or centrally processed by a 3rd party application.


Andy


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



From owner-netconf@ops.ietf.org Fri Mar 31 11:06:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPM8V-0004Xd-3t
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 11:06:07 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPM8T-0000bi-Qm
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 11:06:07 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPM4q-0008rM-Sv
	for netconf-data@psg.com; Fri, 31 Mar 2006 16:02:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPM4p-0008r0-Ty
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 16:02:20 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VG2HkQ020689
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 11:02:18 -0500
Received: (qmail 7635 invoked by uid 78); 31 Mar 2006 16:02:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 31 Mar 2006 16:02:17 -0000
Message-ID: <442D5283.6000307@andybierman.com>
Date: Fri, 31 Mar 2006 08:02:11 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: data model snippet for notification parameters
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

Hi,

Here is the C/RelaxNG hack profile data structure
Juergen asked for: (XSD takes me too much time ;-)

    struct profiles {
      table profile [name] {
        ProfileName name;           # this is the key
        EventClassList class-filter?;
        filterInlineType data-filter?;
      }
    }

E.g:

  <netconf>
    <notifications>
      <profiles>
         <profile>
           <name>faults</name>
           <class-filter>fault</class-filter>
         </profile>
         <profile>
           <name>fred-faults-config</name>
           <class-filter>fault config</class-filter>
           <data-filter type="xpath" select="/bowlers/bowler[name='fred']"/>
         </profile>
       </profiles>
     </notifications>
  </netconf>

In this model, the parameters from the <create-subscription> RPC
are moved to a NV data model on the agent, and the only parameter
passed in the RPC to start receiving notifications (however that
ends up being done) is the profile name.

Additional tables under <notifications> could be added to configure
the agent to connect to a notification receiver application using a
profile name as well.


Andy





          
       

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



From owner-netconf@ops.ietf.org Fri Mar 31 11:47:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPMmK-0004tM-Fj
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 11:47:16 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPMmJ-0002q2-Qq
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 11:47:16 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPMhK-000BS3-Lf
	for netconf-data@psg.com; Fri, 31 Mar 2006 16:42:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.117] (helo=test-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FPMhJ-000BRn-Tz
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 16:42:05 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by test-iport-1.cisco.com with ESMTP; 31 Mar 2006 08:42:05 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2VGg57T000166;
	Fri, 31 Mar 2006 08:42:05 -0800 (PST)
Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 31 Mar 2006 08:42:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: requirement: agent initiated session support
Date: Fri, 31 Mar 2006 08:42:04 -0800
Message-ID: <6E21698722408147BEA594E073E2B0AB01A06F34@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZU0VJvnCTmgh1DQ8m6JYT+wh2y2AAD2dYg
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 31 Mar 2006 16:42:05.0126 (UTC) FILETIME=[0B0B2660:01C654E2]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c

=20

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20
> Sent: Friday, March 31, 2006 7:42 AM
> To: Hector Trevino (htrevino)
> Cc: Netconf (E-mail)
> Subject: Re: requirement: agent initiated session support
>=20
> Hector Trevino (htrevino) wrote:
> > The main body of the netconf-notif doc does not describe this but=20
> > Appendix B.4 discusses potential protocol enhancements to support=20
> > NETCONF server session initiation. One of the use cases mentioned=20
> > there is "call home".
> >=20
> > The same appendix also mentions the subscription info persistency=20
> > issue that you talk about below. It is suggested as a potential=20
> > enhnacement but if you want "simple" then this is not a needed=20
> > feature. The document does not discuss a notification=20
> logging feature=20
> > because it is not a protocol feature (it is a system/model=20
> > capability)- although it could be added. So, I agree w/your comment=20
> > about this being a problem but if we're limited to protocol=20
> discussion then can't be addressed in the doc.
> >=20
>=20
> There's a lot of unspecified details in that appendix.
> How does the manager know that some agent that initiates the=20
> session wants it to invoke a <create-subscription> RPC?

HT: There are two cases that were covered for netconf server session
initiation a) call home and b) notification forwarding. Case "b"
required subscription information to be configured. Hence the need to
have persistency. Otherwise, I'd agree that the manger wouldn't know to
issue a <create-subscription> RPC.   =20
=20
>=20
> The whole approach seems extra complicated for no apparent=20
> reason, if I just want the agent to connect to a notification=20
> receiver application using a pre-configured profile.

HT: Yes, I agree it would be. But what you say above is essentially what
the appendix attempted to describe (i.e. the notification destinations
have to be configured). This could be done by the netconf client or
pre-configured by hand (e.g. a profile as you indicate). The netconf
server (agent) establishes the session when there are notifications to
be sent out. =20

>=20
> >=20
> > Hector
>=20
>=20
> Andy
>=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >> -----Original Message-----
> >> From: owner-netconf@ops.ietf.org
> >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> >> Sent: Thursday, March 30, 2006 8:19 AM
> >> To: Netconf (E-mail)
> >> Subject: requirement: agent initiated session support
> >>
> >> Hi,
> >>
> >> The current subscribe model does not support agent=20
> initiated sessions=20
> >> at all.  There are 2 use cases I think are important:
> >>
> >> 1) notification generator application
> >>    Traditional model as in SNMP.
> >>    Agent SW dedicated to notification generation
> >>    (maybe an aggregator for multiple sub-agents)
> >>    Agent connects to the notification receiver application
> >>    and sends notifications as they are generated.
> >>
> >> 2) bootstrap (thin agent)
> >>    Agent is initially configured with a
> >>   (username, password, cofig-server-IP-addr) tuple.
> >>   Agent boots and immediately connects to the config-server
> >>   (manager role in netconf), and issues a <configure-me>
> >>   notification (perhaps with some parameters). The config
> >>   server then issues <rpc> edit-config or copy-config
> >>   commands to finish bootstrapping the agent.
> >>
> >>
> >> Boot-up Problem with Subscribe model:
> >>
> >> Using the client-subscribe model, all of the initial notifications=20
> >> generated upon system reboot will be lost because the agent isn't=20
> >> connected to a manager yet, and we have no NOTIFICATION-LOG-MIB. =20
> >> Requiring the agent to save all notifications because a=20
> manager might=20
> >> connect someday and request them is a huge memory burden and not=20
> >> likely to be supported.
> >>
> >> In general, I don't really see the subscription model as an=20
> >> improvement over the traditional configuration data model=20
> approach. =20
> >> Even when used in the client-initiated mode, it isn't as efficient=20
> >> because the manager has to re-enter the config-data every time (in=20
> >> the form of a start-notifications RPC).  If the profile=20
> wasn't opaque=20
> >> that could be used instead.
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://ops.ietf.org/lists/netconf/>
> >>
> >=20
> > --
> > to unsubscribe send a message to=20
> netconf-request@ops.ietf.org with the=20
> > word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> >=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 Fri Mar 31 13:18:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPOCG-0005Ha-4W
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 13:18:08 -0500
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPOCF-0007gf-O9
	for netconf-archive@lists.ietf.org; Fri, 31 Mar 2006 13:18:08 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FPO78-000H7w-NQ
	for netconf-data@psg.com; Fri, 31 Mar 2006 18:12:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FPO77-000H7l-Hw
	for netconf@ops.ietf.org; Fri, 31 Mar 2006 18:12:49 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k2VICkkQ010040
	for <netconf@ops.ietf.org>; Fri, 31 Mar 2006 13:12:48 -0500
Received: (qmail 14237 invoked by uid 78); 31 Mar 2006 18:12:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 31 Mar 2006 18:12:46 -0000
Message-ID: <442D7113.80804@andybierman.com>
Date: Fri, 31 Mar 2006 10:12:35 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: again about interim
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C657@is0004avexu1.global.avaya.com> <442D05CA.5040101@cisco.com>
In-Reply-To: <442D05CA.5040101@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

Eliot Lear wrote:
> Dan,
> 
> I have to say that thus far I find arguments both for and against an
> interim meeting unconvincing.  In my experience, the best use of an
> interim is when you have clear questions to discuss - even if they're
> big ones, whether to reuse SYSLOG or whether to use the same transport
> connection or what if any data model should be used.  Having
> presentations on the options is fair game, but there should be drafts
> associated with those presentations so people can prepare.  We have none
> of that yet but perhaps the lists that Sharon and Juergen are making
> will crystallize soon...

I have asked Phil if he would consider writing a draft
on the endless RPC approach.  That means the floor is
open to anyone who wants to take the time to write a
draft on "notifications in netconf".

Speaking of big questions...

Dave H. and I are particularly concerned about this
architecture thing.  There doesn't seem to be any.
How does this all fit with our RPC-based configuration
datastore manipulation protocol?  What is the extensible
framework that allows the maximum standards features
for interoperability, plus a content-independent data
payload capability?  What are the components needed
immediately (vs. phased in) to deploy a robust, secure,
efficient, and interoperable notification mechanism?


> 
> On the other hand, I am flummoxed by the IESG's response.  If a WG has
> those questions above, then if the chairs predict they'll need lots more
> time to answer those questions than can be afforded during an IETF, why
> should anybody insist on YET ANOTHER FLIGHT?  Some people must really
> hate where they live.

Well, I could see if it was going to cost the IETF
extra money (it won't) or be an extra burden on the AD
who has a lot of meetings during IETF week
(who said it was okay with him).  We can have our
regular slideware 2-hour meeting on Friday like normal,
take a lunch break, go to a different room, and continue
working (or go home if you don't want to stay).

It's not just a flight.
It's the time, the travel, and the hotel costs to go
somewhere else, in addition to the regular IETF travel costs.

It's also the reality that we will get many more participants
in Montreal than any random city anybody has named, because
they are already there for all the other WGs on M-Th they
need to attend.  We WANT participation right?  (Randy Bush
once joked I should hold my RMONMIB interim in Anchorage
in January so nobody will attend and we will make decisions
faster. ;-)



> 
> Eliot

Andy

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