From owner-netconf@ops.ietf.org Mon Jul 03 12:35:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxROp-000474-Bw
	for netconf-archive@lists.ietf.org; Mon, 03 Jul 2006 12:35:51 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxROo-0002Yj-1p
	for netconf-archive@lists.ietf.org; Mon, 03 Jul 2006 12:35:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FxRJZ-000M5Z-M7
	for netconf-data@psg.com; Mon, 03 Jul 2006 16:30: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.51] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FxRJZ-000M5N-0Q
	for netconf@ops.ietf.org; Mon, 03 Jul 2006 16:30:25 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k63GUOG6006328
	for <netconf@ops.ietf.org>; Mon, 3 Jul 2006 12:30:24 -0400
Received: (qmail 18157 invoked by uid 78); 3 Jul 2006 16:30:24 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 3 Jul 2006 16:30:24 -0000
Message-ID: <44A945E1.5040607@andybierman.com>
Date: Mon, 03 Jul 2006 09:29:21 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
CC: "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Subject: Re: What about the OAM in OAM&P
References: <50B73C8966FCF840BABA099651DBE060011AB391@rchemx01.fnc.net.local>
In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB391@rchemx01.fnc.net.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: e8a67952aa972b528dd04570d58ad8fe

Hare, Michael wrote:
> Hi,
> 
> Please forgive me if this was covered.
> 
> Netconf is doing a good job of covereing the 'P' and maybe some of the 
> 'A' and 'M', but what about the 'O'?
> 
> Things like:
> 
> Software Download (not really a <copy-config>, maybe just <copy>?)
> Operating and Releasing Loopbacks/Test Signals (not really editing the 
> configuration, new verb-set?)
> Initializing PM Registers (again, not really editing the configuration)
> Protection Switching
> 
> 
> This may be outside the Netconf charter, but it seems the rpc framework 
> being used for netconf could be re-used to the other parts of network 
> management.

My position on NETCONF extensions is clear:

Vendors should develop extensions on their own, in running code,
and get some operators to use them.  When you have some
deployment experience with the extension, then propose it
as a standard.  In my experience, if a "feature" is important
enough, vendors will provide it to customers, regardless of any standard.

<config-rant>

Notifications got grandfathered in because they were in the original charter.
After that, we will be working on standards based configuration
or nothing at all.

Our focus is standards based configuration, a subject some
vendors seem to want to leave as "TBD".  Anybody who understands
embedded agent design knows why --  it is a non-trivial matter
to support multiple incompatible configuration APIs
(e.g., proprietary and standard), unlike multiple incompatible
monitoring APIs.  The problem is not "special RPC" vs. "data model" at all.


Unfortunately, the current process and mindset for IETF data models (MIBs)
is never going to work for configuration.  Somebody is
going to have to figure out how to remove 1 of the 2 adjectives
('multiple' or 'incompatible').  Maybe this is a topic for the NMRG.

</config-rant>


> 
> 
> ---------------------------------
> Michael Hare
> NMI Engineering

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 Jul 04 12:48:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxo4U-00006j-1f
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 12:48:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fxo4S-0005Nd-OO
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 12:48:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fxnzq-0005EH-UB
	for netconf-data@psg.com; Tue, 04 Jul 2006 16:43: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 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 1Fxnzq-0005Dz-EW; Tue, 04 Jul 2006 16:43:34 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k64GdwVi019997;
	Tue, 4 Jul 2006 12:39:58 -0400
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: XCAP to Proposed Standard
Date: Tue, 4 Jul 2006 19:43:31 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: XCAP to Proposed Standard
Thread-Index: AcafiPorqKLfLhcoSd+UR+Nw1IJcKg==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <netconf@ops.ietf.org>, "Ops-Nm \(E-mail\)" <ops-nm@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: 7655788c23eb79e336f5f8ba8bce7906


The XML Configuration Access Protocol (XCAP) -
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt
developped in the simple WG is on the agenda of the 7/6 IESG telechat.=20

2.1.2 Returning Item        Area Date =20
 RAI  The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) (Proposed Standard) - 1 of 1=20
   draft-ietf-simple-xcap-11.txt [Open Web Ballot] =20
   Note: Note that this document was pulled from the RFC Editor queue
and is returning with some changes, which are recorded in the tracker.=20
  Token: Jon Peterson=20
=20
Please let me know if there any questions or concerns until Wednesday
7/5 COB.=20

Dan
=20

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



From owner-netconf@ops.ietf.org Tue Jul 04 17:25:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxsOd-0006Dh-SX
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 17:25:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxsOc-0004MD-ES
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 17:25:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FxsJq-00026U-T8
	for netconf-data@psg.com; Tue, 04 Jul 2006 21:20: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=unavailable version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FxsJq-00026J-DN
	for netconf@ops.ietf.org; Tue, 04 Jul 2006 21:20:30 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k64LKQHF031107
	for <netconf@ops.ietf.org>; Tue, 4 Jul 2006 17:20:26 -0400
Received: (qmail 18265 invoked by uid 78); 4 Jul 2006 21:20:26 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 4 Jul 2006 21:20:26 -0000
Message-ID: <44AADBC7.1000608@andybierman.com>
Date: Tue, 04 Jul 2006 14:21:11 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: netconf@ops.ietf.org, "Ops-Nm (E-mail)" <ops-nm@ops.ietf.org>
Subject: Re: XCAP to Proposed Standard
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@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: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Romascanu, Dan (Dan) wrote:
> The XML Configuration Access Protocol (XCAP) -
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt
> developped in the simple WG is on the agenda of the 7/6 IESG telechat. 
> 

I looked this document over, which is not a review of any sort,
but I have a few questions:

1) Is this intended only for use with SIP?

2) Is there any access control model for securing data?
    (What is the security model?)

3) Is there a persistence model for data?
    (IMO there are problems with trying to abstract a NE device
     configuration as an XML document, and this is one of them)

4) The examples would be easier to read if the XML was pretty-printed.

5) In a general sense there is clearly overlap between NETCONF and XCAP.
    I think NETCONF tries to be more content and transport independent,
    and the RPC-based architecture is more suited to standard and vendor
    "specialized RPC" extensions, which provide a more natural
    programming paradigm than a model based on XML document manipulation.


Andy



> 2.1.2 Returning Item        Area Date  
>  RAI  The Extensible Markup Language (XML) Configuration Access Protocol
> (XCAP) (Proposed Standard) - 1 of 1 
>    draft-ietf-simple-xcap-11.txt [Open Web Ballot]  
>    Note: Note that this document was pulled from the RFC Editor queue
> and is returning with some changes, which are recorded in the tracker. 
>   Token: Jon Peterson 
>  
> Please let me know if there any questions or concerns until Wednesday
> 7/5 COB. 
> 
> 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/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 04 19:25:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxuGh-0003wB-Hi
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 19:25:23 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxuGg-0006yu-7V
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 19:25:23 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FxuCp-000BrK-CX
	for netconf-data@psg.com; Tue, 04 Jul 2006 23:21: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 
	autolearn=unavailable version=3.1.1
Received: from [207.69.195.71] (helo=pop-siberian.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FxuCo-000Bqt-6i; Tue, 04 Jul 2006 23:21:22 +0000
Received: from h-68-165-4-139.snvacaid.dynamic.covad.net ([68.165.4.139] helo=oemcomputer)
	by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FxuCn-0005Ez-00; Tue, 04 Jul 2006 19:21:21 -0400
Message-ID: <002e01c69fc0$a1c33560$6501a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netconf@ops.ietf.org>
Cc: "Ops-Nm \(E-mail\)" <ops-nm@ops.ietf.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@is0004avexu1.global.avaya.com> <44AADBC7.1000608@andybierman.com>
Subject: Re: XCAP to Proposed Standard
Date: Tue, 4 Jul 2006 16:21:51 -0700
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: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> Cc: <netconf@ops.ietf.org>; "Ops-Nm (E-mail)" <ops-nm@ops.ietf.org>
> Sent: Tuesday, July 04, 2006 2:21 PM
> Subject: Re: XCAP to Proposed Standard
...
> 5) In a general sense there is clearly overlap between NETCONF and XCAP.
>     I think NETCONF tries to be more content and transport independent,
>     and the RPC-based architecture is more suited to standard and vendor
>     "specialized RPC" extensions, which provide a more natural
>     programming paradigm than a model based on XML document manipulation.
...

However, treating configuration data as document content makes use
of existing configuration management specifications (webdav / deltav)
conceivable.

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 Tue Jul 04 20:06:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxuu2-0007MH-Fh
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 20:06:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fxuu1-0008Vy-3Y
	for netconf-archive@lists.ietf.org; Tue, 04 Jul 2006 20:06:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FxuqO-000Flf-QC
	for netconf-data@psg.com; Wed, 05 Jul 2006 00:02: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=unavailable version=3.1.1
Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FxuqO-000FlT-Av
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 00:02:16 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k6502Ctn011120
	for <netconf@ops.ietf.org>; Tue, 4 Jul 2006 20:02:12 -0400
Received: (qmail 5687 invoked by uid 78); 5 Jul 2006 00:02:12 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 5 Jul 2006 00:02:12 -0000
Message-ID: <44AB01BD.9010506@andybierman.com>
Date: Tue, 04 Jul 2006 17:03:09 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: netconf@ops.ietf.org, "Ops-Nm (E-mail)" <ops-nm@ops.ietf.org>
Subject: Re: XCAP to Proposed Standard
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@is0004avexu1.global.avaya.com> <44AADBC7.1000608@andybierman.com> <002e01c69fc0$a1c33560$6501a8c0@oemcomputer>
In-Reply-To: <002e01c69fc0$a1c33560$6501a8c0@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <ietf@andybierman.com>
>> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
>> Cc: <netconf@ops.ietf.org>; "Ops-Nm (E-mail)" <ops-nm@ops.ietf.org>
>> Sent: Tuesday, July 04, 2006 2:21 PM
>> Subject: Re: XCAP to Proposed Standard
> ...
>> 5) In a general sense there is clearly overlap between NETCONF and XCAP.
>>     I think NETCONF tries to be more content and transport independent,
>>     and the RPC-based architecture is more suited to standard and vendor
>>     "specialized RPC" extensions, which provide a more natural
>>     programming paradigm than a model based on XML document manipulation.
> ...
> 
> However, treating configuration data as document content makes use
> of existing configuration management specifications (webdav / deltav)
> conceivable.

Sure.
I don't want to stop anybody from managing an NE device this way.
NE device configuration is an area of standardization that nobody
can claim any significant success yet, so "overlap" isn't a valid
argument. IMO, the RPC approach has more potential, but time will
tell either way.

> 
> 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 Wed Jul 05 09:46:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy7hv-0003GV-61
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 09:46:23 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy7hr-0001UF-L0
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 09:46:23 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy7Zj-000As5-TK
	for netconf-data@psg.com; Wed, 05 Jul 2006 13:37: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 [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fy7Zj-000Arr-9f
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 13:37:55 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EBEF4F0052;
	Wed,  5 Jul 2006 15:37:54 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 15:37:53 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 15:37:53 +0200
Message-ID: <44ABC090.8090503@ericsson.com>
Date: Wed, 05 Jul 2006 15:37:20 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Andy Bierman <ietf@andybierman.com>, 
 Sharon Chisholm <schishol@nortel.com>,
  netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net>
In-Reply-To: <200606281600.k5SG0fwn064717@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2006 13:37:53.0089 (UTC) FILETIME=[372C2310:01C6A038]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

I think before the data models themselves we will have to tackle something like the SMI 
first, that is rules for building data models.
e.g. standard datatypes, documentation rules, etc.
Balazs

Phil Shafer wrote:
> Andy Bierman writes:
>> There are many people (including myself) who believe that
>> standard configuration data models are a critical component
>> to a complete standards based solution for network configuration.
> 
> I completely agree that standard configuration data models are
> critical, but I do not agree that they are trivial.  I think this
> is the next big hurdle for this working group.  The question on the
> floor is whether we should stop other work until we have a real
> meta-model for configuration and a way of specifying standard data
> models that will work in the real world.  If so, let's stop talking
> about notifications and get our butts in gear on modeling.
> 
> 
> 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 Jul 05 10:11:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy86Z-0004zQ-3J
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:11:51 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy86W-00059n-Lr
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:11:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy838-000DuT-6J
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:08: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 autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fy837-000DuF-Hk
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:08:17 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k65E8G2I011300
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 10:08:16 -0400
Received: (qmail 4806 invoked by uid 78); 5 Jul 2006 14:08:16 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 Jul 2006 14:08:16 -0000
Message-ID: <44ABC7C3.2000809@andybierman.com>
Date: Wed, 05 Jul 2006 07:08:03 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>,
        netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABC090.8090503@ericsson.com>
In-Reply-To: <44ABC090.8090503@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: 41c17b4b16d1eedaa8395c26e9a251c4

Balazs Lengyel wrote:
> I think before the data models themselves we will have to tackle 
> something like the SMI first, that is rules for building data models.
> e.g. standard datatypes, documentation rules, etc.

Not really.  We have an SMI of sorts.
The IETF uses XSD to describe XML data models.

Standard data types: We have the XSD types.
    I think we need some XML TCs, such as the SMIv2 data types
    and the RFC 4001 TCs.  But this is an IETF-wide requirement,
    not a NETCONF requirement.

Documentation rules: We have the <documentation> annotation,
    and we use it.  We may need some documentation rules beyond
    what we already know from RFC 4181, but we don't have enough
    experience with NETCONF to know what they are yet.

Etc.: This is the part that scares me.  IMO, the best way to figure
    out if we have a good data model is to write one and see what
    happens.  If we aren't competent enough to figure out how to
    write an XML data model for notification delivery parameters,
    then it would be good to know that now.

I am strongly opposed to the specification of rules for NETCONF data
models at this time.  NETCONF is content-independent and requires
only well-formed XML payload (+ the 'operation' attribute).
Also, we do not have enough experience with NETCONF data models to
define any significant rules (beyond XSD and some TCs).

Dave H. had a good suggestion, which I will paraphrase:
If we can't figure out how to write an XML data model module,
then write a MIB module first, and then figure out how to to
convert it to XML.  I'm hoping this WG will figure out how
to write an XML configuration data model though.


Andy




> Balazs
> 
> Phil Shafer wrote:
>> Andy Bierman writes:
>>> There are many people (including myself) who believe that
>>> standard configuration data models are a critical component
>>> to a complete standards based solution for network configuration.
>>
>> I completely agree that standard configuration data models are
>> critical, but I do not agree that they are trivial.  I think this
>> is the next big hurdle for this working group.  The question on the
>> floor is whether we should stop other work until we have a real
>> meta-model for configuration and a way of specifying standard data
>> models that will work in the real world.  If so, let's stop talking
>> about notifications and get our butts in gear on modeling.
>>
>>
>> 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 Jul 05 10:18:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy8DO-0006G2-Pf
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:18:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy8DN-0005N6-Fs
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:18:54 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy88v-000EX0-KZ
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:14: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 [171.71.176.117] (helo=sj-iport-6.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1Fy88v-000EWo-7A
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:14:17 +0000
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
  by sj-iport-6.cisco.com with ESMTP; 05 Jul 2006 07:14:16 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k65EEG1D010824;
	Wed, 5 Jul 2006 07:14:16 -0700
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 k65EEGke019289;
	Wed, 5 Jul 2006 07:14:16 -0700 (PDT)
Received: from [212.254.247.3] (ams3-vpn-dhcp4641.cisco.com [10.61.82.32])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k65E8iWL007401;
	Wed, 5 Jul 2006 07:08:45 -0700
Message-ID: <44ABC933.9010304@cisco.com>
Date: Wed, 05 Jul 2006 16:14:11 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>,
        netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABC090.8090503@ericsson.com> <44ABC7C3.2000809@andybierman.com>
In-Reply-To: <44ABC7C3.2000809@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=543; t=1152108856; x=1152972856;
	c=relaxed/simple; s=sjdkim4001; h=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=20Verbs=20Again=20(was=20RE=3A=20draft-shafer-netconf-syslog-00.tx
	t);
	X=v=3Dcisco.com=3B=20h=3D2nbl7z7OC6sty56GnZe+MAyxxgM=3D; b=tHSNbH8eB1QPbIEFYUbZ+zuZBaYZpcBhnPTFTHbYkH8GVLkgRFnNFSHPHq4EIprjvd6jqgeO
	zNtoM847Fu6IA1zAhoAC7t2yYJxMFCTXgJ2XdxMCAcnA66uB+0ILT5DB;
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

Andy Bierman wrote:
> Dave H. had a good suggestion, which I will paraphrase:
> If we can't figure out how to write an XML data model module,
> then write a MIB module first, and then figure out how to to
> convert it to XML.  I'm hoping this WG will figure out how
> to write an XML configuration data model though.
This would indicate we've come full circle.  We're here in part because
MIBs failed miserably at configuration.  And if we spin in circles, that
would indicate that we are better buying rather than building.

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 Jul 05 10:23:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy8Hg-0006Ti-Bu
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:23:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy8He-0005Tk-MW
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:23:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy8DV-000F3s-AM
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:19: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.6 required=5.0 tests=AWL,BAYES_00 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 1Fy8DU-000F3W-N9
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:19:00 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 65A946E0001;
	Wed,  5 Jul 2006 16:18:59 +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, 5 Jul 2006 16:18:58 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 16:18:57 +0200
Message-ID: <44ABCA31.10803@ericsson.com>
Date: Wed, 05 Jul 2006 16:18:25 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Andy Bierman <ietf@andybierman.com>, 
 Sharon Chisholm <schishol@nortel.com>,
  netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net>
In-Reply-To: <200606281600.k5SG0fwn064717@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2006 14:18:57.0972 (UTC) FILETIME=[F45B6F40:01C6A03D]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

I think there is a misconception here: Even if we use specialized RPCs for configuring 
notification handling we still have a hidden data model in them. You still need to define 
what data can be sent in the RPCs, what they mean and how to specify them. It is just that 
you do your data modeling in an RPC instead of NV stored data.
Mapping between device specific and standard features is the same for data models or "data 
models inside RPCs".

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 Wed Jul 05 10:28:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy8Mx-000723-1O
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:28:47 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy8Mv-0005dq-Nv
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:28:47 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy8J0-000FfD-RD
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:24: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=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fy8J0-000Ff1-9R
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:24:42 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k65EOfbt029895
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 10:24:41 -0400
Received: (qmail 23005 invoked by uid 78); 5 Jul 2006 14:24:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 Jul 2006 14:24:41 -0000
Message-ID: <44ABCB99.1050608@andybierman.com>
Date: Wed, 05 Jul 2006 07:24:25 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>,
        netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABC090.8090503@ericsson.com> <44ABC7C3.2000809@andybierman.com> <44ABC933.9010304@cisco.com>
In-Reply-To: <44ABC933.9010304@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: 7baded97d9887f7a0c7e8a33c2e3ea1b

Eliot Lear wrote:
> Andy Bierman wrote:
>> Dave H. had a good suggestion, which I will paraphrase:
>> If we can't figure out how to write an XML data model module,
>> then write a MIB module first, and then figure out how to to
>> convert it to XML.  I'm hoping this WG will figure out how
>> to write an XML configuration data model though.
> This would indicate we've come full circle.  We're here in part because
> MIBs failed miserably at configuration.  And if we spin in circles, that
> would indicate that we are better buying rather than building.

Not really.
What (I think) Dave meant is that if the constructs are not very complex,
then SMIv2 can describe the data model in a way the IETF already
understands.  This is better than standing around wondering
how in the world can we define a data model.

I agree with you from the POV that I want to break out from the
"N-ary table of simple types" as the only tool in the box.
However, I don't want to stop everything and reinvent the
SMI and XSD. (We are already reinventing notifications -- that should
be enough for now. ;-)

I think we will figure something out at the interim.
Nested XML isn't that hard, and neither is a data model
for notification delivery.



> 
> 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 Wed Jul 05 11:19:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy9AN-0001wa-7Z
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:19:51 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9AL-0003Qq-MC
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:19:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy962-000Jr4-R8
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:15: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 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1Fy962-000Jqp-71
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:15:22 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp03.fnc.fujitsu.com with ESMTP; 05 Jul 2006 10:15:21 -0500
X-IronPort-AV: i="4.06,209,1149483600"; 
   d="scan'208"; a="42406635:sNHT95764808"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 10:15:21 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3A8@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
thread-index: AcaevgDovmbVKmAIQ8eLI7PuONRDdgBhvtFQ
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2

Thanks Andy.

The Notifications is what I think was confusing some of us into =
believing NETCONF was to be a complete OAMP solution since notification =
have little to do with network configuration.

From what I gather from your response NETCONF is just for the =
configuration of the network with a bit of notification thrown in.

Maybe there's a need for other WGs to define NETMAN, NETOP and NETADM to =
cover the rest. Not your problem, I understand, but I have to convience =
the folks here that things like software upgrades, loopbacks and such =
are not part of NETCONF. We will need to write proprietary RPCs for all =
that.

Thanks,

- m

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Monday, July 03, 2006 11:29 AM
To: Hare, Michael
Cc: Netconf Mailing List (E-mail)
Subject: Re: What about the OAM in OAM&P


Hare, Michael wrote:
> Hi,
>=20
> Please forgive me if this was covered.
>=20
> Netconf is doing a good job of covereing the 'P' and maybe some of the =

> 'A' and 'M', but what about the 'O'?
>=20
> Things like:
>=20
> Software Download (not really a <copy-config>, maybe just <copy>?)
> Operating and Releasing Loopbacks/Test Signals (not really editing the =

> configuration, new verb-set?)
> Initializing PM Registers (again, not really editing the =
configuration)
> Protection Switching
>=20
>=20
> This may be outside the Netconf charter, but it seems the rpc =
framework=20
> being used for netconf could be re-used to the other parts of network=20
> management.

My position on NETCONF extensions is clear:

Vendors should develop extensions on their own, in running code,
and get some operators to use them.  When you have some
deployment experience with the extension, then propose it
as a standard.  In my experience, if a "feature" is important
enough, vendors will provide it to customers, regardless of any =
standard.

<config-rant>

Notifications got grandfathered in because they were in the original =
charter.
After that, we will be working on standards based configuration
or nothing at all.

Our focus is standards based configuration, a subject some
vendors seem to want to leave as "TBD".  Anybody who understands
embedded agent design knows why --  it is a non-trivial matter
to support multiple incompatible configuration APIs
(e.g., proprietary and standard), unlike multiple incompatible
monitoring APIs.  The problem is not "special RPC" vs. "data model" at =
all.


Unfortunately, the current process and mindset for IETF data models =
(MIBs)
is never going to work for configuration.  Somebody is
going to have to figure out how to remove 1 of the 2 adjectives
('multiple' or 'incompatible').  Maybe this is a topic for the NMRG.

</config-rant>


>=20
>=20
> ---------------------------------
> Michael Hare
> NMI Engineering

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 Jul 05 11:20:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy9BT-00024i-8u
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:20:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9BS-0003Ti-Px
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:20:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy978-000K0R-Vj
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:16: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.53] (helo=omr3.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fy978-000K0C-6Z
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:16:30 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k65FGSFX024312
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 11:16:28 -0400
Received: (qmail 21351 invoked by uid 78); 5 Jul 2006 15:13:24 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 5 Jul 2006 15:13:24 -0000
Message-ID: <44ABD706.3040909@andybierman.com>
Date: Wed, 05 Jul 2006 08:13:10 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>,
        netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABC090.8090503@ericsson.com> <44ABC7C3.2000809@andybierman.com> <44ABCDB3.5060902@ericsson.com>
In-Reply-To: <44ABCDB3.5060902@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: 932cba6e0228cc603da43d861a7e09d8

Balazs Lengyel wrote:
> So we agree that we need standard data types and textual conventions.
> 

Keep in mind that I intend to finish this work on time.
We aren't going to expand the "to-do" list if it means
blowing off the schedule.



> Some other topics I would like to see stated:
> - A method to extract the data model from the device in an XSD format 
> (Individual devices might decide that they don't want to expose this 
> even with the strictest access control, but generally I think this would 
> be good.)


IMO this is way out of bounds. It forces
everybody to use XSD for all their data models,
and the agent memory/storage requirements would force
this to be optional anyway.

Instead, a simple URL defining each schema location should be sufficient.


> - A statement that the device should advertise his data models in the 
> capability exchange

This is a good idea.
The details were already worked out on the mailing list awhile back.


> - max-access: I feel we do need it

We need normative text explaining the mapping to the protocol.
IMO, an <appinfo> construct in addition would be harmless enough,
but not worth a lot of time.


> - a statement that notification definitions should be part of a data 
> model like in SNMP

We will have an XSD for the format of NETCONF notification PDUs.
We don't have time to define machine readable constructs for
notification content abstractions.  If we define any standard notification
content, it will be included in the XSD.


> 
> Then some questions:
> - how do you indicate in a data model that a bit of data is read-only 
> configuration data or state data?

IMO -- SMIv2 MAX-ACCESS clause (mapped to NETCONF protocol of course)

> - one namespace is always one data model or is it allowed to define the 
> complete data model in one namespace in multiple modules?

There are no rules here.  I want to keep it that way.
For now, we just need a 'data' URI to go along with our 'base' URI.


> Balazs


Andy


> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> I think before the data models themselves we will have to tackle 
>>> something like the SMI first, that is rules for building data models.
>>> e.g. standard datatypes, documentation rules, etc.
>>
>> Not really.  We have an SMI of sorts.
>> The IETF uses XSD to describe XML data models.
>>
>> Standard data types: We have the XSD types.
>>    I think we need some XML TCs, such as the SMIv2 data types
>>    and the RFC 4001 TCs.  But this is an IETF-wide requirement,
>>    not a NETCONF requirement.
>>
>> Documentation rules: We have the <documentation> annotation,
>>    and we use it.  We may need some documentation rules beyond
>>    what we already know from RFC 4181, but we don't have enough
>>    experience with NETCONF to know what they are yet.
>>
>> Etc.: This is the part that scares me.  IMO, the best way to figure
>>    out if we have a good data model is to write one and see what
>>    happens.  If we aren't competent enough to figure out how to
>>    write an XML data model for notification delivery parameters,
>>    then it would be good to know that now.
>>
>> I am strongly opposed to the specification of rules for NETCONF data
>> models at this time.  NETCONF is content-independent and requires
>> only well-formed XML payload (+ the 'operation' attribute).
>> Also, we do not have enough experience with NETCONF data models to
>> define any significant rules (beyond XSD and some TCs).
>>
>> Dave H. had a good suggestion, which I will paraphrase:
>> If we can't figure out how to write an XML data model module,
>> then write a MIB module first, and then figure out how to to
>> convert it to XML.  I'm hoping this WG will figure out how
>> to write an XML configuration data model though.
>>
>>
>> Andy
>>
>>
>>
>>
>>> Balazs
>>>
>>> Phil Shafer wrote:
>>>> Andy Bierman writes:
>>>>> There are many people (including myself) who believe that
>>>>> standard configuration data models are a critical component
>>>>> to a complete standards based solution for network configuration.
>>>>
>>>> I completely agree that standard configuration data models are
>>>> critical, but I do not agree that they are trivial.  I think this
>>>> is the next big hurdle for this working group.  The question on the
>>>> floor is whether we should stop other work until we have a real
>>>> meta-model for configuration and a way of specifying standard data
>>>> models that will work in the real world.  If so, let's stop talking
>>>> about notifications and get our butts in gear on modeling.
>>>>
>>>>
>>>> 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 Jul 05 11:32:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy9MR-0003mY-80
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:32:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9MP-0003zH-O1
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:32:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy9Iu-000KqW-0D
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:28: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 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 1Fy9It-000KqH-CH
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:28:39 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k65FScFR018353;
	Wed, 5 Jul 2006 08:28:38 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k65FScAl018350;
	Wed, 5 Jul 2006 08:28:38 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 5 Jul 2006 08:28:38 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
cc: "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Subject: RE: What about the OAM in OAM&P
In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB3A8@rchemx01.fnc.net.local>
Message-ID: <Pine.LNX.4.10.10607050820590.30969-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: c83ccb5cc10e751496398f1233ca9c3a

HI,

Some of us believe that notifications are a huge part of
configuration management. 

On Wed, 5 Jul 2006, Hare, Michael wrote:
> Thanks Andy.
> 
> The Notifications is what I think was confusing some of us into
> believing NETCONF was to be a complete OAMP solution since
> notification have little to do with network configuration.
> 
> >From what I gather from your response NETCONF is just for 
> >the configuration of the network with a bit of notification
> >thrown in.
> 
> Maybe there's a need for other WGs to define NETMAN, NETOP and
> NETADM to cover the rest. Not your problem, I understand, but I
> have to convience the folks here that things like software
> upgrades, loopbacks and such are not part of NETCONF. We will
> need to write proprietary RPCs for all that.
I'm crying now. Andy and you are talking at different levels
without true understanding nor communication.

Michael - why do you use the term OAM&P?

Regards,
/david t. perkins

> 
> Thanks,
> 
> - m
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Monday, July 03, 2006 11:29 AM
> To: Hare, Michael
> Cc: Netconf Mailing List (E-mail)
> Subject: Re: What about the OAM in OAM&P
> 
> 
> Hare, Michael wrote:
> > Hi,
> > 
> > Please forgive me if this was covered.
> > 
> > Netconf is doing a good job of covereing the 'P' and maybe some of the 
> > 'A' and 'M', but what about the 'O'?
> > 
> > Things like:
> > 
> > Software Download (not really a <copy-config>, maybe just <copy>?)
> > Operating and Releasing Loopbacks/Test Signals (not really editing the 
> > configuration, new verb-set?)
> > Initializing PM Registers (again, not really editing the configuration)
> > Protection Switching
> > 
> > 
> > This may be outside the Netconf charter, but it seems the rpc framework 
> > being used for netconf could be re-used to the other parts of network 
> > management.
> 
> My position on NETCONF extensions is clear:
> 
> Vendors should develop extensions on their own, in running code,
> and get some operators to use them.  When you have some
> deployment experience with the extension, then propose it
> as a standard.  In my experience, if a "feature" is important
> enough, vendors will provide it to customers, regardless of any standard.
> 
> <config-rant>
> 
> Notifications got grandfathered in because they were in the original charter.
> After that, we will be working on standards based configuration
> or nothing at all.
> 
> Our focus is standards based configuration, a subject some
> vendors seem to want to leave as "TBD".  Anybody who understands
> embedded agent design knows why --  it is a non-trivial matter
> to support multiple incompatible configuration APIs
> (e.g., proprietary and standard), unlike multiple incompatible
> monitoring APIs.  The problem is not "special RPC" vs. "data model" at all.
> 
> 
> Unfortunately, the current process and mindset for IETF data models (MIBs)
> is never going to work for configuration.  Somebody is
> going to have to figure out how to remove 1 of the 2 adjectives
> ('multiple' or 'incompatible').  Maybe this is a topic for the NMRG.
> 
> </config-rant>
> 
> 
> > 
> > 
> > ---------------------------------
> > Michael Hare
> > NMI Engineering
> 
> 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 Jul 05 11:43:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy9Xj-0005M8-2R
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:43:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9Xg-0005Oh-H8
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:43:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy9U0-000M0g-0Y
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:40: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.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fy9Tz-000M0T-Bd
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:40:07 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k65Fe5UQ020450
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 11:40:06 -0400
Received: (qmail 12743 invoked by uid 78); 5 Jul 2006 15:38:40 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 5 Jul 2006 15:38:40 -0000
Message-ID: <44ABDCF1.4000508@andybierman.com>
Date: Wed, 05 Jul 2006 08:38:25 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
CC: "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Subject: Re: What about the OAM in OAM&P
References: <50B73C8966FCF840BABA099651DBE060011AB3A8@rchemx01.fnc.net.local>
In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB3A8@rchemx01.fnc.net.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: 50a516d93fd399dc60588708fd9a3002

Hare, Michael wrote:
> Thanks Andy.
> 
> The Notifications is what I think was confusing some of us into believing NETCONF was to be a complete OAMP solution since notification have little to do with network configuration.
> 

This is an important comment.
I agree that notifications have little to do with configuration.
SW update is much more relevant to configuration, since
(in the real world), config changes may be associated with
HW and/or SW changes.

IMO, we should either finish notifications for netconf quickly,
or drop it altogether and move on to our primary mission.

>>From what I gather from your response NETCONF is just for the configuration of the network with a bit of notification thrown in.
> 

Standards based configuration is the charter after all.
I am not opposed at all to other great features in addition
to this one.  But not instead of this one.

> Maybe there's a need for other WGs to define NETMAN, NETOP and NETADM to cover the rest. Not your problem, I understand, but I have to convience the folks here that things like software upgrades, loopbacks and such are not part of NETCONF. We will need to write proprietary RPCs for all that.
> 

It is always a good idea to make solution proposals to a WG (in an I-D),
based on experience, as well as theory.
Vendor extensions are an effective way to do that.

I won't support the chartering of any solution proposals
unless they are "functionally configurable", using standard
data models.  (So don't propose any solutions where the config
magically appears on the device -- we already have enough of those).



> Thanks,
> 
> - m
> 


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 Jul 05 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 1Fy9YS-0005dr-P5
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:44:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9YR-0005ht-9P
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:44:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy9VK-000M8V-8W
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:41: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 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1Fy9VJ-000M8G-GN
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:41:29 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp04.fnc.fujitsu.com with ESMTP; 05 Jul 2006 10:41:29 -0500
X-IronPort-AV: i="4.06,210,1149483600"; 
   d="scan'208"; a="28704115:sNHT23354760"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 10:41:28 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3A9@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
thread-index: AcagR7uPdzQDWWwRRnSO4kDJI1LYfAAALGbA
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7

Hi David,

Maybe. Plenty of notifications are not configuration based. DB Change =
Notifications are, but Alarms, TCAs, PM Reports are not config based. =
Could just be my view of things. But here, there is an expectation that =
Netconf will be a replacement for TL1.

OAMP, forgive me, I've been basically telecom based for many years now.
O - Operations
A - Administration
M - Maintenance
P - Provisioning

maybe FCAPS is a better, more up to date term.

G'day,

- m





-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]
Sent: Wednesday, July 05, 2006 10:29 AM
To: Hare, Michael
Cc: Netconf Mailing List (E-mail)
Subject: RE: What about the OAM in OAM&P


HI,

Some of us believe that notifications are a huge part of
configuration management.=20

On Wed, 5 Jul 2006, Hare, Michael wrote:
> Thanks Andy.
>=20
> The Notifications is what I think was confusing some of us into
> believing NETCONF was to be a complete OAMP solution since
> notification have little to do with network configuration.
>=20
> >From what I gather from your response NETCONF is just for=20
> >the configuration of the network with a bit of notification
> >thrown in.
>=20
> Maybe there's a need for other WGs to define NETMAN, NETOP and
> NETADM to cover the rest. Not your problem, I understand, but I
> have to convience the folks here that things like software
> upgrades, loopbacks and such are not part of NETCONF. We will
> need to write proprietary RPCs for all that.
I'm crying now. Andy and you are talking at different levels
without true understanding nor communication.

Michael - why do you use the term OAM&P?

Regards,
/david t. perkins

>=20
> Thanks,
>=20
> - m
>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Monday, July 03, 2006 11:29 AM
> To: Hare, Michael
> Cc: Netconf Mailing List (E-mail)
> Subject: Re: What about the OAM in OAM&P
>=20
>=20
> Hare, Michael wrote:
> > Hi,
> >=20
> > Please forgive me if this was covered.
> >=20
> > Netconf is doing a good job of covereing the 'P' and maybe some of =
the=20
> > 'A' and 'M', but what about the 'O'?
> >=20
> > Things like:
> >=20
> > Software Download (not really a <copy-config>, maybe just <copy>?)
> > Operating and Releasing Loopbacks/Test Signals (not really editing =
the=20
> > configuration, new verb-set?)
> > Initializing PM Registers (again, not really editing the =
configuration)
> > Protection Switching
> >=20
> >=20
> > This may be outside the Netconf charter, but it seems the rpc =
framework=20
> > being used for netconf could be re-used to the other parts of =
network=20
> > management.
>=20
> My position on NETCONF extensions is clear:
>=20
> Vendors should develop extensions on their own, in running code,
> and get some operators to use them.  When you have some
> deployment experience with the extension, then propose it
> as a standard.  In my experience, if a "feature" is important
> enough, vendors will provide it to customers, regardless of any =
standard.
>=20
> <config-rant>
>=20
> Notifications got grandfathered in because they were in the original =
charter.
> After that, we will be working on standards based configuration
> or nothing at all.
>=20
> Our focus is standards based configuration, a subject some
> vendors seem to want to leave as "TBD".  Anybody who understands
> embedded agent design knows why --  it is a non-trivial matter
> to support multiple incompatible configuration APIs
> (e.g., proprietary and standard), unlike multiple incompatible
> monitoring APIs.  The problem is not "special RPC" vs. "data model" at =
all.
>=20
>=20
> Unfortunately, the current process and mindset for IETF data models =
(MIBs)
> is never going to work for configuration.  Somebody is
> going to have to figure out how to remove 1 of the 2 adjectives
> ('multiple' or 'incompatible').  Maybe this is a topic for the NMRG.
>=20
> </config-rant>
>=20
>=20
> >=20
> >=20
> > ---------------------------------
> > Michael Hare
> > NMI Engineering
>=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

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 05 11:57:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy9kN-0004I6-7T
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:57:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy9kL-0007B2-Qd
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:57:03 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy9g3-000N3Y-Ug
	for netconf-data@psg.com; Wed, 05 Jul 2006 15:52: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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1Fy9g3-000N3K-8Y
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 15:52:35 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp03.fnc.fujitsu.com with ESMTP; 05 Jul 2006 10:52:34 -0500
X-IronPort-AV: i="4.06,210,1149483600"; 
   d="scan'208"; a="42411559:sNHT20958356"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 10:52:34 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3AA@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
thread-index: AcagSVLNO+gskGoGRTmZgdrktOF04AAAHvmw
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168

SW Update can affect configuration, but it's not really reflected in a =
'show config' type operation (outside of a version id and maybe a date =
or two).
Most everything on the box either affects or is affected by the =
configuration. But I bet you don't want to rationalize everything back =
to a config change.
You'll be here much longer than you intended.

Focusing on the configuration aspects is a good idea.

Eventually, the focus will need to include these other areas. If we just =
did Netconf without anything else, our in-house management system would =
refuse to use it because they'd still have to use TL1 (or whatever) to =
manage the rest of the box. They don't want to do that. One box : One =
Interface.

Not to worry, I have no desire to de-rail Netconf with additional work. =
You all have enough on your plate as it is.
However, this must be a common problem for vendors implementing Netconf. =
I'd be open to side discussions, meaning away from this mailing list, =
with anyone interested in persuing other aspects of an XML rpc based =
management solution.

Thanks,

- m



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Wednesday, July 05, 2006 10:38 AM
To: Hare, Michael
Cc: Netconf Mailing List (E-mail)
Subject: Re: What about the OAM in OAM&P


Hare, Michael wrote:
> Thanks Andy.
>=20
> The Notifications is what I think was confusing some of us into =
believing NETCONF was to be a complete OAMP solution since notification =
have little to do with network configuration.
>=20

This is an important comment.
I agree that notifications have little to do with configuration.
SW update is much more relevant to configuration, since
(in the real world), config changes may be associated with
HW and/or SW changes.

IMO, we should either finish notifications for netconf quickly,
or drop it altogether and move on to our primary mission.

>>From what I gather from your response NETCONF is just for the =
configuration of the network with a bit of notification thrown in.
>=20

Standards based configuration is the charter after all.
I am not opposed at all to other great features in addition
to this one.  But not instead of this one.

> Maybe there's a need for other WGs to define NETMAN, NETOP and NETADM =
to cover the rest. Not your problem, I understand, but I have to =
convience the folks here that things like software upgrades, loopbacks =
and such are not part of NETCONF. We will need to write proprietary RPCs =
for all that.
>=20

It is always a good idea to make solution proposals to a WG (in an I-D),
based on experience, as well as theory.
Vendor extensions are an effective way to do that.

I won't support the chartering of any solution proposals
unless they are "functionally configurable", using standard
data models.  (So don't propose any solutions where the config
magically appears on the device -- we already have enough of those).



> Thanks,
>=20
> - m
>=20


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 Jul 05 12:17:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyA3n-0007aB-TM
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:17:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyA3m-00084w-Jm
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:17:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyA06-000PCw-TP
	for netconf-data@psg.com; Wed, 05 Jul 2006 16:13: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 [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 1FyA06-000PCh-Db
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 16:13:18 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65G9d97023414
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 12:09:39 -0400
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: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 19:13:15 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC88409@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
Thread-Index: AcaevgDovmbVKmAIQ8eLI7PuONRDdgBhvtFQAAIr/4A=
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>,
        "Netconf Mailing List \(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: 97adf591118a232206bdb5a27b217034

Michael,

Can you define MAN, OP and ADM?=20

Thanks,

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> Sent: Wednesday, July 05, 2006 6:15 PM
> To: Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
>=20
> Maybe there's a need for other WGs to define NETMAN, NETOP=20
> and NETADM to cover the rest. Not your problem, I understand,=20
> but I have to convience the folks here that things like=20
> software upgrades, loopbacks and such are not part of=20
> NETCONF. We will need to write proprietary RPCs for all that.
>=20
> Thanks,



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



From owner-netconf@ops.ietf.org Wed Jul 05 12:30:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyAGz-0005Ax-Ht
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:30:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyAGy-0008T2-8a
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:30:45 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyADs-0000rI-Bw
	for netconf-data@psg.com; Wed, 05 Jul 2006 16:27: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 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1FyADr-0000r4-RD
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 16:27:31 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp04.fnc.fujitsu.com with ESMTP; 05 Jul 2006 11:27:31 -0500
X-IronPort-AV: i="4.06,210,1149483600"; 
   d="scan'208"; a="28707420:sNHT19668024"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 11:27:30 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3AB@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
thread-index: AcaevgDovmbVKmAIQ8eLI7PuONRDdgBhvtFQAAIr/4AAADscEA==
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

MAN : Maintenance
OP : Operations
ADM : Administrative

Some of this, like alarms and alarm config are covered by Netconf.
Others like SW upgrades and Test Signals is not.

- m

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 05, 2006 11:13 AM
To: Hare, Michael; Netconf Mailing List (E-mail)
Subject: RE: What about the OAM in OAM&P


Michael,

Can you define MAN, OP and ADM?=20

Thanks,

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> Sent: Wednesday, July 05, 2006 6:15 PM
> To: Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
>=20
> Maybe there's a need for other WGs to define NETMAN, NETOP=20
> and NETADM to cover the rest. Not your problem, I understand,=20
> but I have to convience the folks here that things like=20
> software upgrades, loopbacks and such are not part of=20
> NETCONF. We will need to write proprietary RPCs for all that.
>=20
> Thanks,

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



From owner-netconf@ops.ietf.org Wed Jul 05 12:44:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyAU5-0003k1-6N
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:44:17 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyAU3-0000ut-Rm
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:44:17 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyAQi-0002NZ-Mv
	for netconf-data@psg.com; Wed, 05 Jul 2006 16:40: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 [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 1FyAQh-0002NE-R4
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 16:40:47 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65GZvlD003996
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 12:35:58 -0400
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: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 19:40:44 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC8842F@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
Thread-Index: AcaevgDovmbVKmAIQ8eLI7PuONRDdgBhvtFQAAIr/4AAADscEAAAjINA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>,
        "Netconf Mailing List \(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: 6cca30437e2d04f45110f2ff8dc1b1d5

Well, that much I figured out as well, but I was hoping for some
definitions :-)

IMO we need to make a distinction between applications or services and
management operations. It looks to me that MAN, OP and ADM do not refer
strictly to a well (?) defined class of management operations as CONF
does.=20

Dan

BTW - you mentioned Test Signals - are you on the ntdp list?=20

=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> Sent: Wednesday, July 05, 2006 7:28 PM
> To: Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
> MAN : Maintenance
> OP : Operations
> ADM : Administrative
>=20
> Some of this, like alarms and alarm config are covered by Netconf.
> Others like SW upgrades and Test Signals is not.
>=20
> - m
>=20
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Wednesday, July 05, 2006 11:13 AM
> To: Hare, Michael; Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
>=20
> Michael,
>=20
> Can you define MAN, OP and ADM?=20
>=20
> Thanks,
>=20
> Dan
>=20
>=20
> =20
> =20
>=20
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> > Sent: Wednesday, July 05, 2006 6:15 PM
> > To: Netconf Mailing List (E-mail)
> > Subject: RE: What about the OAM in OAM&P
> >=20
> >=20
> > Maybe there's a need for other WGs to define NETMAN, NETOP=20
> and NETADM=20
> > to cover the rest. Not your problem, I understand, but I have to=20
> > convience the folks here that things like software=20
> upgrades, loopbacks=20
> > and such are not part of NETCONF. We will need to write proprietary=20
> > RPCs for all that.
> >=20
> > Thanks,
>=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 Jul 05 12:54:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyAe6-0004Fl-TX
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:54:38 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyAe5-0001OX-GS
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 12:54:38 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyAaR-0003Ch-8z
	for netconf-data@psg.com; Wed, 05 Jul 2006 16:50: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 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1FyAaQ-0003CU-KJ
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 16:50:50 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp03.fnc.fujitsu.com with ESMTP; 05 Jul 2006 11:50:49 -0500
X-IronPort-AV: i="4.06,210,1149483600"; 
   d="scan'208"; a="42418380:sNHT24746136"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P
Date: Wed, 5 Jul 2006 11:50:49 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3AD@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P
thread-index: AcaevgDovmbVKmAIQ8eLI7PuONRDdgBhvtFQAAIr/4AAADscEAAAjINAAABj92A=
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>,
	"Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db

OK, I wasn't sure :)

I basically go with:
Maintenance : Alarms, Alarm Config, Loopbacks, test signals, SW upgrades
Operations: System Turnup,=20
Administrative: Billing, SLAs,

But your point is well taken. I don't think the silos are that well =
defined.

- m

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 05, 2006 11:41 AM
To: Hare, Michael; Netconf Mailing List (E-mail)
Subject: RE: What about the OAM in OAM&P


Well, that much I figured out as well, but I was hoping for some
definitions :-)

IMO we need to make a distinction between applications or services and
management operations. It looks to me that MAN, OP and ADM do not refer
strictly to a well (?) defined class of management operations as CONF
does.=20

Dan

BTW - you mentioned Test Signals - are you on the ntdp list?=20

=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> Sent: Wednesday, July 05, 2006 7:28 PM
> To: Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
> MAN : Maintenance
> OP : Operations
> ADM : Administrative
>=20
> Some of this, like alarms and alarm config are covered by Netconf.
> Others like SW upgrades and Test Signals is not.
>=20
> - m
>=20
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Wednesday, July 05, 2006 11:13 AM
> To: Hare, Michael; Netconf Mailing List (E-mail)
> Subject: RE: What about the OAM in OAM&P
>=20
>=20
> Michael,
>=20
> Can you define MAN, OP and ADM?=20
>=20
> Thanks,
>=20
> Dan
>=20
>=20
> =20
> =20
>=20
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Hare, Michael
> > Sent: Wednesday, July 05, 2006 6:15 PM
> > To: Netconf Mailing List (E-mail)
> > Subject: RE: What about the OAM in OAM&P
> >=20
> >=20
> > Maybe there's a need for other WGs to define NETMAN, NETOP=20
> and NETADM=20
> > to cover the rest. Not your problem, I understand, but I have to=20
> > convience the folks here that things like software=20
> upgrades, loopbacks=20
> > and such are not part of NETCONF. We will need to write proprietary=20
> > RPCs for all that.
> >=20
> > Thanks,
>=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 Jul 05 13:22:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyB57-0001Y5-HI
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 13:22:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyB55-0003JF-1K
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 13:22:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyB1y-0006US-Ej
	for netconf-data@psg.com; Wed, 05 Jul 2006 17:19: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=BAYES_00 
	autolearn=unavailable version=3.1.1
Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <joel@stevecrocker.com>)
	id 1FyB1x-0006U3-9y; Wed, 05 Jul 2006 17:19:17 +0000
Received: from [162.83.109.253] (helo=JMHLap3.stevecrocker.com)
	by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34)
	id 1FyB1t-0004ET-5O; Wed, 05 Jul 2006 13:19:13 -0400
Message-Id: <7.0.1.0.0.20060705131014.032f39f8@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 05 Jul 2006 13:19:11 -0400
To: Andy Bierman <ietf@andybierman.com>,
 "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: XCAP to Proposed Standard
Cc: netconf@ops.ietf.org,"Ops-Nm (E-mail)" <ops-nm@ops.ietf.org>
In-Reply-To: <44AADBC7.1000608@andybierman.com>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AC54181@is0004avexu1.global.avaya.com>
 <44AADBC7.1000608@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120c5cccefe6267a63c4a95d2307dd0558f8a8c4df56ca17738350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 162.83.109.253
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db

I can give you my take on these questions.

With regard to the intended use, to some degree there is a primary 
use and some additional / alternative uses.  The primary use for XCAP 
is to allow individual users of a service to configure the properties 
of their usage.  This would, for example, include a user on a cell 
phone updating his preferences or his buddy list, or his privacy policy, or ...
On the other hand, I had used XCAP to manipulate the configuration of 
a deep packet inspection device.  It was easy to do.  I could get it 
running.  It gave me a state oriented view of the configuration of 
the device, rather than an operation oriented view.  Which matched 
what I needed.

The access control model for XCAP is implicit.  That is, it is 
expected that one is using HTTPS, that one has logged in as a 
specific user, and normally the documents one has visibility to are 
those for that user (see primary use case above.)  For device 
configuration, the userid that was logged in would restrict the 
visibility / write permission for the configuration.

With regard to persistence, in the normal use case it is assumed that 
the change is applied to the users documents, and takes effect 
immediately and permanently.  The SIP working group has not (and 
would not) discuss running vs startup config.  I made some choices 
when I abused XCAP for that purpose.  (I believe that if that usage 
actually mattered one would distinguish using different file 
identifiers after the application usage.)

There are significant differences in perspective between NETCONF and 
XCAP.  While I note that I presonally like XCAP for configuration, 
there are some definite issues with using it.  There are some very 
good reasons for using NETCONF, among them a much easier adoption 
path.  So I don't think anyone is asking that NETCONF stop and switch to XCAP.
At the same time, the primary XCAP problem is quite different from 
NETCONF's, and derailing work in that direction likely makes as little sense.

Yours,
Joel

At 05:21 PM 7/4/2006, Andy Bierman wrote:
>Romascanu, Dan (Dan) wrote:
>>The XML Configuration Access Protocol (XCAP) -
>>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt
>>developped in the simple WG is on the agenda of the 7/6 IESG telechat.
>
>I looked this document over, which is not a review of any sort,
>but I have a few questions:
>
>1) Is this intended only for use with SIP?
>
>2) Is there any access control model for securing data?
>    (What is the security model?)
>
>3) Is there a persistence model for data?
>    (IMO there are problems with trying to abstract a NE device
>     configuration as an XML document, and this is one of them)
>
>4) The examples would be easier to read if the XML was pretty-printed.
>
>5) In a general sense there is clearly overlap between NETCONF and XCAP.
>    I think NETCONF tries to be more content and transport independent,
>    and the RPC-based architecture is more suited to standard and vendor
>    "specialized RPC" extensions, which provide a more natural
>    programming paradigm than a model based on XML document manipulation.
>
>
>Andy
>
>
>
>>2.1.2 Returning Item        Area Date
>>  RAI  The Extensible Markup Language (XML) Configuration Access Protocol
>>(XCAP) (Proposed Standard) - 1 of 
>>1    draft-ietf-simple-xcap-11.txt [Open Web Ballot]
>>    Note: Note that this document was pulled from the RFC Editor queue
>>and is returning with some changes, which are recorded in the 
>>tracker.   Token: Jon Peterson  Please let me know if there any 
>>questions or concerns until Wednesday
>>7/5 COB.
>>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/>
>
>
>--
>to unsubscribe send a message to netconf-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 Jul 05 13:26:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyB8q-00063u-Op
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 13:26:24 -0400
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 1Fy8y3-0002nj-8b
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:07:07 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fy8Vs-0002JO-3q
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:38:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy8T3-000Ggx-KG
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:35: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 autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fy8T3-000GgY-1f
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:35:05 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k65EZ4K2010039
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 10:35:04 -0400
Received: (qmail 2657 invoked by uid 78); 5 Jul 2006 14:35:04 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 Jul 2006 14:35:04 -0000
Message-ID: <44ABCE08.8020808@andybierman.com>
Date: Wed, 05 Jul 2006 07:34:48 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>,
        netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABCA31.10803@ericsson.com>
In-Reply-To: <44ABCA31.10803@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: -2.4 (--)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

Balazs Lengyel wrote:
> I think there is a misconception here: Even if we use specialized RPCs 
> for configuring notification handling we still have a hidden data model 
> in them. You still need to define what data can be sent in the RPCs, 
> what they mean and how to specify them. It is just that you do your data 
> modeling in an RPC instead of NV stored data.
> Mapping between device specific and standard features is the same for 
> data models or "data models inside RPCs".

I pointed this out a few times already.  I suggested:

1) Move the NV-stored parameters to a data model,
    and leave the session parameters in the RPC.

2) Define the absolute path (from the conceptual <config> & <data> root)
    to the data model root.

3) There is no need for special <get> functions to retrieve state
    info for notification delivery activity and statistics.  They are
    just part of the data model.

> 
> 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/>



From owner-netconf@ops.ietf.org Wed Jul 05 13:28:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyBAu-0007Un-2j
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 13:28:32 -0400
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 1Fy8y3-0002nj-Ad
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 11:07:07 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fy8VF-0002Io-QH
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 10:37:24 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fy8Ry-000GYD-NK
	for netconf-data@psg.com; Wed, 05 Jul 2006 14:33: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 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 1Fy8Rx-000GXy-PU
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 14:33:58 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C97F05E0002;
	Wed,  5 Jul 2006 16:33:56 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 16:33:56 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 16:33:55 +0200
Message-ID: <44ABCDB3.5060902@ericsson.com>
Date: Wed, 05 Jul 2006 16:33:23 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>, 
 netconf@ops.ietf.org
Subject: Do we need data modeling rules like an SMI 
References: <200606281600.k5SG0fwn064717@idle.juniper.net> <44ABC090.8090503@ericsson.com> <44ABC7C3.2000809@andybierman.com>
In-Reply-To: <44ABC7C3.2000809@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2006 14:33:55.0915 (UTC) FILETIME=[0B92A9B0:01C6A040]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1

So we agree that we need standard data types and textual conventions.

Some other topics I would like to see stated:
- A method to extract the data model from the device in an XSD format (Individual devices 
might decide that they don't want to expose this even with the strictest access control, 
but generally I think this would be good.)
- A statement that the device should advertise his data models in the capability exchange
- max-access: I feel we do need it
- a statement that notification definitions should be part of a data model like in SNMP

Then some questions:
- how do you indicate in a data model that a bit of data is read-only configuration data 
or state data?
- one namespace is always one data model or is it allowed to define the complete data 
model in one namespace in multiple modules?
Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> I think before the data models themselves we will have to tackle 
>> something like the SMI first, that is rules for building data models.
>> e.g. standard datatypes, documentation rules, etc.
> 
> Not really.  We have an SMI of sorts.
> The IETF uses XSD to describe XML data models.
> 
> Standard data types: We have the XSD types.
>    I think we need some XML TCs, such as the SMIv2 data types
>    and the RFC 4001 TCs.  But this is an IETF-wide requirement,
>    not a NETCONF requirement.
> 
> Documentation rules: We have the <documentation> annotation,
>    and we use it.  We may need some documentation rules beyond
>    what we already know from RFC 4181, but we don't have enough
>    experience with NETCONF to know what they are yet.
> 
> Etc.: This is the part that scares me.  IMO, the best way to figure
>    out if we have a good data model is to write one and see what
>    happens.  If we aren't competent enough to figure out how to
>    write an XML data model for notification delivery parameters,
>    then it would be good to know that now.
> 
> I am strongly opposed to the specification of rules for NETCONF data
> models at this time.  NETCONF is content-independent and requires
> only well-formed XML payload (+ the 'operation' attribute).
> Also, we do not have enough experience with NETCONF data models to
> define any significant rules (beyond XSD and some TCs).
> 
> Dave H. had a good suggestion, which I will paraphrase:
> If we can't figure out how to write an XML data model module,
> then write a MIB module first, and then figure out how to to
> convert it to XML.  I'm hoping this WG will figure out how
> to write an XML configuration data model though.
> 
> 
> Andy
> 
> 
> 
> 
>> Balazs
>>
>> Phil Shafer wrote:
>>> Andy Bierman writes:
>>>> There are many people (including myself) who believe that
>>>> standard configuration data models are a critical component
>>>> to a complete standards based solution for network configuration.
>>>
>>> I completely agree that standard configuration data models are
>>> critical, but I do not agree that they are trivial.  I think this
>>> is the next big hurdle for this working group.  The question on the
>>> floor is whether we should stop other work until we have a real
>>> meta-model for configuration and a way of specifying standard data
>>> models that will work in the real world.  If so, let's stop talking
>>> about notifications and get our butts in gear on modeling.
>>>
>>>
>>> Thanks,
>>>  Phil
>>
>>
> 

-- 
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 Jul 05 14:19:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyBy5-0004Zp-Ep
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 14:19:21 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyBy0-0008ME-So
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 14:19:21 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyBto-000CFZ-UO
	for netconf-data@psg.com; Wed, 05 Jul 2006 18:14: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 [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FyBto-000CFG-8r
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 18:14:56 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1EF245E0005;
	Wed,  5 Jul 2006 20:14:55 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 20:14:53 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 20:14:53 +0200
Message-ID: <44AC019C.2050201@ericsson.com>
Date: Wed, 05 Jul 2006 20:14:52 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: our first CLR
References: <44A5BBEA.40306@andybierman.com>
In-Reply-To: <44A5BBEA.40306@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2006 18:14:53.0205 (UTC) FILETIME=[E9889450:01C6A05E]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

I am fighting to be able to send late replies to operations. The most likely method to do 
this will be a notification that refers to the original operation. To be able to refer to 
it we need the sessionId and the messageId. So Ericsson is in an immediate need of the 
messageId.
Balazs

Andy Bierman wrote:
> Hi,
> 
> Didn't anybody notice that the protocol spec makes a big
> deal about a mandatory message-id (and I made a big deal
> about limiting its length), but it isn't used anywhere
> in the document in a normative manner?
> 
> Nope.  We took out the only operation that depended on
> the message-id attribute a couple years ago.
> The agent totally ignores this attribute except to
> check if needs to generate an error if it is missing.
> 
> If that isn't the essence of a Crappy Little Rule,
> I don't know what is.  (I know, we may need the
> message-id someday, but not now.)
> 
> 
> 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 Wed Jul 05 14:37:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyCFA-00065Y-Ht
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 14:37:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyCF9-0000mP-16
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 14:37:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyCB0-000EcW-Du
	for netconf-data@psg.com; Wed, 05 Jul 2006 18:32: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.6 required=5.0 tests=AWL,BAYES_00 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 1FyCAz-000EcJ-R8
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 18:32:42 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AAF4F4F0113;
	Wed,  5 Jul 2006 20:32:40 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 20:32:09 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Jul 2006 20:32:08 +0200
Message-ID: <44AC05A8.20005@ericsson.com>
Date: Wed, 05 Jul 2006 20:32:08 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC:  netconf@ops.ietf.org
Subject: Re: draft-shafer-netconf-syslog-00.txt
References: <200606262121.k5QLLewn055980@idle.juniper.net>
In-Reply-To: <200606262121.k5QLLewn055980@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2006 18:32:08.0755 (UTC) FILETIME=[52C4F830:01C6A061]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a



Phil Shafer wrote:
> Balazs Lengyel writes:
>> 1) I want to fetch recorded data from yesterday 12:00Z till
>> 13:00Z. The draft doesn't seem
>> to allow this as the stop time is already in the past. I would allow this!
> 
> The draft allows this; see 3.2.1.1 (Closing the Response).
> 
Quoted from the draft:
==============================
The RPC response will be closed when one of the following conditions
    are met:

    o  the <stop-time> parameter was given and the specified time has
       past
================================
If the stop time is already in the past when you start the RPC it will stop immediately 
and not deliver historical data.

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 Wed Jul 05 15:20:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyCvj-0000N9-B6
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:20:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyCvi-0001BS-26
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:20:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyCry-000J5Y-Jv
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:17: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 [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 1FyCry-000J5N-6H
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:17:06 +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 k65JH41Z004068;
	Wed, 5 Jul 2006 12:17:04 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65JH3503985;
	Wed, 5 Jul 2006 12:17:03 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k65JH3wn087960;
	Wed, 5 Jul 2006 15:17:03 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200607051917.k65JH3wn087960@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: netconf@ops.ietf.org
Subject: Re: draft-shafer-netconf-syslog-00.txt 
In-Reply-To: Your message of "Wed, 05 Jul 2006 20:32:08 +0200."
             <44AC05A8.20005@ericsson.com> 
Date: Wed, 05 Jul 2006 15:17:03 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

Ah!  I'll reword this.  Thanks....



Balazs Lengyel writes:
>
>
>Phil Shafer wrote:
>> Balazs Lengyel writes:
>>> 1) I want to fetch recorded data from yesterday 12:00Z till
>>> 13:00Z. The draft doesn't seem
>>> to allow this as the stop time is already in the past. I would allow this!
>> 
>> The draft allows this; see 3.2.1.1 (Closing the Response).
>> 
>Quoted from the draft:
>==============================
>The RPC response will be closed when one of the following conditions
>    are met:
>
>    o  the <stop-time> parameter was given and the specified time has
>       past
>================================
>If the stop time is already in the past when you start the RPC it will stop immediately 
>and not deliver historical data.
>
>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 Wed Jul 05 15:31:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD6D-00026A-Pn
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:31:49 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyD6C-0003qX-Fs
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:31:49 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyD3u-000KTq-2l
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:29: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.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 1FyD3t-000KTd-LZ
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:29: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 k65JTO1Z004228;
	Wed, 5 Jul 2006 12:29:24 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65JTN506561;
	Wed, 5 Jul 2006 12:29:23 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k65JTNwn088157;
	Wed, 5 Jul 2006 15:29:23 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200607051929.k65JTNwn088157@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: our first CLR 
In-Reply-To: Your message of "Fri, 30 Jun 2006 17:03:54 PDT."
             <44A5BBEA.40306@andybierman.com> 
Date: Wed, 05 Jul 2006 15:29:23 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

The "echo all attributes back to the client" rule turns this from
a CLR into an SLR (simple little rule) with a hundred and one uses.

We've used it to record RPC name, hostname, timestamps, and other
information so that any information we need to handle the rpc-reply
is contained inside the rpc-reply.  I can hand the rpc-reply to a
transformation that uses this information without having to feed
it in out of band.

Thanks,
 Phil




Andy Bierman writes:
>Hi,
>
>Didn't anybody notice that the protocol spec makes a big
>deal about a mandatory message-id (and I made a big deal
>about limiting its length), but it isn't used anywhere
>in the document in a normative manner?
>
>Nope.  We took out the only operation that depended on
>the message-id attribute a couple years ago. 
>
>The agent totally ignores this attribute except to
>check if needs to generate an error if it is missing.
>
>If that isn't the essence of a Crappy Little Rule,
>I don't know what is.  (I know, we may need the
>message-id someday, but not now.)
>
>
>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 Jul 05 15:32:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD7K-0002CR-PF
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:32:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyD7J-0003t9-FS
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:32:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyD5L-000Kep-Ia
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:30: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=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyD5K-000KeY-N2
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:30:55 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k65JUlFZ023122
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 15:30:53 -0400
Received: (qmail 27867 invoked by uid 78); 5 Jul 2006 19:30:36 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 Jul 2006 19:30:36 -0000
Message-ID: <44AC1352.8040306@andybierman.com>
Date: Wed, 05 Jul 2006 12:30:26 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: our first CLR
References: <44A5BBEA.40306@andybierman.com> <44AC019C.2050201@ericsson.com>
In-Reply-To: <44AC019C.2050201@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: 769a46790fb42fbb0b0cc700c82f7081

Balazs Lengyel wrote:
> I am fighting to be able to send late replies to operations. The most 
> likely method to do this will be a notification that refers to the 
> original operation. To be able to refer to it we need the sessionId and 
> the messageId. So Ericsson is in an immediate need of the messageId.

But you can put any attribute you want in the <rpc> header and it
will get returned to you.  There's no point in the agent blindly
rejecting a PDU just because this 'message-id' attribute is missing.


> Balazs
> 

Andy

> Andy Bierman wrote:
>> Hi,
>>
>> Didn't anybody notice that the protocol spec makes a big
>> deal about a mandatory message-id (and I made a big deal
>> about limiting its length), but it isn't used anywhere
>> in the document in a normative manner?
>>
>> Nope.  We took out the only operation that depended on
>> the message-id attribute a couple years ago.
>> The agent totally ignores this attribute except to
>> check if needs to generate an error if it is missing.
>>
>> If that isn't the essence of a Crappy Little Rule,
>> I don't know what is.  (I know, we may need the
>> message-id someday, but not now.)
>>
>>
>> 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 Jul 05 15:35:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD9t-00041I-Jy
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:35:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyD9s-00042U-9v
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:35:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyD7d-000Ksw-0c
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:33: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 [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyD7c-000Ksf-71
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:33:16 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k65JXEWC031383
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 15:33:15 -0400
Received: (qmail 26490 invoked by uid 78); 5 Jul 2006 19:33:14 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 5 Jul 2006 19:33:14 -0000
Message-ID: <44AC13F3.6080904@andybierman.com>
Date: Wed, 05 Jul 2006 12:33:07 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: our first CLR
References: <200607051929.k65JTNwn088157@idle.juniper.net>
In-Reply-To: <200607051929.k65JTNwn088157@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: 082a9cbf4d599f360ac7f815372a6a15

Phil Shafer wrote:
> The "echo all attributes back to the client" rule turns this from
> a CLR into an SLR (simple little rule) with a hundred and one uses.
> 
> We've used it to record RPC name, hostname, timestamps, and other
> information so that any information we need to handle the rpc-reply
> is contained inside the rpc-reply.  I can hand the rpc-reply to a
> transformation that uses this information without having to feed
> it in out of band.

You missed my point.
Echoing all attributes is fine -- good stuff.

Making a special check that the manager included an
attribute named 'message-id', and rejecting the PDU
if not, is the CLR.


> 
> Thanks,
>  Phil

Andy

> 
> 
> 
> 
> Andy Bierman writes:
>> Hi,
>>
>> Didn't anybody notice that the protocol spec makes a big
>> deal about a mandatory message-id (and I made a big deal
>> about limiting its length), but it isn't used anywhere
>> in the document in a normative manner?
>>
>> Nope.  We took out the only operation that depended on
>> the message-id attribute a couple years ago. 
>>
>> The agent totally ignores this attribute except to
>> check if needs to generate an error if it is missing.
>>
>> If that isn't the essence of a Crappy Little Rule,
>> I don't know what is.  (I know, we may need the
>> message-id someday, but not now.)
>>
>>
>> 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 Jul 05 15:51:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyDPK-0008Gg-0n
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:51:34 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyDPI-00075E-OY
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:51:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyDM1-000M2A-SJ
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:48: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 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 1FyDM1-000M1x-41
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:48: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 k65Jm71Z004471;
	Wed, 5 Jul 2006 12:48:07 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65Jm6511221;
	Wed, 5 Jul 2006 12:48:06 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k65Jm6wn088361;
	Wed, 5 Jul 2006 15:48:06 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200607051948.k65Jm6wn088361@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: our first CLR 
In-Reply-To: Your message of "Wed, 05 Jul 2006 12:33:07 PDT."
             <44AC13F3.6080904@andybierman.com> 
Date: Wed, 05 Jul 2006 15:48:06 -0400
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:
>You missed my point.

Nope, I'm completely agreeing with you.  Nuke the CLR and just
go with the SLR, which completely covers it.

Thanks,
 Phil

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



From owner-netconf@ops.ietf.org Wed Jul 05 15:55:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyDTG-0000jB-LZ
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:55:38 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyDTF-0007sX-Sz
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:55:38 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyDQY-000MYb-Fa
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:52: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=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1FyDQX-000MYN-MD
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:52:49 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
	by mail2.sharplabs.com (Postfix) with ESMTP id 1F97E1E14FD;
	Wed,  5 Jul 2006 12:52:49 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <NA4PXMDP>; Wed, 5 Jul 2006 12:52:49 -0700
Message-ID: <789E617C880666438EDEE30C2A3E8D10EE62@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: 'Balazs Lengyel' <balazs.lengyel@ericsson.com>, Andy Bierman
	 <ietf@andybierman.com>
Cc: Phil Shafer <phil@juniper.net>, Sharon Chisholm <schishol@nortel.com>, 
	netconf@ops.ietf.org
Subject: RE: Do we need data modeling rules like an SMI 
Date: Wed, 5 Jul 2006 12:52:39 -0700 
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: 932cba6e0228cc603da43d861a7e09d8

Hi,

+1 to all the suggestions below.

I also think making the XSD available is important.

And a data model and single namespace should be able to 
span a tree of XSD files, not just a single file.

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 Balazs Lengyel
> Sent: Wednesday, July 05, 2006 10:33 AM
> To: Andy Bierman
> Cc: Phil Shafer; Sharon Chisholm; netconf@ops.ietf.org
> Subject: Do we need data modeling rules like an SMI 
> 
> 
> So we agree that we need standard data types and textual conventions.
> 
> Some other topics I would like to see stated:
> - A method to extract the data model from the device in an 
> XSD format (Individual devices 
> might decide that they don't want to expose this even with 
> the strictest access control, 
> but generally I think this would be good.)
> - A statement that the device should advertise his data 
> models in the capability exchange
> - max-access: I feel we do need it
> - a statement that notification definitions should be part of 
> a data model like in SNMP
> 
> Then some questions:
> - how do you indicate in a data model that a bit of data is 
> read-only configuration data 
> or state data?
> - one namespace is always one data model or is it allowed to 
> define the complete data 
> model in one namespace in multiple modules?
> Balazs
> 
> Andy Bierman wrote:
> > Balazs Lengyel wrote:
> >> I think before the data models themselves we will have to tackle 
> >> something like the SMI first, that is rules for building 
> data models.
> >> e.g. standard datatypes, documentation rules, etc.
> > 
> > Not really.  We have an SMI of sorts.
> > The IETF uses XSD to describe XML data models.
> > 
> > Standard data types: We have the XSD types.
> >    I think we need some XML TCs, such as the SMIv2 data types
> >    and the RFC 4001 TCs.  But this is an IETF-wide requirement,
> >    not a NETCONF requirement.
> > 
> > Documentation rules: We have the <documentation> annotation,
> >    and we use it.  We may need some documentation rules beyond
> >    what we already know from RFC 4181, but we don't have enough
> >    experience with NETCONF to know what they are yet.
> > 
> > Etc.: This is the part that scares me.  IMO, the best way to figure
> >    out if we have a good data model is to write one and see what
> >    happens.  If we aren't competent enough to figure out how to
> >    write an XML data model for notification delivery parameters,
> >    then it would be good to know that now.
> > 
> > I am strongly opposed to the specification of rules for NETCONF data
> > models at this time.  NETCONF is content-independent and requires
> > only well-formed XML payload (+ the 'operation' attribute).
> > Also, we do not have enough experience with NETCONF data models to
> > define any significant rules (beyond XSD and some TCs).
> > 
> > Dave H. had a good suggestion, which I will paraphrase:
> > If we can't figure out how to write an XML data model module,
> > then write a MIB module first, and then figure out how to to
> > convert it to XML.  I'm hoping this WG will figure out how
> > to write an XML configuration data model though.
> > 
> > 
> > Andy
> > 
> > 
> > 
> > 
> >> Balazs
> >>
> >> Phil Shafer wrote:
> >>> Andy Bierman writes:
> >>>> There are many people (including myself) who believe that
> >>>> standard configuration data models are a critical component
> >>>> to a complete standards based solution for network configuration.
> >>>
> >>> I completely agree that standard configuration data models are
> >>> critical, but I do not agree that they are trivial.  I think this
> >>> is the next big hurdle for this working group.  The 
> question on the
> >>> floor is whether we should stop other work until we have a real
> >>> meta-model for configuration and a way of specifying standard data
> >>> models that will work in the real world.  If so, let's 
> stop talking
> >>> about notifications and get our butts in gear on modeling.
> >>>
> >>>
> >>> Thanks,
> >>>  Phil
> >>
> >>
> > 
> 
> -- 
> 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/>
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/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 Wed Jul 05 16:41:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyEBA-0002aA-6S
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 16:41:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyEB8-0003GG-LL
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 16:41:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyE7h-0000Q6-Eo
	for netconf-data@psg.com; Wed, 05 Jul 2006 20:37: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 autolearn=ham 
	version=3.1.1
Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FyE7g-0000Ps-OF
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 20:37:24 +0000
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
  by sj-iport-6.cisco.com with ESMTP; 05 Jul 2006 13:37:24 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k65KbOj3005626;
	Wed, 5 Jul 2006 13:37:24 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k65KbN9u016809;
	Wed, 5 Jul 2006 13:37:24 -0700 (PDT)
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, 5 Jul 2006 13:37:23 -0700
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: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Date: Wed, 5 Jul 2006 13:37:22 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB021B2998@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Thread-Index: AcagPIvZmz94LYHEQMuSb8W8QLk9XwAMzM3w
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Balazs Lengyel" <balazs.lengyel@ericsson.com>
Cc: "Phil Shafer" <phil@juniper.net>, "Sharon Chisholm" <schishol@nortel.com>,
        <netconf@ops.ietf.org>
X-OriginalArrivalTime: 05 Jul 2006 20:37:23.0948 (UTC) FILETIME=[D22C6AC0:01C6A072]
DKIM-Signature: a=rsa-sha1; q=dns; l=3756; t=1152131844; x=1152995844;
	c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20<htrevino@cisco.com>
	|Subject:RE=3A=20Verbs=20Again=20(was=20RE=3A=20draft-shafer-netconf-syslog-00.tx
	t);
	X=v=3Dcisco.com=3B=20h=3Dy4yI4Szl7FXIIPvlf7ZkSiFgpTU=3D; b=kQy7+UYxkS6Uru9xJmjdOgZy7ppMaGOdJBfVPq1wWn5Ij4mFtWCK2uyqfhfSPYcBhbeu7L49
	k3Jp+Tbm5k5SSDCfe1Jf4cuef5nXRF5idf/7DFVG9v+Pp11/k6gjs3Mw;
Authentication-Results: sj-dkim-2.cisco.com; header.From=htrevino@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: a7d2e37451f7f22841e3b6f40c67db0f

=20
in-line
Hector


>=20
> Balazs Lengyel wrote:
> > I think before the data models themselves we will have to tackle=20
> > something like the SMI first, that is rules for building=20
> data models.
> > e.g. standard datatypes, documentation rules, etc.
>=20
> Not really.  We have an SMI of sorts.
> The IETF uses XSD to describe XML data models.

HT: I think there needs to be the equivalent of an SMI. If this is not
in place then
there is a really good possibility that models will be different (e.g.
style, use of constructs, etc.)
Saying that NETCONF data models are written using XSD is not sufficient.


>=20
> Standard data types: We have the XSD types.
>     I think we need some XML TCs, such as the SMIv2 data types
>     and the RFC 4001 TCs.  But this is an IETF-wide requirement,
>     not a NETCONF requirement.
>=20
> Documentation rules: We have the <documentation> annotation,
>     and we use it.  We may need some documentation rules beyond
>     what we already know from RFC 4181, but we don't have enough
>     experience with NETCONF to know what they are yet.
>=20
> Etc.: This is the part that scares me.  IMO, the best way to figure
>     out if we have a good data model is to write one and see what
>     happens.  If we aren't competent enough to figure out how to
>     write an XML data model for notification delivery parameters,
>     then it would be good to know that now.
>=20
> I am strongly opposed to the specification of rules for=20
> NETCONF data models at this time.  NETCONF is=20
> content-independent and requires only well-formed XML payload=20
> (+ the 'operation' attribute).
> Also, we do not have enough experience with NETCONF data=20
> models to define any significant rules (beyond XSD and some TCs).

HT: When is a good time to define rules (SMI equivalent)?

>=20
> Dave H. had a good suggestion, which I will paraphrase:
> If we can't figure out how to write an XML data model module,=20
> then write a MIB module first, and then figure out how to to=20
> convert it to XML.  I'm hoping this WG will figure out how to=20
> write an XML configuration data model though.

HT: Writing an XML data model is not a problem but w/o the rules it is
going to be a mess. If some people decide
to write SNMP MIBs and then translate them and others write the XML data
models by hand they are going to look
completely different.=20

I guess a data model could be written for event notifications w/o having
the SMI equivalent/rules to move things forward but I don't think that's
a good idea in general.  =20

>=20
>=20
> Andy
>=20
>=20
>=20
>=20
> > Balazs
> >=20
> > Phil Shafer wrote:
> >> Andy Bierman writes:
> >>> There are many people (including myself) who believe that=20
> standard=20
> >>> configuration data models are a critical component to a complete=20
> >>> standards based solution for network configuration.
> >>
> >> I completely agree that standard configuration data models are=20
> >> critical, but I do not agree that they are trivial.  I=20
> think this is=20
> >> the next big hurdle for this working group.  The question on the=20
> >> floor is whether we should stop other work until we have a real=20
> >> meta-model for configuration and a way of specifying standard data=20
> >> models that will work in the real world.  If so, let's=20
> stop talking=20
> >> about notifications and get our butts in gear on modeling.
> >>
> >>
> >> Thanks,
> >>  Phil
> >=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 Wed Jul 05 16:48:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyEIM-0003Am-Rr
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 16:48:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyEIL-0004Sa-5f
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 16:48:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyEEj-00018C-Fs
	for netconf-data@psg.com; Wed, 05 Jul 2006 20:44: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=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyEEi-000180-Qs
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 20:44:40 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k65KidPM009817
	for <netconf@ops.ietf.org>; Wed, 5 Jul 2006 16:44:40 -0400
Received: (qmail 19624 invoked by uid 78); 5 Jul 2006 20:44:39 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 5 Jul 2006 20:44:39 -0000
Message-ID: <44AC24B0.2020802@andybierman.com>
Date: Wed, 05 Jul 2006 13:44:32 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
CC: "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Subject: Re: What about the OAM in OAM&P
References: <50B73C8966FCF840BABA099651DBE060011AB3B3@rchemx01.fnc.net.local>
In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB3B3@rchemx01.fnc.net.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: 4b800b1eab964a31702fa68f1ff0e955

Hare, Michael wrote:
> Anyone explore the DMTF (http://www.dmtf.org/home)?
> 
> It was our opinion they were making all the same mistakes the IETF made with the MIBs, i.e. we would need to restructure our data model to fit into the DMTF framework.
> 
> NETCONF is allowing us to keep our internal data model intact and while the payloads may be less standard across vendors, we will be able to implement the embedded much quicker since we can reuse much of what we had before.
> 

This is fine to get started, but in order to have
a workable standards based solution, there needs to be
a transition to standard data models somehow.

IMO NETCONF is already on the right track by recognizing
that an NE device has native NV-storage behavior,
and an "advertised capabilities" extensibility mechanism.

I agree with Phil that a real solution is not going to
be able to ignore the native interface, but instead will need
to use it effectively to "fill the gaps".

(I have been researching this topic for a few years now.
This is what I call the "near model".  Mapping the near model
to the real model semi-automatically is non-trivial.)

> - m

Andy


> 
> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Wednesday, July 05, 2006 2:37 PM
> To: Andy Bierman
> Cc: Hare, Michael; Netconf Mailing List (E-mail)
> Subject: Re: What about the OAM in OAM&P 
> 
> 
> Andy Bierman writes:
>> Our focus is standards based configuration, a subject some
>> vendors seem to want to leave as "TBD".
> 
> I'm not in the TBD crowd, I just don't think this is a simple
> problem.  You can't just define a simple schema and force all
> the world onto it.  If this worked, folks would have rewritten
> their implementations to follow MIBs.
> 
>> Unfortunately, the current process and mindset for IETF data models (MIBs)
>> is never going to work for configuration.
> 
> What we need is an understanding that it's not a simple problem and
> a plan to simplify it, to allow for incompatibilities, conversions,
> etc without losing the ability to cover the 50-80% of use cases
> that are the most beneficial.
> 
> 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 Wed Jul 05 17:35:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyF1w-00019B-70
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 17:35:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyDeX-0000cV-D9
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 16:07:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyDbs-000NVD-KR
	for netconf-data@psg.com; Wed, 05 Jul 2006 20:04: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 autolearn=ham 
	version=3.1.1
Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <Michael.Hare@us.fujitsu.com>)
	id 1FyDbs-000NUz-3C
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 20:04:32 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101])
  by fncnmp04.fnc.fujitsu.com with ESMTP; 05 Jul 2006 15:04:31 -0500
X-IronPort-AV: i="4.06,210,1149483600"; 
   d="scan'208"; a="28720815:sNHT19915724"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: What about the OAM in OAM&P 
Date: Wed, 5 Jul 2006 15:04:30 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB3B3@rchemx01.fnc.net.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What about the OAM in OAM&P 
thread-index: Acagal4Xg1ZmUKagTpuwZd1YbPWMZQAAopIA
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

Anyone explore the DMTF (http://www.dmtf.org/home)?

It was our opinion they were making all the same mistakes the IETF made =
with the MIBs, i.e. we would need to restructure our data model to fit =
into the DMTF framework.

NETCONF is allowing us to keep our internal data model intact and while =
the payloads may be less standard across vendors, we will be able to =
implement the embedded much quicker since we can reuse much of what we =
had before.

- m

-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net]
Sent: Wednesday, July 05, 2006 2:37 PM
To: Andy Bierman
Cc: Hare, Michael; Netconf Mailing List (E-mail)
Subject: Re: What about the OAM in OAM&P=20


Andy Bierman writes:
>Our focus is standards based configuration, a subject some
>vendors seem to want to leave as "TBD".

I'm not in the TBD crowd, I just don't think this is a simple
problem.  You can't just define a simple schema and force all
the world onto it.  If this worked, folks would have rewritten
their implementations to follow MIBs.

>Unfortunately, the current process and mindset for IETF data models =
(MIBs)
>is never going to work for configuration.

What we need is an understanding that it's not a simple problem and
a plan to simplify it, to allow for incompatibilities, conversions,
etc without losing the ability to cover the 50-80% of use cases
that are the most beneficial.

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 Jul 05 17:38:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyF4u-0001KP-RR
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 17:38:36 -0400
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 1FyDSX-0007qR-2G
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:54:53 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FyDDA-0006Um-Iv
	for netconf-archive@lists.ietf.org; Wed, 05 Jul 2006 15:39:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyDB4-000LBV-Ep
	for netconf-data@psg.com; Wed, 05 Jul 2006 19:36: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=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 1FyDB4-000LBH-1K
	for netconf@ops.ietf.org; Wed, 05 Jul 2006 19:36:50 +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 k65Jam1Z004327;
	Wed, 5 Jul 2006 12:36:48 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k65Jam508237;
	Wed, 5 Jul 2006 12:36:48 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k65Jahwn088248;
	Wed, 5 Jul 2006 15:36:43 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200607051936.k65Jahwn088248@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Hare, Michael" <Michael.Hare@us.fujitsu.com>,
   "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Subject: Re: What about the OAM in OAM&P 
In-Reply-To: Your message of "Mon, 03 Jul 2006 09:29:21 PDT."
             <44A945E1.5040607@andybierman.com> 
Date: Wed, 05 Jul 2006 15:36:43 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Andy Bierman writes:
>Our focus is standards based configuration, a subject some
>vendors seem to want to leave as "TBD".

I'm not in the TBD crowd, I just don't think this is a simple
problem.  You can't just define a simple schema and force all
the world onto it.  If this worked, folks would have rewritten
their implementations to follow MIBs.

>Unfortunately, the current process and mindset for IETF data models (MIBs)
>is never going to work for configuration.

What we need is an understanding that it's not a simple problem and
a plan to simplify it, to allow for incompatibilities, conversions,
etc without losing the ability to cover the 50-80% of use cases
that are the most beneficial.

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 Jul 06 03:23:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyOD8-0006pr-97
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 03:23:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyOD6-0006Nu-VX
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 03:23:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyO95-0001qh-87
	for netconf-data@psg.com; Thu, 06 Jul 2006 07:19: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [213.180.94.158] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FyO94-0001qT-L4
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 07:19:30 +0000
Received: from localhost (c83-176-211-235.cust.tele2.se [83.176.211.235])
	by mail.tail-f.com (Postfix) with ESMTP id A56871B8011;
	Thu,  6 Jul 2006 09:19:29 +0200 (CEST)
Date: Thu, 06 Jul 2006 09:19:25 +0200 (CEST)
Message-Id: <20060706.091925.125789117.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: balazs.lengyel@ericsson.com, phil@juniper.net,
	schishol@nortel.com, netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44ABD706.3040909@andybierman.com>
References: <44ABC7C3.2000809@andybierman.com>
	<44ABCDB3.5060902@ericsson.com>
	<44ABD706.3040909@andybierman.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.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

Andy Bierman <ietf@andybierman.com> wrote:
> Balazs Lengyel wrote:
> > Some other topics I would like to see stated:
> > - A method to extract the data model from the device in an XSD format 
> > (Individual devices might decide that they don't want to expose this 
> > even with the strictest access control, but generally I think this would 
> > be good.)
> 
> 
> IMO this is way out of bounds. It forces
> everybody to use XSD for all their data models,
> and the agent memory/storage requirements would force
> this to be optional anyway.

Of course this could be an optional capability.  If you don't have a
XSD describing the data, don't use this capability.  On the other
hand, *if* the box has the XSD, it would be nice with a standard way
of getting these XSDs, either inline or through an URL.  (would it be
a misuse of the <get> operation to retreive the inline XSDs using
<get>?)

I don't agree with the statement that "it forces everybody to use XSD
for all their data models".  We use a much simpler language for the
data modelling part, where we also specify e.g constraints that cannot
be expressed in XSD.  From these data model we generate XSDs which
describe the instance documents that are sent on the wire.


/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 Jul 06 03:26:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyO7h-000587-9x
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 03:18:05 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyNw1-0004m6-EK
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 03:06:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyNqh-000084-V2
	for netconf-data@psg.com; Thu, 06 Jul 2006 07:00: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [213.180.94.158] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FyNqh-00007p-CD
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 07:00:31 +0000
Received: from localhost (c83-176-211-235.cust.tele2.se [83.176.211.235])
	by mail.tail-f.com (Postfix) with ESMTP id CA2301B8011;
	Thu,  6 Jul 2006 09:00:19 +0200 (CEST)
Date: Thu, 06 Jul 2006 09:00:15 +0200 (CEST)
Message-Id: <20060706.090015.12680422.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: ietf@andybierman.com, phil@juniper.net, schishol@nortel.com,
	netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI 
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44ABCDB3.5060902@ericsson.com>
References: <44ABC090.8090503@ericsson.com>
	<44ABC7C3.2000809@andybierman.com>
	<44ABCDB3.5060902@ericsson.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.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> So we agree that we need standard data types and textual conventions.
> 
> Some other topics I would like to see stated:

> - A method to extract the data model from the device in an XSD
>   format (Individual devices might decide that they don't want to
>   expose this even with the strictest access control, but generally I
>   think this would be good.)

This can of course be done as a vendor-specific rpc.

> - A statement that the device should advertise his data models in
>   the capability exchange

There's already this sentence from the draft, section 5.2:

   The device uses capabilities to announce the set of data models
   which the device implements.


/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 Jul 06 09:56:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyULh-0007Fp-1i
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 09:56:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyULf-0005o8-Mz
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 09:56:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyUG4-000CUG-PP
	for netconf-data@psg.com; Thu, 06 Jul 2006 13:51: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.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyUG0-000CTp-E0
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 13:51:08 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k66Dp1MX026698
	for <netconf@ops.ietf.org>; Thu, 6 Jul 2006 09:51:03 -0400
Received: (qmail 28826 invoked by uid 78); 6 Jul 2006 13:51:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 6 Jul 2006 13:51:01 -0000
Message-ID: <44AD153E.7040602@andybierman.com>
Date: Thu, 06 Jul 2006 06:50:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: balazs.lengyel@ericsson.com, phil@juniper.net, schishol@nortel.com,
        netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI
References: <44ABC7C3.2000809@andybierman.com>	<44ABCDB3.5060902@ericsson.com>	<44ABD706.3040909@andybierman.com> <20060706.091925.125789117.mbj@tail-f.com>
In-Reply-To: <20060706.091925.125789117.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: 50a516d93fd399dc60588708fd9a3002

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Balazs Lengyel wrote:
>>> Some other topics I would like to see stated:
>>> - A method to extract the data model from the device in an XSD format 
>>> (Individual devices might decide that they don't want to expose this 
>>> even with the strictest access control, but generally I think this would 
>>> be good.)
>>
>> IMO this is way out of bounds. It forces
>> everybody to use XSD for all their data models,
>> and the agent memory/storage requirements would force
>> this to be optional anyway.
> 
> Of course this could be an optional capability.  If you don't have a
> XSD describing the data, don't use this capability.  On the other
> hand, *if* the box has the XSD, it would be nice with a standard way
> of getting these XSDs, either inline or through an URL.  (would it be
> a misuse of the <get> operation to retreive the inline XSDs using
> <get>?)
> 
> I don't agree with the statement that "it forces everybody to use XSD
> for all their data models".  We use a much simpler language for the
> data modelling part, where we also specify e.g constraints that cannot
> be expressed in XSD.  From these data model we generate XSDs which
> describe the instance documents that are sent on the wire.

Traditionally, SNMP agents do not contain all the ASCII MIB modules
they support.  Nor do CLI agents contain all the ASCII or HTML documentation
that they support.

A URL of the general schema (not XSD) is DM language independent.
It can point to a RelaxNG, XSD, or even custom DM file.
The bytes on the wire are XML -- that is the only thing
that is standardized here.


> 
> 
> /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 Jul 06 11:09:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyVTQ-00012d-Jv
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:09:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyVTO-0000PA-AO
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:09:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyVL4-000J9p-GX
	for netconf-data@psg.com; Thu, 06 Jul 2006 15:00: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=AWL,BAYES_00 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 1FyVL3-000J9a-Tx
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 15:00:22 +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 k66F0J515347
	for <netconf@ops.ietf.org>; Thu, 6 Jul 2006 11:00:19 -0400 (EDT)
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: Do we need data modeling rules like an SMI
Date: Thu, 6 Jul 2006 11:00:18 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4099B6F1A@zcarhxm2.corp.nortel.com>
In-Reply-To: <44ABCDB3.5060902@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Do we need data modeling rules like an SMI
thread-index: AcagQHLzAYxh97a1TjCP7021m3ij6gAy5teQ
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: 52e1467c2184c31006318542db5614d5


<Balazs>
Then some questions:
- how do you indicate in a data model that a bit of data is read-only
configuration data=20
or state data?
- one namespace is always one data model or is it allowed to define the
complete data=20
model in one namespace in multiple modules?
Balazs

</Balazs>

For the first, there is a proposed solution in=20
=09
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt

Another approach that is interesting is to instead of specifying
minAccess/maxAccess to actually call data
	- statistics
	- configuration
	- administrative state
	- operational state
	- etc.

and hard code minAccess and maxAccess against each of those. This isn't
what we've been doing in product though. It does have a certain appeal
though. In particular, it works well with the get and get-config
commands.

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 Jul 06 11:22:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyVg2-0002sD-LL
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:22:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyVg0-000116-1O
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:22:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyVWG-000KAR-Vj
	for netconf-data@psg.com; Thu, 06 Jul 2006 15:11: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 [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FyVWG-000KAD-Ed
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 15:11:56 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 992958E0009;
	Thu,  6 Jul 2006 10:09:13 +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, 6 Jul 2006 10:09:11 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Jul 2006 10:09:10 +0200
Message-ID: <44ACC526.2090109@ericsson.com>
Date: Thu, 06 Jul 2006 10:09:10 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC:  netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI
References: <789E617C880666438EDEE30C2A3E8D10EE62@mailsrvnt05.enet.sharplabs.com>
In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EE62@mailsrvnt05.enet.sharplabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Jul 2006 08:09:10.0733 (UTC) FILETIME=[76252FD0:01C6A0D3]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

McDonald, Ira wrote:
  > And a data model and single namespace should be able to
> span a tree of XSD files, not just a single file.

Could you explain this a bit more.

Yes in design and during model specification it is really important to be able to use 
multiple files. But is it needed when the device presents it's data model on the wire ?
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 Jul 06 11:35:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyVtQ-0006HR-QW
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:35:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyVtP-0001Om-FY
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:35:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyVq2-000LsV-7j
	for netconf-data@psg.com; Thu, 06 Jul 2006 15:32: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=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyVq1-000LsK-IZ
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 15:32:21 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k66FWC0P008808
	for <netconf@ops.ietf.org>; Thu, 6 Jul 2006 11:32:12 -0400
Received: (qmail 12224 invoked by uid 78); 6 Jul 2006 15:31:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 6 Jul 2006 15:31:46 -0000
Message-ID: <44AD2CDA.8070308@andybierman.com>
Date: Thu, 06 Jul 2006 08:31:38 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "McDonald, Ira" <imcdonald@sharplabs.com>, netconf@ops.ietf.org
Subject: Re: Do we need data modeling rules like an SMI
References: <789E617C880666438EDEE30C2A3E8D10EE62@mailsrvnt05.enet.sharplabs.com> <44ACC526.2090109@ericsson.com>
In-Reply-To: <44ACC526.2090109@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: 8b30eb7682a596edff707698f4a80f7d

Balazs Lengyel wrote:
> McDonald, Ira wrote:
>  > And a data model and single namespace should be able to
>> span a tree of XSD files, not just a single file.
> 
> Could you explain this a bit more.

I was going to comment on this, but Joel did first.
You cannot assume a 1:1 mapping between modules and
namespaces.  Just like the SMI, the module is just
a container of definitions that has absolutely no
hard-wired relationship to the nature or location of
the conceptual data model instances described in each module.


> 
> Yes in design and during model specification it is really important to 
> be able to use multiple files. But is it needed when the device presents 
> it's data model on the wire ?

No.
It is not needed at all, but NMS developers want it anyway.
The XML on the wire is identified with namespaces.

The solution is to simply add an optional 'schemaLocation'
attribute to the <capability> element, so module capabilities
(which identify a conformance level to a particular module)
can also indicate the URL for the actual module schema.



> 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/>



From owner-netconf@ops.ietf.org Thu Jul 06 11:47:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyW4P-000772-4a
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:47:13 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyW4N-0001nv-PM
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 11:47:13 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyW12-000MzS-3w
	for netconf-data@psg.com; Thu, 06 Jul 2006 15:43:44 +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 [64.233.162.192] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1FyW11-000MzG-Hs
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 15:43:43 +0000
Received: by nz-out-0102.google.com with SMTP id 34so1108734nzf
        for <netconf@ops.ietf.org>; Thu, 06 Jul 2006 08:43:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=SGT8dXfqeEegkrrtmZnPBAFQHxeZo3mn+v/DdCpI1bZOewg472JC2fC452LO0BFsNDqa9UVnGYrlc4MFDI2MfgOtNmsNAxwFpY/daG+FOdOiaWreHsP02LuSTU81v94FMgAnmoGYfOiVMjqdC0R/4zYoouBqjGUdbcMY+d2FbUg=
Received: by 10.36.55.2 with SMTP id d2mr1061152nza;
        Thu, 06 Jul 2006 08:43:42 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Thu, 6 Jul 2006 08:43:42 -0700 (PDT)
Message-ID: <dc67eef70607060843k1c44549ehc825aebcff3b0abe@mail.gmail.com>
Date: Thu, 6 Jul 2006 17:43:42 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: netconf@ops.ietf.org
Subject: sylsog in NETCONF notifications
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

WG,

I suggest that the mapping of syslog to netconf notifications as well
as the "syslogTunnel" event type be left out of the netconf
notifications I-D. The reason is that I think the syslog community
should provide a data model for syslog notifications as well as a
mapping. The same should probably be done for SMTP traps.

Having syslog mappings in a basic netconf document forces the netconf
document to be changed/obsoleted whenever there is change on the
syslog side. I think this dependency should be avoided.

There is some growing interest in the syslog community to define event
data models. This effort could play nicely together with netconf.

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 Thu Jul 06 12:02:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyWJ2-0005RL-Vz
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:02:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyWJ0-0002Gc-Kb
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:02:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyWFh-000OVD-8s
	for netconf-data@psg.com; Thu, 06 Jul 2006 15:58: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.51] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyWFg-000OUz-CV
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 15:58:52 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k66FwpJP032197
	for <netconf@ops.ietf.org>; Thu, 6 Jul 2006 11:58:51 -0400
Received: (qmail 32141 invoked by uid 78); 6 Jul 2006 15:58:51 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 6 Jul 2006 15:58:51 -0000
Message-ID: <44AD3331.7050808@andybierman.com>
Date: Thu, 06 Jul 2006 08:58:41 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Rainer Gerhards <rgerhards@gmail.com>
CC: netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <dc67eef70607060843k1c44549ehc825aebcff3b0abe@mail.gmail.com>
In-Reply-To: <dc67eef70607060843k1c44549ehc825aebcff3b0abe@mail.gmail.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: a7d6aff76b15f3f56fcb94490e1052e4

Rainer Gerhards wrote:
> WG,
> 
> I suggest that the mapping of syslog to netconf notifications as well
> as the "syslogTunnel" event type be left out of the netconf
> notifications I-D. The reason is that I think the syslog community
> should provide a data model for syslog notifications as well as a
> mapping. The same should probably be done for SMTP traps.

I disagree.
I think it is fine for the NETCONF WG to reference a specific
version of syslog as the content format.  If the SYSLOG WG
invented a new version, then the NETCONF PDU would just reference it.
I don't see a problem if the NETCONF WG creates configuration
mechanisms for NETCONF (such as notification filtering) and
uses well-known fields in a specific version of syslog.


> 
> Having syslog mappings in a basic netconf document forces the netconf
> document to be changed/obsoleted whenever there is change on the
> syslog side. I think this dependency should be avoided.
> 
> There is some growing interest in the syslog community to define event
> data models. This effort could play nicely together with netconf.

Does this mean you think it is a good idea for the NETCONF WG
to create a brand-new netconf-only notification system?

Or does it mean you think the SYSLOG WG should do this work
instead of the NETCONF WG?


> 
> Rainer

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 Jul 06 12:33:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyWnZ-0003Jz-5s
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:33:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyWnX-0003l1-OV
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:33:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyWkC-0001Az-4h
	for netconf-data@psg.com; Thu, 06 Jul 2006 16:30: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [64.233.162.201] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1FyWkB-0001Ao-DQ
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 16:30:23 +0000
Received: by nz-out-0102.google.com with SMTP id s18so532725nze
        for <netconf@ops.ietf.org>; Thu, 06 Jul 2006 09:30:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=qjs1t2iqnOfBI6LxPrxYHHywgZhS3sYvCGSbyxXAA+8zbFZdu5BVYjKsMuK8JzQNP20hSCo9IjLrVaQRxTN+g8qH0mLP13HVrbjeL7D8Oe14FolhVothhKiDdOQLGBmffSNGqWZhfprDecZh39eWBohCRofK0+KQEyxpOI/P54s=
Received: by 10.36.33.6 with SMTP id g6mr1120752nzg;
        Thu, 06 Jul 2006 09:30:21 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Thu, 6 Jul 2006 09:30:21 -0700 (PDT)
Message-ID: <dc67eef70607060930j929a7adid3f8f88e2d8526dd@mail.gmail.com>
Date: Thu, 6 Jul 2006 18:30:21 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: sylsog in NETCONF notifications
Cc: netconf@ops.ietf.org
In-Reply-To: <44AD3331.7050808@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <dc67eef70607060843k1c44549ehc825aebcff3b0abe@mail.gmail.com>
	 <44AD3331.7050808@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

<inline>

On 7/6/06, Andy Bierman <ietf@andybierman.com> wrote:
> I disagree.
> I think it is fine for the NETCONF WG to reference a specific
> version of syslog as the content format.  If the SYSLOG WG
> invented a new version, then the NETCONF PDU would just reference it.
> I don't see a problem if the NETCONF WG creates configuration
> mechanisms for NETCONF (such as notification filtering) and
> uses well-known fields in a specific version of syslog.

I do not see any problem if the NETCONF WG creates a configuration
mechanism for NETCONF. But appendix B looks like the NETCONF WG
creates a configuration mechanism (or better: notification mechanism)
for syslog. If that is just one way of doing things, why not also
specifying how SNMP traps and informs should be carried inside a
NETCONF notification?

If you talk about filtering and also talk about syslog data, NETCONF
IMHO actually tries to define a configuration mechanism for SYSLOG.
The draft is not taking SYSLOG as *the* content format and just
extending it with some syslog fields. The draft is defining a NETCONF
notification format (which is perfectly fine and good to see) and then
is mapping how SYSLOG should be mapped into it. The later IMHO should
be done as a separate effort via a SYSLOG data model.

> > Having syslog mappings in a basic netconf document forces the netconf
> > document to be changed/obsoleted whenever there is change on the
> > syslog side. I think this dependency should be avoided.
> >
> > There is some growing interest in the syslog community to define event
> > data models. This effort could play nicely together with netconf.
>
> Does this mean you think it is a good idea for the NETCONF WG
> to create a brand-new netconf-only notification system?

I think it is eventually a good idea for the NETCONF WG to create a
brand-new, EXTENSIBLE notification system that could also transport
events traditionally being transported via SYSLOG, SNMP or
vendor-specific event notification protocols. If I understood NETCONF
correctly, it is a common base that it should be extensible.
Extensions can be vendor-specific or via standard capabilities. Lots
of discussion on this list are focussed about data models for
configuration. If I follow that spirit, NETCONF notifications should
provide a framework for notification delivery, but not necessarily
(and exclusively) all data models that could be transported via it.

> Or does it mean you think the SYSLOG WG should do this work
> instead of the NETCONF WG?

I think the syslog community should standardize a SYSLOG data model.
As much as it probably could standardize a basic SYSLOG configuration
data model (including syslog-specific filters and event actions). I do
not think that the current SYSLOG WG (chartered in the SEC area) is
the right one to do this. I think a new SYSLOG WG should be chartered
in the OPS area to standardize syslog payload and thus also provide a
data model. Ideally, it would lean on the good work NETCONF has done.
Such a data model could be advertised as a capability.

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 Thu Jul 06 12:49:14 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyX2Q-00005R-BL
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:49:14 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyX2O-0004mR-US
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 12:49:14 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyWwq-0002Gz-Dg
	for netconf-data@psg.com; Thu, 06 Jul 2006 16:43: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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FyWwp-0002Go-Ra
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 16:43:27 +0000
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
  by sj-iport-6.cisco.com with ESMTP; 06 Jul 2006 09:43:27 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k66GhRjl029496;
	Thu, 6 Jul 2006 09:43:27 -0700
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 k66GhKCq014328;
	Thu, 6 Jul 2006 09:43:27 -0700 (PDT)
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, 6 Jul 2006 09:43:24 -0700
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: sylsog in NETCONF notifications
Date: Thu, 6 Jul 2006 09:43:23 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB021B2C4B@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: sylsog in NETCONF notifications
Thread-Index: AcahEwlBti3EsWUNTxGN0tnEIBlM/QABh61Q
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Rainer Gerhards" <rgerhards@gmail.com>, <netconf@ops.ietf.org>
X-OriginalArrivalTime: 06 Jul 2006 16:43:24.0422 (UTC) FILETIME=[4C608260:01C6A11B]
DKIM-Signature: a=rsa-sha1; q=dns; l=1606; t=1152204207; x=1153068207;
	c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20<htrevino@cisco.com>
	|Subject:RE=3A=20sylsog=20in=20NETCONF=20notifications;
	X=v=3Dcisco.com=3B=20h=3Di1g4ON2xyWi8EvZT8FbxLj99TTk=3D; b=dqxvC+pg2YFwSXgzy6VYQKG4P84/8YbfHr7xjn2gmiWE0oeRa84IZqXMVt+/HF5+vZtSjBpL
	yUZfBZMxLpKMcwvtsBpOvgbwCk9HZ8KuqsiJ4u2aq33EGlHDo8JoISqm;
Authentication-Results: sj-dkim-4.cisco.com; header.From=htrevino@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: 50a516d93fd399dc60588708fd9a3002


=20

> Rainer Gerhards writes:=20
> WG,
>=20
> I suggest that the mapping of syslog to netconf notifications=20
> as well as the "syslogTunnel" event type be left out of the=20
> netconf notifications I-D. The reason is that I think the=20
> syslog community should provide a data model for syslog=20
> notifications as well as a mapping. The same should probably=20
> be done for SMTP traps.

HT: I tend to disagree with this. First, the "syslogTunnel" is just a
way to=20
    indicate that the payload of the NETCONF notification is a syslog
PDU. Why would this be the
    responsibility of the syslog WG/community. Second, the mapping was
an attempt to "re-use" existing
    syslog field definitions. =20
>=20
> Having syslog mappings in a basic netconf document forces the=20
> netconf document to be changed/obsoleted whenever there is=20
> change on the syslog side. I think this dependency should be avoided.

HT: I don't think this is necessarily true given the purpose of the
"mappings" but we'll look at it.=20

>=20
> There is some growing interest in the syslog community to=20
> define event data models. This effort could play nicely=20
> together with netconf.

HT: IMO this work is necessary but should be done independently of
syslog. Syslog can be a delivery mechanism but there is no reason for
syslog to be the only one.=20
>=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 Thu Jul 06 13:10:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyXMa-0002Yc-Qe
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 13:10:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyXMa-0005hp-Ae
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 13:10:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyXIK-0004WK-Ln
	for netconf-data@psg.com; Thu, 06 Jul 2006 17: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=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FyXIJ-0004W6-TX
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 17:05:39 +0000
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
  by sj-iport-6.cisco.com with ESMTP; 06 Jul 2006 10:05:39 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k66H5dxS000710;
	Thu, 6 Jul 2006 10:05:39 -0700
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 k66H5dCU007657;
	Thu, 6 Jul 2006 10:05:39 -0700 (PDT)
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, 6 Jul 2006 10:05:38 -0700
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: sylsog in NETCONF notifications
Date: Thu, 6 Jul 2006 10:05:38 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: sylsog in NETCONF notifications
Thread-Index: AcahGaAA1goOWcvDRO+veEPfaVHSMAAAdefA
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Rainer Gerhards" <rgerhards@gmail.com>,
        "Andy Bierman" <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 06 Jul 2006 17:05:38.0937 (UTC) FILETIME=[67CF5690:01C6A11E]
DKIM-Signature: a=rsa-sha1; q=dns; l=4688; t=1152205539; x=1153069539;
	c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20<htrevino@cisco.com>
	|Subject:RE=3A=20sylsog=20in=20NETCONF=20notifications;
	X=v=3Dcisco.com=3B=20h=3Di1g4ON2xyWi8EvZT8FbxLj99TTk=3D; b=Yf1xCM5RXBhS9YJCuiFFItJVdv0XU6cRphBlKMUAC5dxJOewfORL1B4zmxKR1f2CSKlvOZ/o
	GUcxPJzyz+ZCBLHEyDfUADpcp2AJ/71Edw/9aRSCXK7nsdRJdQvpv23w;
Authentication-Results: sj-dkim-4.cisco.com; header.From=htrevino@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: 36c793b20164cfe75332aa66ddb21196

=20
in-line
Hector


> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Rainer Gerhards
> Sent: Thursday, July 06, 2006 10:30 AM
> To: Andy Bierman
> Cc: netconf@ops.ietf.org
> Subject: Re: sylsog in NETCONF notifications
>=20
> <inline>
>=20
> On 7/6/06, Andy Bierman <ietf@andybierman.com> wrote:
> > I disagree.
> > I think it is fine for the NETCONF WG to reference a=20
> specific version=20
> > of syslog as the content format.  If the SYSLOG WG invented a new=20
> > version, then the NETCONF PDU would just reference it.
> > I don't see a problem if the NETCONF WG creates configuration=20
> > mechanisms for NETCONF (such as notification filtering) and uses=20
> > well-known fields in a specific version of syslog.
>=20
> I do not see any problem if the NETCONF WG creates a=20
> configuration mechanism for NETCONF. But appendix B looks=20
> like the NETCONF WG creates a configuration mechanism (or=20
> better: notification mechanism) for syslog. If that is just=20
> one way of doing things, why not also specifying how SNMP=20
> traps and informs should be carried inside a NETCONF notification?

HT: Because nobody (that I know of) is interested/needs to carry
    SNMP notifications inside NETCONF. Whether or not the Appendix B
proposal stays
    in is up for discussion next week.=20

>=20
> If you talk about filtering and also talk about syslog data,=20
> NETCONF IMHO actually tries to define a configuration=20
> mechanism for SYSLOG.
> The draft is not taking SYSLOG as *the* content format and=20
> just extending it with some syslog fields. The draft is=20
> defining a NETCONF notification format (which is perfectly=20
> fine and good to see) and then is mapping how SYSLOG should=20
> be mapped into it. The later IMHO should be done as a=20
> separate effort via a SYSLOG data model.

HT: The title of the section is "Leveraging Syslog Field Definitions"
and as the title I think suggests the purpose is to re-use existing
syslog definitions where it makes sense.=20

>=20
> > > Having syslog mappings in a basic netconf document forces the=20
> > > netconf document to be changed/obsoleted whenever there=20
> is change on=20
> > > the syslog side. I think this dependency should be avoided.
> > >
> > > There is some growing interest in the syslog community to define=20
> > > event data models. This effort could play nicely together=20
> with netconf.
> >
> > Does this mean you think it is a good idea for the NETCONF WG to=20
> > create a brand-new netconf-only notification system?
>=20
> I think it is eventually a good idea for the NETCONF WG to=20
> create a brand-new, EXTENSIBLE notification system that could=20
> also transport events traditionally being transported via=20
> SYSLOG, SNMP or vendor-specific event notification protocols.=20
> If I understood NETCONF correctly, it is a common base that=20
> it should be extensible.
> Extensions can be vendor-specific or via standard=20
> capabilities. Lots of discussion on this list are focussed=20
> about data models for configuration. If I follow that spirit,=20
> NETCONF notifications should provide a framework for=20
> notification delivery, but not necessarily (and exclusively)=20
> all data models that could be transported via it.

HT: That's the idea. Right now the doc only covers syslog & as I said in
a previous e-mail
    SNMP is not something that has come up.=20

>=20
> > Or does it mean you think the SYSLOG WG should do this work=20
> instead of=20
> > the NETCONF WG?
>=20
> I think the syslog community should standardize a SYSLOG data model.
> As much as it probably could standardize a basic SYSLOG=20
> configuration data model (including syslog-specific filters=20
> and event actions). I do not think that the current SYSLOG WG=20
> (chartered in the SEC area) is the right one to do this. I=20
> think a new SYSLOG WG should be chartered in the OPS area to=20
> standardize syslog payload and thus also provide a data=20
> model. Ideally, it would lean on the good work NETCONF has done.
> Such a data model could be advertised as a capability.

HT: I think this is good. Not sure what SYSLOG data model entails but
I'll assume it could include event types/contents. If so, could this be
done (i.e. event types, contents) defined in a protocol independent
manner.=20

>=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 Thu Jul 06 15:52:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyZtI-0000Xc-7s
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 15:52:00 -0400
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 1FyZtI-0002aw-6R
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 15:52:00 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FyZrB-0003E6-UO
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 15:49:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyZnI-000GvF-1x
	for netconf-data@psg.com; Thu, 06 Jul 2006 19:45: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [213.180.94.158] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FyZnH-000Gsj-Ez
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 19:45:47 +0000
Received: from localhost (c83-176-211-235.cust.tele2.se [83.176.211.235])
	by mail.tail-f.com (Postfix) with ESMTP id A186F1B8011;
	Thu,  6 Jul 2006 21:45:10 +0200 (CEST)
Date: Thu, 06 Jul 2006 21:45:06 +0200 (CEST)
Message-Id: <20060706.214506.89639224.mbj@tail-f.com>
To: htrevino@cisco.com
Cc: rgerhards@gmail.com, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB021B2C4B@xmb-sjc-223.amer.cisco.com>
References: <6E21698722408147BEA594E073E2B0AB021B2C4B@xmb-sjc-223.amer.cisco.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: -2.6 (--)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

"Hector Trevino (htrevino)" <htrevino@cisco.com> wrote:
> 
>  
> 
> > Rainer Gerhards writes: 
> > WG,
> > 
> > I suggest that the mapping of syslog to netconf notifications 
> > as well as the "syslogTunnel" event type be left out of the 
> > netconf notifications I-D. The reason is that I think the 
> > syslog community should provide a data model for syslog 
> > notifications as well as a mapping. The same should probably 
> > be done for SMTP traps.
> 
> HT: I tend to disagree with this. First, the "syslogTunnel" is just
> a way to indicate that the payload of the NETCONF notification is a
> syslog PDU.

The current draft specifies in B.1 a mapping from the syslog fields to
something called NETCONF event fields.  But these event fields are not
defined anywhere.  Is this part still correct, or are you saying that
the syslog message is tunnelled "as-is"?


/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 Jul 06 16:41:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyafH-0003Rr-1P
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:35 -0400
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 1FyafG-0000Fx-Ve
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:35 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FyafE-0004MH-KS
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyaZo-000Lyb-0V
	for netconf-data@psg.com; Thu, 06 Jul 2006 20:35: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 autolearn=ham 
	version=3.1.1
Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FyaZk-000Ly6-6E
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 20:35:55 +0000
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
  by sj-iport-6.cisco.com with ESMTP; 06 Jul 2006 13:35:51 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k66KZpE0001352;
	Thu, 6 Jul 2006 13:35:51 -0700
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 k66KZpCW028372;
	Thu, 6 Jul 2006 13:35:51 -0700 (PDT)
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, 6 Jul 2006 13:35:51 -0700
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: sylsog in NETCONF notifications
Date: Thu, 6 Jul 2006 13:35:50 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB021B2D8D@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: sylsog in NETCONF notifications
Thread-Index: AcahNLyCaTediTUMThykiG7DcWl1pgABTerA
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Martin Bjorklund" <mbj@tail-f.com>
Cc: <rgerhards@gmail.com>, <netconf@ops.ietf.org>
X-OriginalArrivalTime: 06 Jul 2006 20:35:51.0425 (UTC) FILETIME=[C5704710:01C6A13B]
DKIM-Signature: a=rsa-sha1; q=dns; l=649; t=1152218151; x=1153082151;
	c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20<htrevino@cisco.com>
	|Subject:RE=3A=20sylsog=20in=20NETCONF=20notifications;
	X=v=3Dcisco.com=3B=20h=3Di1g4ON2xyWi8EvZT8FbxLj99TTk=3D; b=QJG6+vUrzl/WJ6NjX7AULqXbGp9QPp0dBk9oDBxc4VnL4I10sG5AJ/Ml8vX2G1/cA2AzQZB7
	mWDieZ9GLItmGCCq3vNJZP1LK0OS7jYkpI4bxxHdr9CXgmK4nLHXM0Ul;
Authentication-Results: sj-dkim-2.cisco.com; header.From=htrevino@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

=20

>=20
> The current draft specifies in B.1 a mapping from the syslog=20
> fields to something called NETCONF event fields.  But these=20
> event fields are not defined anywhere.  Is this part still=20
> correct, or are you saying that the syslog message is=20
> tunnelled "as-is"?
>=20
>=20
> /martin
>=20

The field descriptions got removed in a previous update. This needs to
be updated. The idea was that if we were to define the NETCONF
notification contents then we'd use the same definitions as syslog for
the fields listed in that table. =20
To your second question, yes the entire syslog message is tunneled as
is.=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 Jul 06 16:41:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyafS-0003Su-DM
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:46 -0400
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 1FyafS-0000Gf-AN
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:46 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FyafP-0004MT-PH
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 16:41:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fyacs-000MEC-Vt
	for netconf-data@psg.com; Thu, 06 Jul 2006 20:39: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [64.233.162.205] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1Fyacs-000MDz-5R
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 20:39:06 +0000
Received: by nz-out-0102.google.com with SMTP id l1so1603131nzf
        for <netconf@ops.ietf.org>; Thu, 06 Jul 2006 13:39:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aQX0CjoDb6Qg5ZHTyu1jWE2yLsLjgf+/f9FN5Bv7Eqt6TPmWq7ch8gwkvTMvfuTZKbinXscBdYwCYNzjsyIU5uYv0iE1kJdQ5TuZ9oklBm5CKYtUeONgCYfyIvUih2IVWcm1gylDtxxFD0+dWVNKZi4QqJB1X8Ygd55IesmR+wQ=
Received: by 10.36.47.6 with SMTP id u6mr647829nzu;
        Thu, 06 Jul 2006 13:39:05 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Thu, 6 Jul 2006 13:39:05 -0700 (PDT)
Message-ID: <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
Date: Thu, 6 Jul 2006 22:39:05 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
Subject: Re: sylsog in NETCONF notifications
Cc: "Andy Bierman" <ietf@andybierman.com>, netconf@ops.ietf.org
In-Reply-To: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

<inline>
Rainer

> HT: Because nobody (that I know of) is interested/needs to carry
>     SNMP notifications inside NETCONF. Whether or not the Appendix B
> proposal stays
>     in is up for discussion next week.

That's why I raised the point today.

> > If you talk about filtering and also talk about syslog data,
> > NETCONF IMHO actually tries to define a configuration
> > mechanism for SYSLOG.
> > The draft is not taking SYSLOG as *the* content format and
> > just extending it with some syslog fields. The draft is
> > defining a NETCONF notification format (which is perfectly
> > fine and good to see) and then is mapping how SYSLOG should
> > be mapped into it. The later IMHO should be done as a
> > separate effort via a SYSLOG data model.
>
> HT: The title of the section is "Leveraging Syslog Field Definitions"
> and as the title I think suggests the purpose is to re-use existing
> syslog definitions where it makes sense.


> >
> > > > Having syslog mappings in a basic netconf document forces the
> > > > netconf document to be changed/obsoleted whenever there
> > is change on
> > > > the syslog side. I think this dependency should be avoided.
> > > >
> > > > There is some growing interest in the syslog community to define
> > > > event data models. This effort could play nicely together
> > with netconf.
> > >
> > > Does this mean you think it is a good idea for the NETCONF WG to
> > > create a brand-new netconf-only notification system?
> >
> > I think it is eventually a good idea for the NETCONF WG to
> > create a brand-new, EXTENSIBLE notification system that could
> > also transport events traditionally being transported via
> > SYSLOG, SNMP or vendor-specific event notification protocols.
> > If I understood NETCONF correctly, it is a common base that
> > it should be extensible.
> > Extensions can be vendor-specific or via standard
> > capabilities. Lots of discussion on this list are focussed
> > about data models for configuration. If I follow that spirit,
> > NETCONF notifications should provide a framework for
> > notification delivery, but not necessarily (and exclusively)
> > all data models that could be transported via it.
>
> HT: That's the idea. Right now the doc only covers syslog & as I said in
> a previous e-mail
>     SNMP is not something that has come up.

That's my problem: "right now the doc only covers syslog". If so, then
the doc is not talking about NETCONF but about SYSLOG ;) But if it is
about SYSLOG, then it is either beyond the charter of the NETCONF WG
or the NETCONF WG must endure that SYSLOG specifics be discussed here
(Andy, I think, rejected the later for good reasons).

I fear that if NETCONF notifications goes into too much detail on
SYSLOG, it will eventually distract interest in a solution for SYSLOG.
Think about it that way: any NETCONF agent that puts SYSLOG fields
into some NETCONF fields is not a pure NETCONF agent. It is actually a
SYSLOG/NETCONF gateway, as is shown in the netconf-syslog draft. The
SYSLOG side of that beast is actually ... a SYSLOG receiver.

Don't misunderstand me: I find it correct that NETCONF does
notifications, if NETCONF needs such. I also think it is valuable to
have an extensible notification mechanism. I just think that NETCONF
should standardize NETCONF and not whatever else seems handy. And,
yes, I agree SYSLOG messages are interesting to NETCONF agents. SNMP
events, IMHO, should also be interesting if you really intend to make
a single manager able to manage everything. In concept, I do not see
any big difference between the need to see SYSLOG vs. SNMP events if
you go after as many event data as possible. In practice, of course,
SNMP is mature and well-standardized while SYSLOG is a quick ad-hoc
solution. That doesn't mean that we should continue to look at it in a
quick ad-hoc way.

> > > Or does it mean you think the SYSLOG WG should do this work
> > instead of
> > > the NETCONF WG?
> >
> > I think the syslog community should standardize a SYSLOG data model.
> > As much as it probably could standardize a basic SYSLOG
> > configuration data model (including syslog-specific filters
> > and event actions). I do not think that the current SYSLOG WG
> > (chartered in the SEC area) is the right one to do this. I
> > think a new SYSLOG WG should be chartered in the OPS area to
> > standardize syslog payload and thus also provide a data
> > model. Ideally, it would lean on the good work NETCONF has done.
> > Such a data model could be advertised as a capability.
>
> HT: I think this is good. Not sure what SYSLOG data model entails but
> I'll assume it could include event types/contents. If so, could this be
> done (i.e. event types, contents) defined in a protocol independent
> manner.

So far, I have just a personal view. I will try to write a short I-D
with a problem statement soon. In my (purely personal) point of view,
I think an XML based data stream for SYSLOG content would be
advisable. For obvious reasons, that would not need to be limited to
SYSLOG. I like the data model approach NETCONF is taking. I can easily
see how one and the same XML stream could be transmitted as part of a
SYSLOG STRUCTURED-DATA element or as part of a NETCONF <GET> operation
(or whatever is invented as part of netconf notifications). Thus I
consider it vital that NETCONF does not place any preconception on the
way SYSLOG events are encoded. For example, a very basic
(hypothetical) SYSLOG event XML stream could look like:

<event>
  <syslog-message><144>HEADER,,, the raw message</message>
</event>

That obviously would be a solution for legacy senders, Other could do
things like

<event>
  <origin>orgsender.example.com</origin>
  <type>traffic-report</type>
   <source>10.0.0.1</source>
   <target>10.0.0.2</target>
   <bytes-transferred>22222</bytes-transferred>
   .
   .
   .
</event>

I think you'll get the idea. The last sample is my medium to long term
vision: some standard way of telling common events for firewalls
(traffic flow, access violations etc) and other common usage
scenarios,

OK, already written too much. I hope I have clarified.

Warp up: I think NETCONF should define what it needs for its
notifications, leave that as extensible (via capabilities) as the rest
of NETCONF and do not try to standardize things outside NETCONF
itself.

Rainer
>
> >
> > 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 Thu Jul 06 18:53:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyciU-0002XG-Sl
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 18:53:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyciU-0006gE-Am
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 18:53:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fycej-0007A2-4s
	for netconf-data@psg.com; Thu, 06 Jul 2006 22:49: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.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fyceh-00079q-N4
	for netconf@ops.ietf.org; Thu, 06 Jul 2006 22:49:08 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k66Mn6Xq029507
	for <netconf@ops.ietf.org>; Thu, 6 Jul 2006 18:49:06 -0400
Received: (qmail 7291 invoked by uid 78); 6 Jul 2006 22:49:06 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 6 Jul 2006 22:49:06 -0000
Message-ID: <44AD935C.50007@andybierman.com>
Date: Thu, 06 Jul 2006 15:49:00 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Rainer Gerhards <rgerhards@gmail.com>
CC: "Hector Trevino (htrevino)" <htrevino@cisco.com>, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com> <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
In-Reply-To: <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.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: a92270ba83d7ead10c5001bb42ec3221

Rainer Gerhards wrote:

The thing I like the most about Phil's draft is that it
it reusing, rather than reinventing, syslog.

IMO, we should have the same type of extensible, content-independent
PDU and framework that we have for <rpc>, but that syslog delivery
should be the first (and only) content that we work on right now.

The "netconf requirement" is that the content is well-formed XML and
it is identified by a namespace URI.

I envision starting with syslog/RAW and even syslog/SD-Params,
and new work can start (in the SYSLOG WG) on syslog/XML
if there is enough interest.  I don't think the NETCONF WG
should be defining any standard notification content except maybe
a config-change notification.



Andy


> <inline>
> Rainer
> 
>> HT: Because nobody (that I know of) is interested/needs to carry
>>     SNMP notifications inside NETCONF. Whether or not the Appendix B
>> proposal stays
>>     in is up for discussion next week.
> 
> That's why I raised the point today.
> 
>> > If you talk about filtering and also talk about syslog data,
>> > NETCONF IMHO actually tries to define a configuration
>> > mechanism for SYSLOG.
>> > The draft is not taking SYSLOG as *the* content format and
>> > just extending it with some syslog fields. The draft is
>> > defining a NETCONF notification format (which is perfectly
>> > fine and good to see) and then is mapping how SYSLOG should
>> > be mapped into it. The later IMHO should be done as a
>> > separate effort via a SYSLOG data model.
>>
>> HT: The title of the section is "Leveraging Syslog Field Definitions"
>> and as the title I think suggests the purpose is to re-use existing
>> syslog definitions where it makes sense.
> 
> 
>> >
>> > > > Having syslog mappings in a basic netconf document forces the
>> > > > netconf document to be changed/obsoleted whenever there
>> > is change on
>> > > > the syslog side. I think this dependency should be avoided.
>> > > >
>> > > > There is some growing interest in the syslog community to define
>> > > > event data models. This effort could play nicely together
>> > with netconf.
>> > >
>> > > Does this mean you think it is a good idea for the NETCONF WG to
>> > > create a brand-new netconf-only notification system?
>> >
>> > I think it is eventually a good idea for the NETCONF WG to
>> > create a brand-new, EXTENSIBLE notification system that could
>> > also transport events traditionally being transported via
>> > SYSLOG, SNMP or vendor-specific event notification protocols.
>> > If I understood NETCONF correctly, it is a common base that
>> > it should be extensible.
>> > Extensions can be vendor-specific or via standard
>> > capabilities. Lots of discussion on this list are focussed
>> > about data models for configuration. If I follow that spirit,
>> > NETCONF notifications should provide a framework for
>> > notification delivery, but not necessarily (and exclusively)
>> > all data models that could be transported via it.
>>
>> HT: That's the idea. Right now the doc only covers syslog & as I said in
>> a previous e-mail
>>     SNMP is not something that has come up.
> 
> That's my problem: "right now the doc only covers syslog". If so, then
> the doc is not talking about NETCONF but about SYSLOG ;) But if it is
> about SYSLOG, then it is either beyond the charter of the NETCONF WG
> or the NETCONF WG must endure that SYSLOG specifics be discussed here
> (Andy, I think, rejected the later for good reasons).
> 
> I fear that if NETCONF notifications goes into too much detail on
> SYSLOG, it will eventually distract interest in a solution for SYSLOG.
> Think about it that way: any NETCONF agent that puts SYSLOG fields
> into some NETCONF fields is not a pure NETCONF agent. It is actually a
> SYSLOG/NETCONF gateway, as is shown in the netconf-syslog draft. The
> SYSLOG side of that beast is actually ... a SYSLOG receiver.
> 
> Don't misunderstand me: I find it correct that NETCONF does
> notifications, if NETCONF needs such. I also think it is valuable to
> have an extensible notification mechanism. I just think that NETCONF
> should standardize NETCONF and not whatever else seems handy. And,
> yes, I agree SYSLOG messages are interesting to NETCONF agents. SNMP
> events, IMHO, should also be interesting if you really intend to make
> a single manager able to manage everything. In concept, I do not see
> any big difference between the need to see SYSLOG vs. SNMP events if
> you go after as many event data as possible. In practice, of course,
> SNMP is mature and well-standardized while SYSLOG is a quick ad-hoc
> solution. That doesn't mean that we should continue to look at it in a
> quick ad-hoc way.
> 
>> > > Or does it mean you think the SYSLOG WG should do this work
>> > instead of
>> > > the NETCONF WG?
>> >
>> > I think the syslog community should standardize a SYSLOG data model.
>> > As much as it probably could standardize a basic SYSLOG
>> > configuration data model (including syslog-specific filters
>> > and event actions). I do not think that the current SYSLOG WG
>> > (chartered in the SEC area) is the right one to do this. I
>> > think a new SYSLOG WG should be chartered in the OPS area to
>> > standardize syslog payload and thus also provide a data
>> > model. Ideally, it would lean on the good work NETCONF has done.
>> > Such a data model could be advertised as a capability.
>>
>> HT: I think this is good. Not sure what SYSLOG data model entails but
>> I'll assume it could include event types/contents. If so, could this be
>> done (i.e. event types, contents) defined in a protocol independent
>> manner.
> 
> So far, I have just a personal view. I will try to write a short I-D
> with a problem statement soon. In my (purely personal) point of view,
> I think an XML based data stream for SYSLOG content would be
> advisable. For obvious reasons, that would not need to be limited to
> SYSLOG. I like the data model approach NETCONF is taking. I can easily
> see how one and the same XML stream could be transmitted as part of a
> SYSLOG STRUCTURED-DATA element or as part of a NETCONF <GET> operation
> (or whatever is invented as part of netconf notifications). Thus I
> consider it vital that NETCONF does not place any preconception on the
> way SYSLOG events are encoded. For example, a very basic
> (hypothetical) SYSLOG event XML stream could look like:
> 
> <event>
>  <syslog-message><144>HEADER,,, the raw message</message>
> </event>
> 
> That obviously would be a solution for legacy senders, Other could do
> things like
> 
> <event>
>  <origin>orgsender.example.com</origin>
>  <type>traffic-report</type>
>   <source>10.0.0.1</source>
>   <target>10.0.0.2</target>
>   <bytes-transferred>22222</bytes-transferred>
>   .
>   .
>   .
> </event>
> 
> I think you'll get the idea. The last sample is my medium to long term
> vision: some standard way of telling common events for firewalls
> (traffic flow, access violations etc) and other common usage
> scenarios,
> 
> OK, already written too much. I hope I have clarified.
> 
> Warp up: I think NETCONF should define what it needs for its
> notifications, leave that as extensible (via capabilities) as the rest
> of NETCONF and do not try to standardize things outside NETCONF
> itself.
> 
> Rainer
>>
>> >
>> > 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/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 06 20:27:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyeC0-00058Z-61
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 20:27:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyeBy-0008Lq-Rg
	for netconf-archive@lists.ietf.org; Thu, 06 Jul 2006 20:27:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fye7o-000Ek5-El
	for netconf-data@psg.com; Fri, 07 Jul 2006 00:23: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=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <clonvick@cisco.com>)
	id 1Fye7o-000Ejs-00
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 00:23:16 +0000
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
  by sj-iport-2.cisco.com with ESMTP; 06 Jul 2006 17:23:16 -0700
X-IronPort-AV: i="4.06,215,1149490800"; 
   d="scan'208"; a="327666453:sNHT29261410"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k670NFmD032286;
	Thu, 6 Jul 2006 17:23:15 -0700
Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k670NFkf012411;
	Thu, 6 Jul 2006 17:23:15 -0700 (PDT)
Date: Thu, 6 Jul 2006 17:23:15 -0700 (PDT)
From: Chris Lonvick <clonvick@cisco.com>
To: Andy Bierman <ietf@andybierman.com>
cc: Rainer Gerhards <rgerhards@gmail.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
In-Reply-To: <44AD935C.50007@andybierman.com>
Message-ID: <Pine.GSO.4.63.0607061709240.24406@sjc-cde-003.cisco.com>
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
 <44AD935C.50007@andybierman.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: a=rsa-sha1; q=dns; l=1013; t=1152231795; x=1153095795;
	c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20<clonvick@cisco.com>
	|Subject:Re=3A=20sylsog=20in=20NETCONF=20notifications;
	X=v=3Dcisco.com=3B=20h=3DtD5k1MJ6RND2bFLDhnpNM0q23ZE=3D; b=kSpqZ7BdzXhYcMeRWrX3vv0MOC4oqAuqKa6Svy+bPtawmD5MwE1Dk9Qm0cffG5YEkya5SPvf
	vqpTKIVyAKCEsHYbSx1qopDfack9MryG7V9doE6q1oL3LzwXRllnjh1o;
Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@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: ea4ac80f790299f943f0a53be7e1a21a

Hi Andy,

On Thu, 6 Jul 2006, Andy Bierman wrote:

> I envision starting with syslog/RAW and even syslog/SD-Params,
> and new work can start (in the SYSLOG WG) on syslog/XML
> if there is enough interest.  I don't think the NETCONF WG
> should be defining any standard notification content except maybe
> a config-change notification.

Speaking as syslog WG Co-Chair

I appreciate your confidence in the syslog WG.  :-)  At this time, we are 
VERY focused on meeting our milestones.  We are chartered in the Security 
Area to address some specific security requirements.  If we go down the 
path you envision, then we should probably be rechartered in the OAM Area.
I'm not opposed to that, but that discussion will have to wait until after 
we meet our milestones.

Unfortunately, I won't be able to attend the netconf WG meeting on Friday, 
but I believe that David Harrington, my Co-Chair, will be there and will 
be able to represent our WG if this is discussed.

Best regards,
Chris

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 07 05:11:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FymNB-00070x-J6
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 05:11:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FymN8-0005UN-Tw
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 05:11:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FymGc-00075z-Nt
	for netconf-data@psg.com; Fri, 07 Jul 2006 09:04: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 [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FymGc-00075n-5d
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 09:04:54 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E11206E0001;
	Fri,  7 Jul 2006 11:04:52 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Jul 2006 11:04:52 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Jul 2006 11:04:51 +0200
Message-ID: <44AE23B3.6070901@ericsson.com>
Date: Fri, 07 Jul 2006 11:04:51 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC:  netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com> <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com> <44AD935C.50007@andybierman.com>
In-Reply-To: <44AD935C.50007@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jul 2006 09:04:51.0968 (UTC) FILETIME=[6816F000:01C6A1A4]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

Hello,
I hope you are not very strict with this syslog ONLY. There are a good number of nodes 
that use non-syslog notification methods. Also I feel one basic reason why we need 
notifications is  to help Netconf configuration which id not strictly syslog related. For 
me this means we should work on topics like
- basic data needed in every notification
- event classes
- filtering on XML
as well.

Sorry if I misunderstood your intent.
Balazs

Andy Bierman wrote:
> IMO, we should have the same type of extensible, content-independent
> PDU and framework that we have for <rpc>, but that syslog delivery
> should be the first (and only) content that we work on right now.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 07 08:48:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fypkw-0000BN-74
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 08:48:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fypku-00044w-Kz
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 08:48:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FypfY-000PIl-Dd
	for netconf-data@psg.com; Fri, 07 Jul 2006 12:42: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.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FypfX-000PIY-R2
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 12:42:51 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k67Cgo3X007136
	for <netconf@ops.ietf.org>; Fri, 7 Jul 2006 08:42:51 -0400
Received: (qmail 26090 invoked by uid 78); 7 Jul 2006 12:42:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 7 Jul 2006 12:42:50 -0000
Message-ID: <44AE56DB.8070506@andybierman.com>
Date: Fri, 07 Jul 2006 05:43:07 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com> <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com> <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>
In-Reply-To: <44AE23B3.6070901@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: 3e15cc4fdc61d7bce84032741d11c8e5

Balazs Lengyel wrote:
> Hello,
> I hope you are not very strict with this syslog ONLY. There are a good 
> number of nodes that use non-syslog notification methods. Also I feel 
> one basic reason why we need notifications is  to help Netconf 
> configuration which id not strictly syslog related. For me this means we 
> should work on topics like
> - basic data needed in every notification
> - event classes
> - filtering on XML
> as well.

My intent is to have a content-independent framework for delivering
notifications, but not have the NETCONF WG develop any standard
notification content unless it is directly related to configuration.

IMO, syslog is important enough that it is worthwhile to have
filtering mechanisms that actually work for syslog.
Generalized filters sound great, but if they are impossible
to use for the most common application (syslog/RAW), then
they are mostly irrelevant.  Telling all the vendors "Hey, I have a
really cool XML tool, so if you could re-design and re-code
15,000 or so syslog messages to output an XML subtree instead of text,
well, that would be great."


I suggest coming up with a transition plan, because it will
be about a decade before you get to use your fancy XML tools on
notification content.

> 
> Sorry if I misunderstood your intent.
> Balazs

Andy

> 
> Andy Bierman wrote:
>> IMO, we should have the same type of extensible, content-independent
>> PDU and framework that we have for <rpc>, but that syslog delivery
>> should be the first (and only) content that we work on right now.
> 
> 
> -- 
> to unsubscribe send a message to netconf-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 Jul 07 09:06:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fyq22-00051q-8W
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 09:06:06 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fyq20-0006sY-VL
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 09:06:06 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FypyZ-0001SO-Bn
	for netconf-data@psg.com; Fri, 07 Jul 2006 13:02: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 [64.233.162.192] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1FypyY-0001SA-SR
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 13:02:30 +0000
Received: by nz-out-0102.google.com with SMTP id l1so1711780nzf
        for <netconf@ops.ietf.org>; Fri, 07 Jul 2006 06:02:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=KKjzMOyvXsLb7RCQGzRLUakdFc4Il32se4bQooyF6eACrofPyGXmAQLJg6AVUBuRssYTb+eqOya2H/CspHCXO+tGs+0vPPyzorHHkZVIijPDabxsY9MZMThoUPIK5XFoXcyWcE2JTzMedTyxxVb0pvyOfQxCupZqGKE/SJkUYPM=
Received: by 10.36.100.15 with SMTP id x15mr1611652nzb;
        Fri, 07 Jul 2006 06:02:30 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Fri, 7 Jul 2006 06:02:30 -0700 (PDT)
Message-ID: <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>
Date: Fri, 7 Jul 2006 15:02:30 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: sylsog in NETCONF notifications
Cc: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
In-Reply-To: <44AE56DB.8070506@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>
	 <44AE56DB.8070506@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Andy,

I am a bit confused. You say:

> My intent is to have a content-independent framework for delivering
> notifications, but not have the NETCONF WG develop any standard
> notification content unless it is directly related to configuration.

I fully agree with you on that. But you also say:

> IMO, syslog is important enough that it is worthwhile to have
> filtering mechanisms that actually work for syslog.
> Generalized filters sound great, but if they are impossible
> to use for the most common application (syslog/RAW), then
> they are mostly irrelevant.  Telling all the vendors "Hey, I have a
> really cool XML tool, so if you could re-design and re-code
> 15,000 or so syslog messages to output an XML subtree instead of text,
> well, that would be great."
>
>
> I suggest coming up with a transition plan, because it will
> be about a decade before you get to use your fancy XML tools on
> notification content.

I agree with you on the need and the timing. I am not sure if I am
with you who should do that. Are you saying the NETCONF WG should do
that? If so, I think it is beyond the NETCONF charter.

I would appreciate if you could clarify if you think NETCONF should

a) develop a notification mechanism and a data model for NETCONF
and/or
b) develop a data model and transformation rules for SYSLOG

Thanks,
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 Fri Jul 07 09:14:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fyq9t-0006Ns-VX
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 09:14:13 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fyq9s-0007TC-BQ
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 09:14:13 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fyq5h-0002Bl-DB
	for netconf-data@psg.com; Fri, 07 Jul 2006 13:09: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=AWL,BAYES_00 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 1Fyq5g-0002BQ-R9
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 13:09:53 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E5BDC4F0070;
	Fri,  7 Jul 2006 15:09:51 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Jul 2006 15:09:51 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Jul 2006 15:09:50 +0200
Message-ID: <44AE5D1E.5040804@ericsson.com>
Date: Fri, 07 Jul 2006 15:09:50 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC:  netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com> <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com> <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com> <44AE56DB.8070506@andybierman.com>
In-Reply-To: <44AE56DB.8070506@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jul 2006 13:09:50.0902 (UTC) FILETIME=[A1564560:01C6A1C6]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hello,
There are some NEW implementations for Netconf as well. These don't always need a 
transition plan. Also if you look at Jurgens requirement page a good number of 
requirements are not refering to syslog.
Generally I would like to avoid being forced to use syslog in order to have a standard 
notification mechanism with filtering.
Balazs

> IMO, syslog is important enough that it is worthwhile to have
> filtering mechanisms that actually work for syslog.
> Generalized filters sound great, but if they are impossible
> to use for the most common application (syslog/RAW), then
> they are mostly irrelevant.  Telling all the vendors "Hey, I have a
> really cool XML tool, so if you could re-design and re-code
> 15,000 or so syslog messages to output an XML subtree instead of text,
> well, that would be great."
> 
> 
> I suggest coming up with a transition plan, because it will
> be about a decade before you get to use your fancy XML tools on
> notification content.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 07 10:17:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fyr9O-0004aI-Ii
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 10:17:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fyr9N-0005yr-8A
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 10:17:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fyr58-00084D-Cf
	for netconf-data@psg.com; Fri, 07 Jul 2006 14:13: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.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fyr55-00083q-47
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 14:13:21 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k67EDCQ9001046
	for <netconf@ops.ietf.org>; Fri, 7 Jul 2006 10:13:18 -0400
Received: (qmail 10343 invoked by uid 78); 7 Jul 2006 14:13:12 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 7 Jul 2006 14:13:12 -0000
Message-ID: <44AE6C16.90704@andybierman.com>
Date: Fri, 07 Jul 2006 07:13:42 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Rainer Gerhards <rgerhards@gmail.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>	 <44AE56DB.8070506@andybierman.com> <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>
In-Reply-To: <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.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

Rainer Gerhards wrote:
> Andy,
> 
> I am a bit confused. You say:
> 
>> My intent is to have a content-independent framework for delivering
>> notifications, but not have the NETCONF WG develop any standard
>> notification content unless it is directly related to configuration.
> 
> I fully agree with you on that. But you also say:
> 
>> IMO, syslog is important enough that it is worthwhile to have
>> filtering mechanisms that actually work for syslog.
>> Generalized filters sound great, but if they are impossible
>> to use for the most common application (syslog/RAW), then
>> they are mostly irrelevant.  Telling all the vendors "Hey, I have a
>> really cool XML tool, so if you could re-design and re-code
>> 15,000 or so syslog messages to output an XML subtree instead of text,
>> well, that would be great."
>>
>>
>> I suggest coming up with a transition plan, because it will
>> be about a decade before you get to use your fancy XML tools on
>> notification content.
> 
> I agree with you on the need and the timing. I am not sure if I am
> with you who should do that. Are you saying the NETCONF WG should do
> that? If so, I think it is beyond the NETCONF charter.
> 
> I would appreciate if you could clarify if you think NETCONF should
> 
> a) develop a notification mechanism and a data model for NETCONF
> and/or

not sure what you mean by 'data model'.
Yes -- if that means a data model for the
NV-stored configuration parameters for notification delivery,
and perhaps some state data related to notification delivery.


> b) develop a data model and transformation rules for SYSLOG
> 

If you mean transformation of all ad-hoc syslog text content
to a standard and structured XML hierarchy -- no.  That is way out
of scope.  However, filter parameters to suppress notification delivery
are in scope.  (The non-normative appendices are supposed to be removed.)


> Thanks,
> Rainer

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 Jul 07 10:29:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyrL8-0008Pd-7g
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 10:29:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyrL6-0007NP-UI
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 10:29:54 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FyrI6-0009Eg-Am
	for netconf-data@psg.com; Fri, 07 Jul 2006 14:26: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.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FyrI5-0009EU-Nz
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 14:26:45 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k67EQiXY016506
	for <netconf@ops.ietf.org>; Fri, 7 Jul 2006 10:26:45 -0400
Received: (qmail 24065 invoked by uid 78); 7 Jul 2006 14:26:44 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 7 Jul 2006 14:26:44 -0000
Message-ID: <44AE6F44.2010008@andybierman.com>
Date: Fri, 07 Jul 2006 07:27:16 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com> <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com> <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com> <44AE56DB.8070506@andybierman.com> <44AE5D1E.5040804@ericsson.com>
In-Reply-To: <44AE5D1E.5040804@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: 97adf591118a232206bdb5a27b217034

Balazs Lengyel wrote:
> Hello,
> There are some NEW implementations for Netconf as well. These don't 
> always need a transition plan. Also if you look at Jurgens requirement 
> page a good number of requirements are not refering to syslog.
> Generally I would like to avoid being forced to use syslog in order to 
> have a standard notification mechanism with filtering.

I suggest using a proprietary format for XML notifications,
or asking the AD for a BOF or WG charter for standardized syslog/XML.

I am strongly opposed to any new mechanisms unless they
follow the "content-independent payload" concept.  This is easy.
Just define a namespace for the specialized content instead of
hard-wiring it in as an element.

Instead of a special "syslog" capability, we need a general "notification"
capability.  The <capability> exchange should include module identifiers
that indicate that the agent supports "syslog/RAW", "syslog/COOKED", "acme/TOASTED",
or whatever content you want to use. (It will probably be a combination
of all kinds of formats for many years.)   This should be no different than
advertising the data models that can be used with <edit-config> or <get>.



> 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/>



From owner-netconf@ops.ietf.org Fri Jul 07 11:25:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FysCz-0000rf-3O
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:25:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FysCx-0005TF-Q4
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:25:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fys8A-000E3P-CD
	for netconf-data@psg.com; Fri, 07 Jul 2006 15:20: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 autolearn=ham 
	version=3.1.1
Received: from [64.233.162.197] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1Fys89-000E3C-Kq
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 15:20:33 +0000
Received: by nz-out-0102.google.com with SMTP id l1so1733705nzf
        for <netconf@ops.ietf.org>; Fri, 07 Jul 2006 08:20:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IOBOdO5cR2J2SRE6SubpJ1YHn1V1zDTXY5HeB9zCZ46EIonqncVoMzNhPZ/uG9SaPIK7s5u7nCAkwZiGnUjZhp2hp8iFFj3CDogJg7LK7+kNzL/MUfxQziRH3cRPi8Z3wFO1l3X0YyNg84pymSlcrgkYynDwVHjHPI0EEy1l98Q=
Received: by 10.36.105.17 with SMTP id d17mr2576562nzc;
        Fri, 07 Jul 2006 08:20:33 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Fri, 7 Jul 2006 08:20:32 -0700 (PDT)
Message-ID: <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.com>
Date: Fri, 7 Jul 2006 17:20:32 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: sylsog in NETCONF notifications
Cc: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
In-Reply-To: <44AE6C16.90704@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>
	 <44AE56DB.8070506@andybierman.com>
	 <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>
	 <44AE6C16.90704@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Andy,

> If you mean transformation of all ad-hoc syslog text content
> to a standard and structured XML hierarchy -- no.  That is way out
> of scope.  However, filter parameters to suppress notification delivery
> are in scope.  (The non-normative appendices are supposed to be removed.)

I agree. But these filter parameters must not be SYSLOG specific - in
the same way as <get> is not specified for SYSLOG or any other
specific case. I'd like to see some standard properties for NETCONF. I
also think that specifying extensible filter mechanisms (as in section
6.) is useful and needed.

However, I do NOT think that specifying a "severity" filter for syslog
is appropriate (or any other SYSLOG reference). That I would expect to
see in a different document, and being announced as an optional
capability at the time of <hello>.

Putting any SYSLOG specifics into the core notification document
would, IMO,  remove its payload content-independence.

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 Fri Jul 07 11:38:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FysPV-0002Hj-1u
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:38:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FysPT-00069f-NK
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:38:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FysLy-000FXJ-SO
	for netconf-data@psg.com; Fri, 07 Jul 2006 15:34: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.51] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FysLy-000FX6-81
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 15:34:50 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k67FYnw4024686
	for <netconf@ops.ietf.org>; Fri, 7 Jul 2006 11:34:49 -0400
Received: (qmail 15829 invoked by uid 78); 7 Jul 2006 15:34:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 7 Jul 2006 15:34:49 -0000
Message-ID: <44AE7F3D.2020705@andybierman.com>
Date: Fri, 07 Jul 2006 08:35:25 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Rainer Gerhards <rgerhards@gmail.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>	 <44AE56DB.8070506@andybierman.com>	 <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>	 <44AE6C16.90704@andybierman.com> <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.com>
In-Reply-To: <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.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: 538aad3a3c4f01d8b6a6477ca4248793

Rainer Gerhards wrote:
> Andy,
> 
>> If you mean transformation of all ad-hoc syslog text content
>> to a standard and structured XML hierarchy -- no.  That is way out
>> of scope.  However, filter parameters to suppress notification delivery
>> are in scope.  (The non-normative appendices are supposed to be removed.)
> 
> I agree. But these filter parameters must not be SYSLOG specific - in
> the same way as <get> is not specified for SYSLOG or any other
> specific case. I'd like to see some standard properties for NETCONF. I
> also think that specifying extensible filter mechanisms (as in section
> 6.) is useful and needed.

I agree.
I was referring to the "regexp" text filtering in Phil's draft.
I don't the best way to accomplish syslog content filtering,
but I doubt either subtree or Xpath filters would be it.

I don't think that if the netconf protocol had any particular
syslog content filters (for netconf delivery of syslog), the
syslog protocol (or WG) would be impacted in any way.



> 
> However, I do NOT think that specifying a "severity" filter for syslog
> is appropriate (or any other SYSLOG reference). That I would expect to
> see in a different document, and being announced as an optional
> capability at the time of <hello>.
> 
> Putting any SYSLOG specifics into the core notification document
> would, IMO,  remove its payload content-independence.

I agree.
We should not include non-normative appendices as a way
to avoid the actual standardization of that material either.
The final draft will be consistent with the architecture
and operations defined in the netconf-prot-12 draft.
We are not very close to a final draft yet.

> 
> Rainer
> 
> 

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 Jul 07 11:56:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyshN-0004yB-UH
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:56:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyshM-0001fq-Gl
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 11:56:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fysdh-000HIE-ET
	for netconf-data@psg.com; Fri, 07 Jul 2006 15: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=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [64.233.162.206] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1Fysdg-000HI1-Up
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 15:53:09 +0000
Received: by nz-out-0102.google.com with SMTP id l1so1739068nzf
        for <netconf@ops.ietf.org>; Fri, 07 Jul 2006 08:53:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sKJe1qLVEBBauCQYc0NjiVj4SzxFm+PRe/X9LQSV6DheIOgfCjgOqBnamtDZViFN6D1JjQy7GgHmbg1ntEDvHCJ+W17iriwUGxc4bY0nA/Jytg3Ckj2x3NhP4ZWCtlk+NhXnTPv5TZ05ujBFtnjAism1vQL2chCW/B5nZ0TzBuI=
Received: by 10.36.18.3 with SMTP id 3mr2628651nzr;
        Fri, 07 Jul 2006 08:53:08 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Fri, 7 Jul 2006 08:53:07 -0700 (PDT)
Message-ID: <dc67eef70607070853n5008725y70364b7e8b4399d1@mail.gmail.com>
Date: Fri, 7 Jul 2006 17:53:07 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: sylsog in NETCONF notifications
Cc: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
In-Reply-To: <44AE7F3D.2020705@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>
	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>
	 <44AE56DB.8070506@andybierman.com>
	 <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>
	 <44AE6C16.90704@andybierman.com>
	 <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.com>
	 <44AE7F3D.2020705@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

On 7/7/06, Andy Bierman <ietf@andybierman.com> wrote:

> I don't think that if the netconf protocol had any particular
> syslog content filters (for netconf delivery of syslog), the
> syslog protocol (or WG) would be impacted in any way.

Just to clarify: my comment dug even deeper. Here, I am not only
concerned with SYSLOG. I think the cleanness of NETCONF notifications
would be compromised if the core notifications draft depends on
non-NETCONF-native filter capabilities. I think it should be aimed to
find a filtering capability that is able to express filters in a very
generic way, including nested boolean operations and regular
expression filters. I can envison that these are useful for vendor
extensions as well as for SYSLOG.

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 Fri Jul 07 13:01:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fythl-0004e3-Uz
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 13:01:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fythj-0007j3-Jq
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 13:01:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fytdx-000MjI-9j
	for netconf-data@psg.com; Fri, 07 Jul 2006 16: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.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fytdw-000Miy-FB
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 16:57:28 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k67GvRrf003571
	for <netconf@ops.ietf.org>; Fri, 7 Jul 2006 12:57:27 -0400
Received: (qmail 28707 invoked by uid 78); 7 Jul 2006 16:57:26 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 7 Jul 2006 16:57:26 -0000
Message-ID: <44AE92AD.1010904@andybierman.com>
Date: Fri, 07 Jul 2006 09:58:21 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Rainer Gerhards <rgerhards@gmail.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
Subject: Re: sylsog in NETCONF notifications
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>	 <dc67eef70607061339h3cdaace0n129371815903eccc@mail.gmail.com>	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>	 <44AE56DB.8070506@andybierman.com>	 <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>	 <44AE6C16.90704@andybierman.com>	 <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.com>	 <44AE7F3D.2020705@andybierman.com> <dc67eef70607070853n5008725y70364b7e8b4399d1@mail.gmail.com>
In-Reply-To: <dc67eef70607070853n5008725y70364b7e8b4399d1@mail.gmail.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: 538aad3a3c4f01d8b6a6477ca4248793

Rainer Gerhards wrote:
> On 7/7/06, Andy Bierman <ietf@andybierman.com> wrote:
> 
>> I don't think that if the netconf protocol had any particular
>> syslog content filters (for netconf delivery of syslog), the
>> syslog protocol (or WG) would be impacted in any way.
> 
> Just to clarify: my comment dug even deeper. Here, I am not only
> concerned with SYSLOG. I think the cleanness of NETCONF notifications
> would be compromised if the core notifications draft depends on
> non-NETCONF-native filter capabilities. I think it should be aimed to
> find a filtering capability that is able to express filters in a very
> generic way, including nested boolean operations and regular
> expression filters. I can envison that these are useful for vendor
> extensions as well as for SYSLOG.
> 


Agreed.  The protocol itself needs to be content-independent.
I argued that even the <eventClass> field should just be
a string instead of the netconf WG defining the allowable
values of that string.  (I don't know exactly what the WG
wants to do here yet.)

I like the basic architecture Phil is proposing (except I
want to make sure any NV-stored data is handled properly).
I like the idea of NV-configuring multiple streams on an
agent, based not only on filtering subsets of the data,
but also to support different encodings of the same notifications.

I like the idea of the netconf manager issuing a <start-notifications>
RPC and subscribing to a pre-configured stream,
or providing a "my-session-only" stream config that the agent will
toss when the session is closed.

This provides a transition path to XML-encoded syslog or snmp-notif
streams.  Legacy apps will subscribe to "syslog/RAW", and gradually,
new apps will have some reason to subscribe to "syslog/XML" or "snmp/XML"
formatted streams.






> Rainer

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 Jul 07 14:20:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyuwY-0000D0-3A
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 14:20:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyuwW-0004zA-Pe
	for netconf-archive@lists.ietf.org; Fri, 07 Jul 2006 14:20:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fyuqs-0003b0-5P
	for netconf-data@psg.com; Fri, 07 Jul 2006 18:14: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 [64.233.162.192] (helo=nz-out-0102.google.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <rgerhards@gmail.com>)
	id 1Fyuqr-0003al-Hj
	for netconf@ops.ietf.org; Fri, 07 Jul 2006 18:14:53 +0000
Received: by nz-out-0102.google.com with SMTP id l1so1759081nzf
        for <netconf@ops.ietf.org>; Fri, 07 Jul 2006 11:14:52 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TzP/gAc4Xfo8rZoDdbMXXKkEniZTJZnaPfhs/vxDMZeVOyv0N67MT1y151T2i+z4uKUtUbpDmPcQTCpTGIgRqnUCz/v7oM5HSU0iwUDe07z2XowznipoqsQ8KwKJl8C81nyyuJHuQadtosWhlF77cr9rebnnvONDeGQ9uBpJEL8=
Received: by 10.36.178.19 with SMTP id a19mr2766516nzf;
        Fri, 07 Jul 2006 11:14:52 -0700 (PDT)
Received: by 10.36.196.19 with HTTP; Fri, 7 Jul 2006 11:14:52 -0700 (PDT)
Message-ID: <dc67eef70607071114s30c6cb60o9370d7bba216b866@mail.gmail.com>
Date: Fri, 7 Jul 2006 20:14:52 +0200
From: "Rainer Gerhards" <rgerhards@gmail.com>
To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: sylsog in NETCONF notifications
Cc: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, netconf@ops.ietf.org
In-Reply-To: <44AE92AD.1010904@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6E21698722408147BEA594E073E2B0AB021B2C6D@xmb-sjc-223.amer.cisco.com>
	 <44AD935C.50007@andybierman.com> <44AE23B3.6070901@ericsson.com>
	 <44AE56DB.8070506@andybierman.com>
	 <dc67eef70607070602n29e90e6i89a7f8aca30ee562@mail.gmail.com>
	 <44AE6C16.90704@andybierman.com>
	 <dc67eef70607070820y7c9be4fmf8f89b41cc7264d2@mail.gmail.com>
	 <44AE7F3D.2020705@andybierman.com>
	 <dc67eef70607070853n5008725y70364b7e8b4399d1@mail.gmail.com>
	 <44AE92AD.1010904@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

On 7/7/06, Andy Bierman <ietf@andybierman.com> wrote:
> Agreed.  The protocol itself needs to be content-independent.
> I argued that even the <eventClass> field should just be
> a string instead of the netconf WG defining the allowable
> values of that string.  (I don't know exactly what the WG
> wants to do here yet.)

Have you considered using the capability string as identifier for
eventClass? Granted, it may be a bit lengthy, but it clearly
identifies the event. That would also allow cross-checks (e.g. if
eventClass matches advertised capabilities).

> I like the basic architecture Phil is proposing (except I
> want to make sure any NV-stored data is handled properly).
> I like the idea of NV-configuring multiple streams on an
> agent, based not only on filtering subsets of the data,
> but also to support different encodings of the same notifications.
>
> I like the idea of the netconf manager issuing a <start-notifications>
> RPC and subscribing to a pre-configured stream,
> or providing a "my-session-only" stream config that the agent will
> toss when the session is closed.
>
> This provides a transition path to XML-encoded syslog or snmp-notif
> streams.  Legacy apps will subscribe to "syslog/RAW", and gradually,
> new apps will have some reason to subscribe to "syslog/XML" or "snmp/XML"
> formatted streams.

I agree.

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 Mon Jul 10 14:01:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G004O-0002kk-S9
	for netconf-archive@lists.ietf.org; Mon, 10 Jul 2006 14:01:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G004N-0002Qr-J1
	for netconf-archive@lists.ietf.org; Mon, 10 Jul 2006 14:01:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fzzzi-000OcE-Mw
	for netconf-data@psg.com; Mon, 10 Jul 2006 17:56: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.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fzzzf-000Obo-RS
	for netconf@ops.ietf.org; Mon, 10 Jul 2006 17:56:28 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k6AHtvcs011898
	for <netconf@ops.ietf.org>; Mon, 10 Jul 2006 13:56:13 -0400
Received: (qmail 15555 invoked by uid 78); 10 Jul 2006 17:55:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 10 Jul 2006 17:55:56 -0000
Message-ID: <44B29496.5070003@andybierman.com>
Date: Mon, 10 Jul 2006 10:55:34 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: FYI: updated netconf WG meeting agenda
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: 1ac7cc0a4cd376402b85bc1961a86ac2

Hi,

I have refined the agenda for Friday:

http://www3.ietf.org/proceedings/06jul/agenda/netconf.txt


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 Jul 10 19:39:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G04yi-0002Py-Up
	for netconf-archive@lists.ietf.org; Mon, 10 Jul 2006 19:15:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G04n5-0000SW-VK
	for netconf-archive@lists.ietf.org; Mon, 10 Jul 2006 19:03:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G04iG-000MrU-Ee
	for netconf-data@psg.com; Mon, 10 Jul 2006 22:58: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 [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 1G04iF-000MrC-D8
	for netconf@ops.ietf.org; Mon, 10 Jul 2006 22:58:47 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AMspxx003729
	for <netconf@ops.ietf.org>; Mon, 10 Jul 2006 18:54:52 -0400
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: FW: [XCON] XCON Data Model
Date: Tue, 11 Jul 2006 01:58:44 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0ACF86BB@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] XCON Data Model
Thread-Index: AcakQeRtHevzALpRQdi/KGdMxCCjSAAMegzQ
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <xml-dir@ietf.org>,
        "Netconf Mailing List \(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: ded6070f7eed56e10c4f4d0d5043d9c7

=20
I apologize for the possible cross-posting, but I believe that some
folks on xml-dir and Netconf WG lists would be interested in seeing
this.=20

Dan


=20

-----Original Message-----
From: Adam Roach [mailto:adam@estacado.net]=20
Sent: Monday, July 10, 2006 7:57 PM
To: XCON-IETF
Subject: [XCON] XCON Data Model

At the Dallas IETF meeting (IETF 65), the chairs called for a team of
editors to work during the following several months to produce a set of
protocol operations (semantics, not syntax) that can be used to
manipulate conference state. During the course of the discussions, it
became clear that the apparent consensus on the data model within the
working group was more illusory than rough. Unable to build the
operations on a shifting foundation, we disbanded the operations
document editor team to focus our efforts on the data model.

On June 21st, the chairs sent out a call for participants for an editing
session to work on the data model to be held on Sunday, July 9th.=20
Participants in the session are listed at the end of this message.

As a result of this editing session, Oscar Novo (the editor of the data
model document) will be producing and publishing a new version of the
data model document shortly.

In attempting to solve some of the difficulties that we have had with
the data model, the participants of this editing session concluded that
a preponderance of the issues resulted from the division of the template
portion of conference state from the fixed portion of conference state.

To address this issue, the team produced text and examples that
incorporate the controls associated with audio streams directly into
what was previously called the "fixed part" of the conference. Other
information relating to the conference (e.g. moderator controls on
streams that affect all participants' audio) are moved into appropriate
other locations (in the example given above, into the <available-media/>
section).

Additional controls required by the conference server can be added to
the document in the same way that PIDF presence documents can be
extended.

So, for example, under <users>/<user>/<endpoint>, the document for a
user participating in an audio/video conference might look something
like this (with some of the elements that aren't interesting for this
example elided):

<endpoint>
  <media>
    <type>audio</type>
    <display-type/>
    <label/>
    <src-id/>
    <status/>
    <to-mixer name=3D"AudioIn">
      <floor name=3D"main" floor_id=3D"1" instances=3D"1" =
enable=3D"true"
         value=3D"false">
      </floor>  =20
        <controls>
          <control type =3D"boolean" name=3D"mute" enable=3D"true">
            <display-text xml:lang=3D"en">Mute-Audio</display-text>
            <value>True</value>
          </control>
        </controls>
    </to-mixer>
    <from-mixer name=3D"AudioOut">
      <controls>
        <control type=3D"signed-char" name=3D"gain" enable=3D"true" >
          <display-text xml:lang=3D"en">Volume</label>
          <value>0</value>
        </control>
      </from-mixer>
    </controls>
  </media>

  <media>
    <type>video</type> (from SIP conferencing event package)
    <display-type/> (from SIP conferencing event package)
    <label/> (from SIP conferencing event package)
    <src-id/> (from SIP conferencing event package)
    <status/> (from SIP conferencing event package)
    <to-mixer name=3D"VideoIn">
      <floor name=3D"main" floor_id=3D"1" instances=3D"1" =
enable=3D"true"
         value=3D"false">
      </floor>  =20
        <controls>
          <control type=3D"boolean" name=3D"blank" enable=3D"true">
            <display-text xml:lang=3D"en">Mute Video</display-text>
            <value>True</value>
          </control>
        </controls>
    </to-mixer>
    <from-mixer name=3D"VideoOut">
      <controls>
        <control name=3D"layout" type=3D"enum" enable=3D"false">
          <display-text xml:lang=3D"en">Video Layout</label>
          <value>quadrate</value>
        </control>
      </controls>
    </from-mixer>
  </media>
</endpoint>

Similarly, controls that apply at a different level than endpoint/stream
would appear at an appropriate place in the document. So, moderator
controls that affect all media output would go under
<conference-description>/<available-media>, and look something like:

<available-media>
  <entry label=3D"23985u7t6">
    <type>audio</type>
    <display-text/>
    <status/>
    <mixing-mode/>
    <mix-level>
    <codecs>
      <entry/>
    </codecs>
    <controls>
      <control name=3D"mute" type=3D"boolean" enable=3D"false">
        <display-text xml:lang=3D"en">Mute All Audio</label>
        <value>False</value>
      </control>
    </controls>
  </entry>
  <entry label=3D"90gj2094">
    <type>video</type>
    <display-text/>
    <status/>
    <mixing-mode/>
    <mix-level>
    <codecs>
      <entry/>
    </codecs>
    <controls>
      <control name=3D"layout" type=3D"enum" enable=3D"false">
        <display-text xml:lang=3D"en">Video Layout</label>
        <value>quadrate</value>
      </control>
    </controls>
  </entry>
</available-media>

We would like to have feedback on this approach before we invest too
much time finalizing the approach in the data model draft. If time
allows, please discuss on this list prior to the meeting on Thursday. We
will, of course, visit these issues in the meeting on Thursday.

/a

---
The team that met consisted of the following participants:

Oscar Novo
Roni Even
Alan Johnston
Rohan Mahy
Cullen Jennings
Mary Barnes
Gonzalo Camarillo
Srivatsa Srinivasan

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


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 13 12:24:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G13zR-0001hO-U7
	for netconf-archive@lists.ietf.org; Thu, 13 Jul 2006 12:24:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G13zQ-0005Cc-KN
	for netconf-archive@lists.ietf.org; Thu, 13 Jul 2006 12:24:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G13uS-0002uf-Sn
	for netconf-data@psg.com; Thu, 13 Jul 2006 16:19: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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [135.245.0.39] (helo=ihemail4.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1G13uS-0002uS-4c
	for netconf@ops.ietf.org; Thu, 13 Jul 2006 16:19:28 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6DGJMFc016968;
	Thu, 13 Jul 2006 11:19:23 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <3KJ8TXY5>; Thu, 13 Jul 2006 18:19:21 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A6F6979@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Phil Shafer <phil@juniper.net>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RE: draft-shafer-netconf-syslog-00.txt - NITs
Date: Thu, 13 Jul 2006 18:19:12 +0200
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: 69a74e02bbee44ab4f8eafdbcedd94a1

A few editorial NITs for you to consider in the next revision.

While reading I noticed (sect 3.1.2.1):

            <priority facility="kern" level="debug"/>

whereas on page 7 I see:

   o  "kernel" -- Messages generated by the kernel

so should it be:

            <priority facility="kernel" level="debug"/>

so that they are in sync?
There is another occurrence on page 11.

and also (again in section 3.1.2.1):

              <parameter>peer=10.1.2.3</parameter>

And I guess that that represents and ip-address?
If so, I suggest to use an address aka RFC3330 in the range 192.0.2.0/24
This will avoid a possible later comment/discuss at IESG level.
Possibly (on page 11):
       <parameter>peer=10.*</parameter>
also is net 10? and so maybe it is then better to do 192.* ??

Further, I do not think that RFC1157 is a normative reference.
At least I would make it informative. But even if you do, 
maybe it is better to use RFC3410.

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 Fri Jul 14 11:40:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1Plx-0000wF-Ai
	for netconf-archive@lists.ietf.org; Fri, 14 Jul 2006 11:40:09 -0400
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 1G1Plx-0000sC-9P
	for netconf-archive@lists.ietf.org; Fri, 14 Jul 2006 11:40:09 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1G1Plu-0000PS-GD
	for netconf-archive@lists.ietf.org; Fri, 14 Jul 2006 11:40:09 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G1Ph9-0005G8-Ah
	for netconf-data@psg.com; Fri, 14 Jul 2006 15:35: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 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 1G1Ph8-0005Fq-47
	for netconf@ops.ietf.org; Fri, 14 Jul 2006 15:35:10 +0000
Received: from diotima.switch.ch (localhost [IPv6:::1])
	by diotima.switch.ch (8.13.6+Sun/8.13.6) with ESMTP id k6EFZ5GS016568;
	Fri, 14 Jul 2006 17:35:05 +0200 (CEST)
From: Simon Leinen <simon@limmat.switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17591.47529.185790.714165@diotima.switch.ch>
Date: Fri, 14 Jul 2006 17:35:05 +0200
To: netconf@ops.ietf.org
Subject: NETCONF Interim Meeting Location
X-Mailer: VM 7.18 under Emacs 21.3.3
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`
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199

Please note: The NETCONF Imterim Meeting will start two hours from now
(1:30 PM EDT) in the St. Charles room at the Delta Centre-Ville hotel.

See you there!
-- 
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 Jul 14 18:10:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1VrW-00033L-5R
	for netconf-archive@lists.ietf.org; Fri, 14 Jul 2006 18:10:18 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G1VrS-000669-Vq
	for netconf-archive@lists.ietf.org; Fri, 14 Jul 2006 18:10:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G1VlS-000Fzf-LU
	for netconf-data@psg.com; Fri, 14 Jul 2006 22:04: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.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 1G1VlQ-000FzQ-ER
	for netconf@ops.ietf.org; Fri, 14 Jul 2006 22:04:00 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 4CE6B55C63
	for <netconf@ops.ietf.org>; Sat, 15 Jul 2006 00:03:59 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 04607-01; Sat, 15 Jul 2006 00:03:56 +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 89FBD4D4C2;
	Sat, 15 Jul 2006 00:03:55 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 45EAF78AE4D; Sat, 15 Jul 2006 00:03:50 +0200 (CEST)
Date: Sat, 15 Jul 2006 00:03:49 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: netconf@ops.ietf.org
Subject: high-level summary of today's discussions
Message-ID: <20060714220349.GC4869@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: netconf@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d

Hi,

this afternoon, we went through the requirements list one by one and
this is what we have produced:

   1. solution should focus on notification support for configuration [AB]

=> R1: required to identify configuration changes on a device

   2. solution should support structured hierarchical data [BL, SC]

=> not meaningful since we do not focus on the content of a notification

   3. solution should be able to carry configuration fragments [?]

=> not meaningful since we do not focus on the content of a notification

   4. solution should support a reasonable message size limit (syslog and 
      SNMP are rather constrained in terms of message sizes) [BL]

=> netconf does not impose message size constraints

   5. solution should provide reliable delivery of notifications [BL]

=> netconf does have a reliable transport which is good enough

   6. solution should support preconfigured notification destinations [AB]

=> nice to have feature if there is a solution - ISMS is investigating
   whether there is a solution for SSH (seems to be easy over BEEP)

=> this is just a notification specific instantiation of the call home
   feature (see below)

   7. solution should support agent initiated connections [KW]

=> this is a transport issue and as such must be handled outside the
   notification work

   8. solution should provide a subscription mechanism [HT]

=> subscription is vague - does it mean a subscription that is bound
   to the lifetime of a session or is it a more permanent subscription?

=> R2: an agent does not send notifications before asked to do so

=> R3: the manager initiates the flow of notifications

   9. solution should support multiple subscriptions [RP]

=> netconf supports multiple session which means that multiple
   subscription in separate different sessions is covered

=> multiple subscriptions over the same session are not required

  10. solution should provide a filtering mechanism [HT]

=> R4: yes

  11. solution should support notification names [BL]

=> notification names belong into the data content

=> R5: it is required to be able to filter on the data content

  12. solution should support notification timestamps [BL]

=> notification timestamps belong into the data content

  13. solution should support notification classes [SC]

=> notification classes belong into the data content

  14. solution should support notification info [BL]

=> notification info belong into the data content

  15. solution should provide the ability to specify the content of 
      notifications to ensure predictability [SC]

=> notifications should be formally defined, to be addressed by data
   modeling language efforts

  16. solution should send sufficient information in a notification so 
      that it can be analyzed independent of the transport mechanism [AB]

=> R6: data content fully describes a notification; protocol information
       is not needed to understand a notification

  17. solution should allow notifications to refer to prior configuration 
      change RPCs

=> belongs into the data content

  18. solution should not bind subscriptions to a connection [RP]

=> sounds a bit too complex - unclear what the real use case is

  19. channels for configuration change notifications should share fate 
      with a session that includes a configuration channel [DP]

=> R7: sessions are independent

  20. solution should support replay of locally logged notifications [KW]

=> need to distinguish between retrieval of logged notifications and
   replay of notifications

=> might be a capability

=> R8: yes

  21. solution should support message chunking capability in cases 
      channels carry mixed RPCs [KW]

=> netconf does not interleave messages, no chunking/fragmentation needed

  22. solution should scale to 30.000-100.000 nodes which may emit
      notifications [BL]

=> the netconf transport has already been decided

  23. solution should scale to order 30.000-100.000 nodes to send
      notifications [BL] 

=> dropped

/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 Jul 15 08:43:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1jUP-0006fJ-3J
	for netconf-archive@lists.ietf.org; Sat, 15 Jul 2006 08:43:21 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G1jUM-0005BG-OV
	for netconf-archive@lists.ietf.org; Sat, 15 Jul 2006 08:43:21 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G1jPw-000H5v-6N
	for netconf-data@psg.com; Sat, 15 Jul 2006 12:38:44 +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 1G1jPv-000H5g-7v
	for netconf@ops.ietf.org; Sat, 15 Jul 2006 12:38:43 +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 k6FCcel17166
	for <netconf@ops.ietf.org>; Sat, 15 Jul 2006 08:38:41 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C6A80B.9999AC83"
Subject: Issue Breakdown: Endless RPC versus notification thing
Date: Sat, 15 Jul 2006 08:38:38 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B409C3B1AC@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Issue Breakdown: Endless RPC versus notification thing
thread-index: AcaoC5gK1x1J4whLR7CzDN77dw57mQ==
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: 3a4bc66230659131057bb68ed51598f8

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A80B.9999AC83
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

hi

Attached is a breakdown of some of the issues with both approaches.

Sharon Chisholm
Nortel=20
Ottawa, Ontario
Canada

------_=_NextPart_001_01C6A80B.9999AC83
Content-Type: application/octet-stream;
	name="issue_breakdown.pdf"
Content-Transfer-Encoding: base64
Content-Description: issue_breakdown.pdf
Content-Disposition: attachment;
	filename="issue_breakdown.pdf"

JVBERi0xLjMNJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDggDS9IIFsgNjEy
IDE2NiBdIA0vTCA0OTU5IA0vRSAzMjY5IA0vTiAxIA0vVCA0NzIyIA0+PiANZW5kb2JqDSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTYgOSANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwNTIzIDAwMDAwIG4NCjAwMDAw
MDA3NzggMDAwMDAgbg0KMDAwMDAwMDkzMSAwMDAwMCBuDQowMDAwMDAxMDMzIDAwMDAwIG4NCjAw
MDAwMDExMzkgMDAwMDAgbg0KMDAwMDAwMzE2MSAwMDAwMCBuDQowMDAwMDAwNjEyIDAwMDAwIG4N
CjAwMDAwMDA3NTggMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxNQ0vSW5mbyA0IDAgUiANL1Jv
b3QgNyAwIFIgDS9QcmV2IDQ3MTMgDS9JRFs8ZWE4ZWM1ZDZlMTUwMmFiMWEyOTgyNjA0NjgxOGIy
MGU+PDk5OGYzN2M0ODdkNTQ5MTJlNWU4NWY2NWE3OTJlYTIyPl0NPj4Nc3RhcnR4cmVmDTANJSVF
T0YNICAgICAgDTcgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMyAwIFIgDS9NZXRh
ZGF0YSA1IDAgUiANL1BhZ2VMYWJlbHMgMiAwIFIgDT4+IA1lbmRvYmoNMTMgMCBvYmoNPDwgL1Mg
MzYgL0wgNjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNCAwIFIgPj4gDXN0cmVhbQ0K
SIliYGBgZ2BgSmEAAs65DNgAB5QWAGJWKGZg8GPg5kxI4KtsAPMYGRh4gJiBCYg9AAIMAITDA7cN
ZW5kc3RyZWFtDWVuZG9iag0xNCAwIG9iag01NiANZW5kb2JqDTggMCBvYmoNPDwgDS9UeXBlIC9Q
YWdlIA0vUGFyZW50IDMgMCBSIA0vUmVzb3VyY2VzIDkgMCBSIA0vQ29udGVudHMgMTEgMCBSIA0v
Um90YXRlIC05MCANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEy
IDc5MiBdIA0+PiANZW5kb2JqDTkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v
Rm9udCA8PCAvRjEgMTAgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMTIgMCBSID4+IA0+PiAN
ZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2Rp
bmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lcy1Sb21hbiANPj4gDWVuZG9iag0x
MSAwIG9iag08PCAvTGVuZ3RoIDE5NDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SInsl0mzm0YQgO/8ijkOroCZYS/f4i12xalKrKocVD7w0Og9bATPgCz7b+QXp3s2FiEcV66+CBA9
Pb1+03x2GKmIEwe5nwUpScPEDxNOMj/LGAn9kDPSCfs6STI/ZePbPMO3fz8hjRP4eZiRe+fp6/eM
3PcTjbmfZKFe46Ugl4a46uj8ubFoaoaXRD6PI7Xo153z9BUjjOyOTgD6/JTznOhLQGLG/DRME6MC
5E4gd+94gR8E8FTC0+7i7Okbl3Ha92fXY4wK4n7YvXVe7pzP84AkSewH2a14xHnqx0G8fD0LyDR2
UcAmgcjyZBmI1W2X/m+5rRdqp6XPETpNn7f98PSvqv9E3N3HFUfjPPSz9MoV+5onPufhZuqnUWHg
22bK1/f9EVf1SpvhPX1XDdW9C+9DWrgx/A5V29zKbMy5DypuORzFEEh2lfl1h3ns5xDn/5Ta+b4/
5LBeaf193p5OAhyNaDP01s+YZdBxmey8POck8MMgJ566yH1uSLCI+6kxXMVKC5qMasFpRq2ILhAj
wvyYRXMRE9IVgyawQIN0bFYkZgRaE5i35KrErJTXJOa5n0rcyFAAiYnSaA4d6D0FHM/cXmSNfnU9
8JIKN/IZPZBTe9D0Ac3MZzHZvdC0CiWu9B0u7sTnc9WJngwPgvRALg5FLlxIG+2+CBcMC2nnQrlQ
pXH3ZMo93xoxtOROkOKuFgRuO1xJS1F9EfNlEEa9Du8ujtxf9FBr2FaAERCUb5MJV5t2qI5VCd4l
0IX4O3ahVZxKJpVt04hSvQZtuQ9Zif10jACXcnv63vUScGpwvQguRfnpKmBjvPa0Oj3WQvb/SV2a
YYkDa0hkPYykh40Qhx6DUmJahoeqN44qgxIjj3forvgq05Ao4xIIfwD9WJBL22krwS0OAImsncjn
0smgh6DUpRLyG0Yqo7BZlmcBPZ3roUIn8E+rJVy4OxYX03k1njPlOdOeM+l5/wvpW+u+NCQcyzNU
7rcDASVt31dYHPqowL6I8m1eGJktVBiR26iIYnjF7EZx6HMAx7QDtYTmwG0Bw4ENCW3GbQnDgRWJ
dRBEEWQ1DpL/CQLbtmPfsgUASmx2Bg3GQUMzfzz3yz62etTmpkcLWRZE0cD086SVD6IuoLoT+s3l
AdoJVk6q0dT0eie9azsha6kbimaQ6hf9qvrAM7eygJtj251UM8huPRW4t+wCjwX0XrXEMJbxd8wd
OxBQiRvv6QvxWLdSm5Q7Yf9KaXuILu2MRztjtRXiLaZto65C/nZuCL8NJtX8dSCXanjQGJk03qRz
jb4YRxZYzSipq1M1IOLhjwqsox05yWKh3jyt3IZccoTKCiphKCgaBbEpo6+dGB7aXtmJRwBe60Je
BmP9sOBFusr5VHI+VZCZ1IdB+Vge3lgfe7rDqDx27Z3kXCQTAQCFkNX1eh74qEODs8X9OVW/Z0Av
h2BVDRmN49I4Pmc/LGxqHPyhlmR9cUr6oRPFqSfFPFXqbPPMLW56EfJYq2uf/AG8LPTToudym5x8
pecKaI72ODtb5oc0hU4vattApYUxQikP2CaMjcwGjK3IBoxhrEngUN2isRbZwLGW2OKxEdkAshb5
YSKHORz8cZjPiDyZQcwd5vVlc/Bq0feg7xGqg+NY9c1lOUwO5NCKfjvBsiPIQwFDFJz+rgcnAZU4
gqvUAp096afVDt5jC1dHhDlXiwB8OOvNKnL8iqX9+a4vu+pxPkPNho3lGb+nv6tPpBbaJaTgLtSh
6Rcvxm6eNPJyJg3sTGq0Hc5d1dy7OQ6dAA4Y1ODrq4OAXZpni+Psap4FVsHA8lV2IgQZYFAK0DcJ
9ZTvED1EBTY0whaOPfjniE+fJM7x3SK+dlwzvXs8N3LgLOpq0IObjHNEn0HGET+v5AeVPCBwnCvR
o4Qus8+sZiY1y0MXAykus6aejMaTcbc3ueIEymMc+O0ZyjQjX4hj1QgiEFaQVSpOAk8pJMfqF0Nm
FegD1YQU6zGjYGI3r6XrI/jeZXjeIkwzWh3UWSxPNcXZjOqxFDB76IrjcF3VVzUiU4zV9lgXsOyx
HcCNqqjXvlJkqHB6Lrr2jOeYLWvArK3qfLRbd98bFyKUQxGhqUyexmq2yukBfMmpPA5ynB08rs5+
KeDFcnDCV2rN7fAuZ5w9hXZXxZ/I5tZ+RtrP666dTIBUTgWw6FG00AS+5TugLgRQbvJdy2zx3Yjc
5nsYBT4Lx50S7rMkn0HViGi+b0gYvm+JaFM2RAzfV0Ru8D3kfpbGa3xffLxKvs/xHqvej1fxbltJ
NcZI9+lQNSnZc3MFY8Mv+BqDWetwA9DXpfzKxUOjlVXblaqGexdEmESsLNVT1aiiHQebq3JdRIBC
XfcQAFjwjJRF888wR9VyYukEQk2vGImlB+mfxPpJLEWsEPiR8WSTWEZmg1hW5DaxOExzQRjZnSL4
7MjDGSaWIqMWnvG5iIbahhKUiMD50drMOGREDPc2tGz4bEW0z1taOAzsEIgNWww9N7QYEa3lu3yF
KdsPspDP+DoOZdTUQEBeO4y8JYx8BN1BnJELYQF5R/YfAnJwYqyilKQ5JBMyDONenqXEw+k8xu3f
O/8OAERYC3oKZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSAN
L1NBIGZhbHNlIA0vU00gMC4wMiANL1RSMiAvRGVmYXVsdCANPj4gDWVuZG9iag0xIDAgb2JqDTw8
IA0vUyAvRCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vTnVtcyBbIDAgMSAwIFIgXSANPj4gDWVu
ZG9iag0zIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgOCAwIFIgXSANL0NvdW50IDEg
DT4+IA1lbmRvYmoNNCAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDA2MDcxNTA4MzUzNS0w
NCcwMCcpDS9Nb2REYXRlIChEOjIwMDYwNzE1MDgzNTM1LTA0JzAwJykNL1Byb2R1Y2VyIChBY3Jv
YmF0IERpc3RpbGxlciA1LjAgXChXaW5kb3dzXCkpDS9DcmVhdG9yIChQU2NyaXB0NS5kbGwgVmVy
c2lvbiA1LjIpDS9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBpc3N1ZV9icmVha2Rvd24uZG9jKQ0+
PiANZW5kb2JqDTUgMCBvYmoNPDwgL1R5cGUgL01ldGFkYXRhIC9TdWJ0eXBlIC9YTUwgL0xlbmd0
aCAxMDI5ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1wQ2VoaUh6cmVT
ek5UY3prYzlkJyBieXRlcz0nMTAyOCc/PjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53
My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9i
ZS5jb20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL25z
LmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8x
LjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDA2LTA3LTE1VDEyOjM1OjM1WicgcGRmOk1vZERhdGU9
JzIwMDYtMDctMTVUMTI6MzU6MzVaJyBwZGY6UHJvZHVjZXI9J0Fjcm9iYXQgRGlzdGlsbGVyIDUu
MCAoV2luZG93cyknIHBkZjpDcmVhdG9yPSdQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjInIHBkZjpU
aXRsZT0nTWljcm9zb2Z0IFdvcmQgLSBpc3N1ZV9icmVha2Rvd24uZG9jJy8+CjxyZGY6RGVzY3Jp
cHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhtbG5z
OnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDYt
MDctMTVUMTI6MzU6MzVaJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwNi0wNy0xNVQxMjozNTozNVonIHhh
cDpNZXRhZGF0YURhdGU9JzIwMDYtMDctMTVUMTI6MzU6MzVaJz48eGFwOlRpdGxlPjxyZGY6QWx0
PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+TWljcm9zb2Z0IFdvcmQgLSBpc3N1ZV9icmVh
a2Rvd24uZG9jPC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwvcmRmOkRlc2NyaXB0aW9u
Pgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vcHVybC5vcmcvZGMvZWxl
bWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBk
Yzp0aXRsZT0nTWljcm9zb2Z0IFdvcmQgLSBpc3N1ZV9icmVha2Rvd24uZG9jJy8+CjwvcmRmOlJE
Rj48P3hwYWNrZXQgZW5kPSdyJz8+CmVuZHN0cmVhbQ1lbmRvYmoNeHJlZg0wIDYgDTAwMDAwMDAw
MDAgNjU1MzUgZg0KMDAwMDAwMzIzOSAwMDAwMCBuDQowMDAwMDAzMjY5IDAwMDAwIG4NCjAwMDAw
MDMzMTEgMDAwMDAgbg0KMDAwMDAwMzM3NSAwMDAwMCBuDQowMDAwMDAzNjAxIDAwMDAwIG4NCnRy
YWlsZXINPDwNL1NpemUgNg0vSURbPGVhOGVjNWQ2ZTE1MDJhYjFhMjk4MjYwNDY4MThiMjBlPjw5
OThmMzdjNDg3ZDU0OTEyZTVlODVmNjVhNzkyZWEyMj5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN

------_=_NextPart_001_01C6A80B.9999AC83--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 15 16:21:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1qdz-0000pv-DC
	for netconf-archive@lists.ietf.org; Sat, 15 Jul 2006 16:21:43 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G1qdx-0002Kh-U4
	for netconf-archive@lists.ietf.org; Sat, 15 Jul 2006 16:21:43 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G1qYL-0007Cv-AE
	for netconf-data@psg.com; Sat, 15 Jul 2006 20:15: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=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 1G1qYJ-0007CY-QH
	for netconf@ops.ietf.org; Sat, 15 Jul 2006 20:15:52 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 0E72C4D578
	for <netconf@ops.ietf.org>; Sat, 15 Jul 2006 22:15:51 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 26530-04; Sat, 15 Jul 2006 22:15:47 +0200 (CEST)
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 024303998E;
	Sat, 15 Jul 2006 22:15:47 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 7F2B279157F; Sat, 15 Jul 2006 22:15:43 +0200 (CEST)
Date: Sat, 15 Jul 2006 22:15:42 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: netconf@ops.ietf.org
Subject: some more interim notes
Message-ID: <20060715201542.GA7393@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: netconf@ops.ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached are some more notes. The meaning of all this will be
explained by the chairs. ;-)

/js

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

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netconf-interim-notes.txt"

   1. solution should focus on notification support for configuration [AB]

=> R1: required to identify configuration changes on a device

   2. solution should support structured hierarchical data [BL, SC]

=> not meaningful since we do not focus on the content of a notification

   3. solution should be able to carry configuration fragments [?]

=> not meaningful since we do not focus on the content of a notification

   4. solution should support a reasonable message size limit (syslog and 
      SNMP are rather constrained in terms of message sizes) [BL]

=> netconf does not impose message size constraints

   5. solution should provide reliable delivery of notifications [BL]

=> netconf does have a reliable transport which is good enough

   6. solution should support preconfigured notification destinations [AB]

=> nice to have feature if there is a solution - ISMS is investigating
   whether there is a solution for SSH (seems to be easy over BEEP)

=> this is just a notification specific instantiation of the call home
   feature (see below)

   7. solution should support agent initiated connections [KW]

=> this is a transport issue and as such must be handled outside the
   notification work

   8. solution should provide a subscription mechanism [HT]

=> subscription is vague - does it mean a subscription that is bound
   to the lifetime of a session or is it a more permanent subscription?

=> R2: an agent does not send notifications before asked to do so

=> R3: the manager initiates the flow of notifications

   9. solution should support multiple subscriptions [RP]

=> netconf supports multiple session which means that multiple
   subscription in separate different sessions is covered

=> multiple subscriptions over the same session are not required

  10. solution should provide a filtering mechanism [HT]

=> R4: yes

  11. solution should support notification names [BL]

=> notification names belong into the data content

=> R5: it is required to be able to filter on the data content

  12. solution should support notification timestamps [BL]

=> notification timestamps belong into the data content

  13. solution should support notification classes [SC]

=> notification classes belong into the data content

  14. solution should support notification info [BL]

=> notification info belong into the data content

  15. solution should provide the ability to specify the content of 
      notifications to ensure predictability [SC]

=> notifications should be formally defined, to be addressed by data
   modeling language efforts

  16. solution should send sufficient information in a notification so 
      that it can be analyzed independent of the transport mechanism [AB]

=> R6: data content fully describes a notification; protocol information
       is not needed to understand a notification

  17. solution should allow notifications to refer to prior configuration 
      change RPCs

=> belongs into the data content

  18. solution should not bind subscriptions to a connection [RP]

=> sounds a bit too complex - unclear what the real use case is

  19. channels for configuration change notifications should share fate 
      with a session that includes a configuration channel [DP]

=> R7: sessions are independent

  20. solution should support replay of locally logged notifications [KW]

=> need to distinguish between retrieval of logged notifications and
   replay of notifications

=> might be a capability

=> R8: yes

  21. solution should support message chunking capability in cases 
      channels carry mixed RPCs [KW]

=> netconf does not interleave messages, no chunking/fragmentation needed

  22. solution should scale to 30.000-100.000 nodes which may emit
      notifications [BL]

=> the netconf transport has already been decided

  23. solution should scale to order 30.000-100.000 nodes to send
      notifications [BL] 

=> dropped

----------------------------------------------

Consensus Points:

=> The solution will support multiple event streams

=> There will be a special named stream to carry "netconf"
   notifications

=> There might be other special named streams to carry "snmp"
   notifications

=> Filters are applied before a notification is shipped over a
   session. Filters are established as part of the subcription (and
   they share fate with the underlying session

=> An empty filter matches all notifications

=> The configuration of streams is out of scope for the current work
   in this working group

----------------------------------------------

There are three potential ways to ship notifications:

a) One big (potentially never ending) reply that ships multiple
   notifications

b) A subscribe RPC followed by a sequence of "linked" replies, each
   one carrying a notification (but no other RPCs interleaved)

c) Same as b) but interleaved requests are allowed

S: <rpc-reply>              S: <rpc-notify-reply>
S:   <data>                 S:    <data>
S:     <event>              S:    </data>
S:     </event>             S: </rpc-notify-reply>
S:     <event>              S: ]]>]]>
S:     </event>             S: <rpc-notify-reply>
S:   </data>                S:    <data>
S: </rpc-reply>             S:    </data>
S: ]]>]]>                   S: </rpc-notify-reply>
                            S: ]]>]]>

=> There was consensus towards b). A server is not required to process
   RPC requests until the notification stream is done

=> A capability may be defined to announce that a server is capable to
   process RPCs while a notification stream is active on a session

=> Every implementation should be correct

----------------------------------------------

The WG editors will rewrite the WG notification document. It was
requisted to remove all the appendices.

----------------------------------------------

Discussion of standard <get> operation vs. collections of specific
<get-xxx> operations. One point raised was that a specialized
operation might have the feature that it can pull things together from
different subtrees and namespaces, e.g. <get-vlan-info> with parameter
42 might retrieve all information related to vlan 42.

----------------------------------------------

<ns:ietf ns="urn:ietf:params:xml:ns:netconf-data:1.0">
  <ns:netconf>
    <ns:stream>
      <ns:name>snmp</ns:name>
      <!-- ... -->    
    </ns:stream>
  </ns:netconf>
</ns:ietf>


Q: What is the granularity of a namespace?

Q: How does the granularity affect filter expressions?

----------------------------------------------

The function library of XPATH 2.0 supports regular expressions in the
function library. XPATH 1.0 does not have something like that.

--IJpNTDwzlM2Ie8A6--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 17 13:40:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2X52-0003XL-O3
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 13:40:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2X51-0002ii-5a
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 13:40:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G2Wyq-00035O-GR
	for netconf-data@psg.com; Mon, 17 Jul 2006 17:34: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=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [213.180.94.158] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1G2Wyo-000355-IX
	for netconf@ops.ietf.org; Mon, 17 Jul 2006 17:34:02 +0000
Received: from localhost (c83-176-211-235.cust.tele2.se [83.176.211.235])
	by mail.tail-f.com (Postfix) with ESMTP id AEF841B8016
	for <netconf@ops.ietf.org>; Mon, 17 Jul 2006 19:33:50 +0200 (CEST)
Date: Mon, 17 Jul 2006 19:33:49 +0200 (CEST)
Message-Id: <20060717.193349.21925466.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: SSH channels
From: Martin Bjorklund <mbj@tail-f.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.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

Hi,

At the interim we briefly discussed whether NETCONF supports multiple
SSH channels as "a well hidden feature".

In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
channels are not supported (at least not very cleanly), since it
explicitly states that when an agent receives a <close-session>, it
shall terminate the SSH session and the TCP connection.

(So theoretically one could try to open multiple netconf sessions over
new ssh channels over the same ssh session, but as soon as one of the
netconf sessions sends <close-session>, all these netconf sessions
will be torn down.)


/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 Jul 17 13:52:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2XGC-0002Eu-CT
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 13:52:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2XGB-0003bv-2i
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 13:52:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G2XCI-0004BF-D4
	for netconf-data@psg.com; Mon, 17 Jul 2006 17:47: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.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1G2XCG-0004Ax-F6
	for netconf@ops.ietf.org; Mon, 17 Jul 2006 17:47:57 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k6HHls73014494
	for <netconf@ops.ietf.org>; Mon, 17 Jul 2006 13:47:55 -0400
Received: (qmail 10674 invoked by uid 78); 17 Jul 2006 17:47:54 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 17 Jul 2006 17:47:54 -0000
Message-ID: <44BBCCC6.4000202@andybierman.com>
Date: Mon, 17 Jul 2006 10:45:42 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: SSH channels
References: <20060717.193349.21925466.mbj@tail-f.com>
In-Reply-To: <20060717.193349.21925466.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: b19722fc8d3865b147c75ae2495625f2

Martin Bjorklund wrote:
> Hi,
> 
> At the interim we briefly discussed whether NETCONF supports multiple
> SSH channels as "a well hidden feature".
> 
> In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
> channels are not supported (at least not very cleanly), since it
> explicitly states that when an agent receives a <close-session>, it
> shall terminate the SSH session and the TCP connection.
> 
> (So theoretically one could try to open multiple netconf sessions over
> new ssh channels over the same ssh session, but as soon as one of the
> netconf sessions sends <close-session>, all these netconf sessions
> will be torn down.)

thanks -- this is the exact text, and I also remember clearly
that when the WG took out multiple conceptual functional channels
at the RPC layer, we decided to hide it, and support them later
in the transport layer instead.


> 
> 
> /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 Mon Jul 17 16:04:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2ZKZ-0000p6-EN
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 16:04:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2ZKY-0002cW-4x
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 16:04:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G2Z4Q-000Cal-8z
	for netconf-data@psg.com; Mon, 17 Jul 2006 19:47: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 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 1G2Z4P-000CaY-Ls
	for netconf@ops.ietf.org; Mon, 17 Jul 2006 19:47:57 +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 k6HJlsX58866;
	Mon, 17 Jul 2006 12:47:54 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (leida.juniper.net [172.18.16.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k6HJlng50956;
	Mon, 17 Jul 2006 12:47:49 -0700 (PDT)
	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])
	by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k6HJlmwn034557;
	Mon, 17 Jul 2006 15:47:48 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200607171947.k6HJlmwn034557@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
cc: netconf@ops.ietf.org
Subject: Re: SSH channels 
In-Reply-To: Your message of "Mon, 17 Jul 2006 19:33:49 +0200."
             <20060717.193349.21925466.mbj@tail-f.com> 
Date: Mon, 17 Jul 2006 15:47:48 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Martin Bjorklund writes:
>In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
>channels are not supported (at least not very cleanly), since it
>explicitly states that when an agent receives a <close-session>, it
>shall terminate the SSH session and the TCP connection.

I don't see this.  Section 3 of draft-ietf-netconf-ssh-06.txt reads:

   After the ssh-connection service is established, the client will open
   a channel of type "session", which will result in an SSH session.

So the "SSH session" refers to the SSH channel of type "session".

Then in Section 5, we have:

   ... When the agent processes a <close-session>
   command, the agent shall respond and terminate the SSH session.  The
   agent MUST NOT process any RPC commands received on the current
   session after the <close-session> command.

If you see the use of netconf over a distinct channel as a distinct
netconf session, then the close-session on one would not affect the
other.  You get this for free with openssh, since the ssh daemon spawns
the subsystem as a child process, cleaning up when all children have
been reaped.  If you start two netconf subsystems, sshd will continue
until both have died.

The other reading would mean that <close-session> would need to kill
the parent sshd.  Even so, if the only thing blocking this is the close
RPC, we could fix the close RPC.

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 Jul 17 16:29:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2Ziv-0003Qe-G5
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 16:29:49 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2Zit-0006iJ-2B
	for netconf-archive@lists.ietf.org; Mon, 17 Jul 2006 16:29:49 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G2Zee-000FTv-8k
	for netconf-data@psg.com; Mon, 17 Jul 2006 20:25: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 [205.178.146.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1G2Zed-000FTi-HS
	for netconf@ops.ietf.org; Mon, 17 Jul 2006 20:25:23 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k6HKPLxi030837
	for <netconf@ops.ietf.org>; Mon, 17 Jul 2006 16:25:22 -0400
Received: (qmail 16306 invoked by uid 78); 17 Jul 2006 20:18:54 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 17 Jul 2006 20:18:54 -0000
Message-ID: <44BBF02B.60706@andybierman.com>
Date: Mon, 17 Jul 2006 13:16:43 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: SSH channels
References: <200607171947.k6HJlmwn034557@idle.juniper.net>
In-Reply-To: <200607171947.k6HJlmwn034557@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:
> Martin Bjorklund writes:
>> In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
>> channels are not supported (at least not very cleanly), since it
>> explicitly states that when an agent receives a <close-session>, it
>> shall terminate the SSH session and the TCP connection.
> 
> I don't see this.  Section 3 of draft-ietf-netconf-ssh-06.txt reads:
> 
>    After the ssh-connection service is established, the client will open
>    a channel of type "session", which will result in an SSH session.
> 
> So the "SSH session" refers to the SSH channel of type "session".
> 
> Then in Section 5, we have:
> 
>    ... When the agent processes a <close-session>
>    command, the agent shall respond and terminate the SSH session.  The
>    agent MUST NOT process any RPC commands received on the current
>    session after the <close-session> command.
> 
> If you see the use of netconf over a distinct channel as a distinct
> netconf session, then the close-session on one would not affect the
> other.  You get this for free with openssh, since the ssh daemon spawns
> the subsystem as a child process, cleaning up when all children have
> been reaped.  If you start two netconf subsystems, sshd will continue
> until both have died.
> 
> The other reading would mean that <close-session> would need to kill
> the parent sshd.  Even so, if the only thing blocking this is the close
> RPC, we could fix the close RPC.


Fair enough.
Like almost every thing else in this protocol,
there are usually multiple passages to cite that may be
interpreted in particular ways that support many viewpoints
on the same complex problem.

(Like another book I know of, but that's out of scope ;-)


> 
> 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 Tue Jul 18 13:03:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2syo-0002Uv-Jz
	for netconf-archive@lists.ietf.org; Tue, 18 Jul 2006 13:03:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2sym-0004vM-5a
	for netconf-archive@lists.ietf.org; Tue, 18 Jul 2006 13:03:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G2sst-0008t4-Ho
	for netconf-data@psg.com; Tue, 18 Jul 2006 16:57: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [213.180.94.158] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1G2ssq-0008sl-O8
	for netconf@ops.ietf.org; Tue, 18 Jul 2006 16:57:20 +0000
Received: from localhost (h232n1c1o851.bredband.skanova.com [81.225.32.232])
	by mail.tail-f.com (Postfix) with ESMTP id 9BE931B8011;
	Tue, 18 Jul 2006 18:57:08 +0200 (CEST)
Date: Tue, 18 Jul 2006 18:57:07 +0200 (CEST)
Message-Id: <20060718.185707.85409376.mbj@tail-f.com>
To: phil@juniper.net
Cc: netconf@ops.ietf.org
Subject: Re: SSH channels 
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <200607171947.k6HJlmwn034557@idle.juniper.net>
References: <20060717.193349.21925466.mbj@tail-f.com>
	<200607171947.k6HJlmwn034557@idle.juniper.net>
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.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >In draft-ietf-netconf-ssh-05,txt, section 5 implies that multiple
> >channels are not supported (at least not very cleanly), since it
> >explicitly states that when an agent receives a <close-session>, it
> >shall terminate the SSH session and the TCP connection.
> 
> I don't see this.  Section 3 of draft-ietf-netconf-ssh-06.txt reads:
> 
>    After the ssh-connection service is established, the client will open
>    a channel of type "session", which will result in an SSH session.
> 
> So the "SSH session" refers to the SSH channel of type "session".

You're right.  I looked at an old version of the draft...  sorry about
that.

Furthermore, section 5 says:

   To continue the example used in previous sections, an existing
   NETCONF subsystem session could be closed as follows:
           ^^^^^^^^^^^^^^^^^

> Then in Section 5, we have:
> 
>    ... When the agent processes a <close-session>
>    command, the agent shall respond and terminate the SSH session.  The
>    agent MUST NOT process any RPC commands received on the current
>    session after the <close-session> command.
> 
> If you see the use of netconf over a distinct channel as a distinct
> netconf session, then the close-session on one would not affect the
> other.  You get this for free with openssh, since the ssh daemon spawns
> the subsystem as a child process, cleaning up when all children have
> been reaped.  If you start two netconf subsystems, sshd will continue
> until both have died.
> 
> The other reading would mean that <close-session> would need to kill
> the parent sshd.  Even so, if the only thing blocking this is the close
> RPC, we could fix the close RPC.

So, I also think that the draft should be read as mapping one SSH
channel to one NETCONF session.

(Which, as you pointed out, makes it easier to use OpenSSH, since this
is it's default behaviour.)


/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 Wed Jul 19 09:59:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3CaI-0007aA-MH
	for netconf-archive@lists.ietf.org; Wed, 19 Jul 2006 09:59:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G3CaH-0003tL-4x
	for netconf-archive@lists.ietf.org; Wed, 19 Jul 2006 09:59:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G3CSA-000Gqw-E8
	for netconf-data@psg.com; Wed, 19 Jul 2006 13:51: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=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 <hideki.okita.pf@hitachi.com>)
	id 1G3CS8-000Gq2-QD
	for netconf@ops.ietf.org; Wed, 19 Jul 2006 13:51:05 +0000
Received: from mlsv5.hitachi.co.jp (unknown [133.145.228.16])
	by mail4.hitachi.co.jp (Postfix) with ESMTP id BD02133CE1
	for <netconf@ops.ietf.org>; Wed, 19 Jul 2006 22:51:02 +0900 (JST)
Received: from mfilter-s5.hitachi.co.jp by mlsv5.hitachi.co.jp (8.12.10/8.12.10) id k6JDp2NW016592; Wed, 19 Jul 2006 22:51:02 +0900
Received: from navgw4.itg.hitachi.co.jp (unverified) by 
    mfilter-s5.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP 
    id <T799564ee5f0ac906b5da0@mfilter-s5.hitachi.co.jp> for 
    <netconf@ops.ietf.org>; Wed, 19 Jul 2006 22:51:02 +0900
Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by 
    navgw4.itg.hitachi.co.jp with SMTP id M2006071922510131620 for 
    <netconf@ops.ietf.org>; Wed, 19 Jul 2006 22:51:01 +0900
Received: from localhost by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) 
    id k6JDp1U3891402; Wed, 19 Jul 2006 22:51:02 +0900
Date: Wed, 19 Jul 2006 22:50:56 +0900 (JST)
Message-Id: <20060719.225056.100212048.hideki.okita.pf@hitachi.com>
To: netconf@ops.ietf.org
Subject: Confirmation of HTTPS use for the port 832
From: OKITA Hideki <hideki.okita.pf@hitachi.com>
Organization: Central Research Lab., Hitachi Ltd., Japan
X-Mailer: Mew version 5.1rc1 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: 82c9bddb247d9ba4471160a9a865a5f3

Dear all,


At the Montreal meeting, IANA-assigned ports are reported as following.

    netconf-ssh     830/tcp    NETCONF over SSH
    netconf-beep    831/tcp    NETCONF over BEEP 
    netconfsoaphttp 832/tcp    NETCONF for SOAP over HTTP
    netconfsoapbeep 833/tcp    NETCONF for SOAP over BEEP

I would like to confirm the following points.

- We use HTTPS rather than HTTP as the transport of NETCONF/SOAP/HTTP.
  (In ML, the word "SOAP/HTTPS" is always used.)

- We use same port 832 for HTTP, when there is some reason to use HTTP.


I concern that proto-12 and soap-08 draft are ambiguous about these points.
It seems that there is no sentence definitely specifying the use of HTTPS.
# Section 2.4 of soap-08 says "Use HTTPS" only.



To clarify the use of HTTPS, I suggest

1. to ask IANA to change the description of assigned port
   of NETCONF/SOAP/HTTP as following, if possible.

    netconfsoaphttps 832/tcp    NETCONF for SOAP over HTTPS
    netconfsoaphttps 832/udp    NETCONF for SOAP over HTTPS

2. to add the following sentence in the last of section 2.4 "BCP56:..."
   of soap-08 draft to avoid the anbiguity.

    "As these reasons, NETCONF system SHOULD use HTTPS
     when it use SOAP and HTTP as the transport."

   And, how about the following sentence in the last of section 4?

    "If there is some reason to use HTTP rather than HTTPS,
     the opeartor configures the NETCONF manager and devices
     to use HTTP on the IANA-assined port (832) for theier session"


Regards,


Hideki Okita
hideki.okita.pf@hitachi.com
Central Research Laboratory, Hitachi Ltd.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 19 12:40:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3F5c-0003Ja-Im
	for netconf-archive@lists.ietf.org; Wed, 19 Jul 2006 12:40:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G3F5b-000832-2M
	for netconf-archive@lists.ietf.org; Wed, 19 Jul 2006 12:40:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G3F1E-0008oP-KY
	for netconf-data@psg.com; Wed, 19 Jul 2006 16:35: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1G3F1B-0008nm-Hk
	for netconf@ops.ietf.org; Wed, 19 Jul 2006 16:35:25 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
	by mail2.sharplabs.com (Postfix) with ESMTP id 2C34A1E1361;
	Wed, 19 Jul 2006 09:35:25 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <NA4P7GQZ>; Wed, 19 Jul 2006 09:35:25 -0700
Message-ID: <789E617C880666438EDEE30C2A3E8D10EE81@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: 'OKITA Hideki' <hideki.okita.pf@hitachi.com>, netconf@ops.ietf.org
Subject: RE: Confirmation of HTTPS use for the port 832
Date: Wed, 19 Jul 2006 09:35:23 -0700
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

Hi,

A suggestion - use HTTP TLS Upgrade (RFC 2817) to allow
both plain HTTP and HTTP w/ TLS use over the same port,
as is the case with IPP/1.1 (RFC 2910/2911).

Trying to use HTTPS (where the TLS/SSL session starts
_before_ the first application message) and HTTP on the
same port is going to be hard to make interoperable.

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 OKITA Hideki
> Sent: Wednesday, July 19, 2006 9:51 AM
> To: netconf@ops.ietf.org
> Subject: Confirmation of HTTPS use for the port 832
> 
> 
> Dear all,
> 
> 
> At the Montreal meeting, IANA-assigned ports are reported as 
> following.
> 
>     netconf-ssh     830/tcp    NETCONF over SSH
>     netconf-beep    831/tcp    NETCONF over BEEP 
>     netconfsoaphttp 832/tcp    NETCONF for SOAP over HTTP
>     netconfsoapbeep 833/tcp    NETCONF for SOAP over BEEP
> 
> I would like to confirm the following points.
> 
> - We use HTTPS rather than HTTP as the transport of NETCONF/SOAP/HTTP.
>   (In ML, the word "SOAP/HTTPS" is always used.)
> 
> - We use same port 832 for HTTP, when there is some reason to 
> use HTTP.
> 
> 
> I concern that proto-12 and soap-08 draft are ambiguous about 
> these points.
> It seems that there is no sentence definitely specifying the 
> use of HTTPS.
> # Section 2.4 of soap-08 says "Use HTTPS" only.
> 
> 
> 
> To clarify the use of HTTPS, I suggest
> 
> 1. to ask IANA to change the description of assigned port
>    of NETCONF/SOAP/HTTP as following, if possible.
> 
>     netconfsoaphttps 832/tcp    NETCONF for SOAP over HTTPS
>     netconfsoaphttps 832/udp    NETCONF for SOAP over HTTPS
> 
> 2. to add the following sentence in the last of section 2.4 
> "BCP56:..."
>    of soap-08 draft to avoid the anbiguity.
> 
>     "As these reasons, NETCONF system SHOULD use HTTPS
>      when it use SOAP and HTTP as the transport."
> 
>    And, how about the following sentence in the last of section 4?
> 
>     "If there is some reason to use HTTP rather than HTTPS,
>      the opeartor configures the NETCONF manager and devices
>      to use HTTP on the IANA-assined port (832) for theier session"
> 
> 
> Regards,
> 
> 
> Hideki Okita
> hideki.okita.pf@hitachi.com
> Central Research Laboratory, Hitachi Ltd.
> 
> --
> to unsubscribe send a message to netconf-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 outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/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 Thu Jul 20 09:53:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3Yxj-00048j-JJ
	for netconf-archive@lists.ietf.org; Thu, 20 Jul 2006 09:53:11 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G3Yll-0000Et-Jt
	for netconf-archive@lists.ietf.org; Thu, 20 Jul 2006 09:40:50 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G3YbJ-0004s9-4f
	for netconf-data@psg.com; Thu, 20 Jul 2006 13:30: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,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1G3YbI-0004rh-09
	for netconf@ops.ietf.org; Thu, 20 Jul 2006 13:30:00 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k6KDTw6I017375
	for <netconf@ops.ietf.org>; Thu, 20 Jul 2006 09:29:59 -0400
Received: (qmail 3822 invoked by uid 78); 20 Jul 2006 13:29:58 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 20 Jul 2006 13:29:58 -0000
Message-ID: <44BF85CA.2090601@andybierman.com>
Date: Thu, 20 Jul 2006 06:31:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Netconf Data Model Discussion <netconfmodel@lists.nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Open Call to NETCONF Data Modelling Design Teams
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,

Dan, Simon, and I have crafted a mission statement for a design team,
except we decided not to run an official design team.  Instead, we are
issuing an Open Call to anyone who wants to write a draft in response
to these 3 challenges:

   Determine the best way to leverage the SMI/SNMP/SYSLOG experience
   we have in the IETF to create a simple, user-friendly,
   fully functional standards-based NM framework for the NETCONF protocol.

   Determine the best way to represent, organize, manage, and
   manipulate data models in a single vendor-extensible framework that
   allows for a "unified view" human API, even if there are N machine
   APIs as well (SNMP, NETCONF, SYSLOG, WEB, CLI).

   Determine the best way to migrate from proprietary-based configuration
   to standards-based configuration.


You can write whatever draft you want, at anytime, as always,
but these are the data modeling questions that the co-Chairs
and the AD are asking, in order to decide the best standards path
forward for netconf data modeling.


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 Thu Jul 20 19:16:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3hl0-0007SS-Tj
	for netconf-archive@lists.ietf.org; Thu, 20 Jul 2006 19:16:38 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G3hZo-0004VJ-Uy
	for netconf-archive@lists.ietf.org; Thu, 20 Jul 2006 19:05:06 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G3hTF-0007GO-LI
	for netconf-data@psg.com; Thu, 20 Jul 2006 22:58: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.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE 
	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 <cfinss@dial.pipex.com>)
	id 1G3hTE-0007Fx-Jb
	for netconf@ops.ietf.org; Thu, 20 Jul 2006 22:58:16 +0000
Received: from pc6 (1Cust234.tnt24.lnd4.gbr.da.uu.net [62.188.151.234])
	by ranger.systems.pipex.net (Postfix) with SMTP id 5C9D5E0004F9
	for <netconf@ops.ietf.org>; Thu, 20 Jul 2006 14:59:15 +0100 (BST)
Message-ID: <01f801c6abfb$add387a0$0601a8c0@pc6>
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
From: "tom.petch" <cfinss@dial.pipex.com>
To: <netconf@ops.ietf.org>
References: <20060717.193349.21925466.mbj@tail-f.com>
Subject: Notifications in opsec
Date: Thu, 20 Jul 2006 14:50:51 +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: 79899194edc4f33a41f49410777972f8

I came across
 draft-cain-logging-caps-00
and found it is actually all about notifications, written as part of opsec.  It
interests me because it gives an operator perspective, as opposed to a software
developper perspective, of what notifications are about.

As the name implies, it only considers the use of syslog, and that only in the
shape of [RFC3164] and [RFC3195].  I am surprised at the lack of reference to
SNMP, less so to syslog-sec or netconf.

But its existence does emphasise for me the importance of this topic (even if
the IETF does not quite know what to do with it:-)

Tom Petch


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 25 22:54:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5ZXO-0005KG-OJ
	for netconf-archive@lists.ietf.org; Tue, 25 Jul 2006 22:54:18 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G5ZXN-0007XB-9C
	for netconf-archive@lists.ietf.org; Tue, 25 Jul 2006 22:54:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G5ZQ4-0008gS-A5
	for netconf-data@psg.com; Wed, 26 Jul 2006 02:46:44 +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,HTML_MESSAGE 
	autolearn=ham version=3.1.1
Received: from [207.17.137.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1G5ZQ2-0008fw-Gn
	for netconf@ops.ietf.org; Wed, 26 Jul 2006 02:46:42 +0000
Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126])
  by kremlin.juniper.net with ESMTP; 25 Jul 2006 19:46:43 -0700
X-IronPort-AV: i="4.07,181,1151910000"; 
   d="scan'208,217"; a="565773057:sNHT72849380"
Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 25 Jul 2006 19:46:47 -0700
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_01C6B05D.BC89DD55"
Subject: Character encoding for Netconf messages?
Date: Tue, 25 Jul 2006 19:46:46 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E2537E@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Character encoding for Netconf messages?
Thread-Index: AcawXbxYJ2r/GLugQR6KgdU2Sg/m2w==
From: "Kent Watsen" <kwatsen@juniper.net>
To: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 26 Jul 2006 02:46:47.0361 (UTC) FILETIME=[BCDBDB10:01C6B05D]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121

This is a multi-part message in MIME format.

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

=20

The Netconf spec does not require XML declarations (i.e. <?xml
version=3D"1.0" encoding=3D"UTF-8" ?>).  However, both the SSH and SOAP
mapping specs show the use of XML declarations; though the BEEP mapping
spec does not... =20

=20

Should NetConf specify a mandatory encoding (e.g. USASCII) or leave it
up to implementations to decide?   If it is up to the implementations to
decide, then would that require the client to defer sending its <hello>
until after receiving the server's <hello> in order to determine the
encoding to use?

=20

Would it make sense for the <hello> to be USASCII and to list all
supported encodings as capabilities? - this seems flexible but then the
NetConf spec would need to require an XML declaration on every message

=20

Thanks!

Kent

=20

--

Kent Watsen

Software Architect

Juniper Networks

=20


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The Netconf spec does not require =
XML
declarations (i.e. &lt;?xml version=3D&quot;1.0&quot; =
encoding=3D&quot;UTF-8&quot;
?&gt;). &nbsp;However, both the SSH and SOAP mapping specs show the use =
of XML declarations;
though the BEEP mapping spec does not...&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Should NetConf specify a mandatory
encoding (e.g. USASCII) or leave it up to implementations to decide? =
&nbsp;&nbsp;If
it is up to the implementations to decide, then would that require the =
client
to defer sending its &lt;hello&gt; until after receiving the =
server&#8217;s
&lt;hello&gt; in order to determine the encoding to =
use?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Would it make sense for the =
&lt;hello&gt;
to be USASCII and to list all supported encodings as capabilities? =
&#8211; this
seems flexible but then the NetConf spec would need to require an XML
declaration on every message<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks!<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><st1:country-region w:st=3D"on"><st1:place =
w:st=3D"on"><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Kent</span></font></st1:place></st1:country-region><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>--<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Kent =
Watsen<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Software =
Architect<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Juniper =
Networks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6B05D.BC89DD55--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 26 18:46:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5s90-0000XX-15
	for netconf-archive@lists.ietf.org; Wed, 26 Jul 2006 18:46:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G5s8x-0008Q2-MJ
	for netconf-archive@lists.ietf.org; Wed, 26 Jul 2006 18:46:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G5s4U-000D65-9S
	for netconf-data@psg.com; Wed, 26 Jul 2006 22:41: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=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
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 1G5s4T-000D5k-GL
	for netconf@ops.ietf.org; Wed, 26 Jul 2006 22:41:41 +0000
Received: from h-68-165-5-186.snvacaid.dynamic.covad.net ([68.165.5.186] helo=oemcomputer)
	by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #1)
	id 1G5s4S-0000Uy-00
	for netconf@ops.ietf.org; Wed, 26 Jul 2006 18:41:40 -0400
Message-ID: <000901c6b104$d99bf4e0$6501a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netconf@ops.ietf.org>
References: <B8C821F9E0675D44BFA994C28C0120E5E2537E@antitop.jnpr.net>
Subject: Re: Character encoding for Netconf messages?
Date: Wed, 26 Jul 2006 15:43:00 -0700
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: f607d15ccc2bc4eaf3ade8ffa8af02a0

Hi -

If we specify a mandatory-to-implement encoding, I'd strongly suggest
that it be UTF-8.

Randy

----- Original Message ----- 
From: "Kent Watsen" <kwatsen@juniper.net>
To: <netconf@ops.ietf.org>
Sent: Tuesday, July 25, 2006 7:46 PM
Subject: Character encoding for Netconf messages?




The Netconf spec does not require XML declarations (i.e. <?xml
version="1.0" encoding="UTF-8" ?>).  However, both the SSH and SOAP
mapping specs show the use of XML declarations; though the BEEP mapping
spec does not...  

 

Should NetConf specify a mandatory encoding (e.g. USASCII) or leave it
up to implementations to decide?   If it is up to the implementations to
decide, then would that require the client to defer sending its <hello>
until after receiving the server's <hello> in order to determine the
encoding to use?

 

Would it make sense for the <hello> to be USASCII and to list all
supported encodings as capabilities? - this seems flexible but then the
NetConf spec would need to require an XML declaration on every message

 

Thanks!

Kent

 

--

Kent Watsen

Software 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 Wed Jul 26 18:58:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5sKt-0002a6-IH
	for netconf-archive@lists.ietf.org; Wed, 26 Jul 2006 18:58:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G5sKs-00025Z-83
	for netconf-archive@lists.ietf.org; Wed, 26 Jul 2006 18:58:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G5sIL-000F1D-GM
	for netconf-data@psg.com; Wed, 26 Jul 2006 22:56: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,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1G5sIK-000F11-E4
	for netconf@ops.ietf.org; Wed, 26 Jul 2006 22:56:00 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k6QMtxkM026301
	for <netconf@ops.ietf.org>; Wed, 26 Jul 2006 18:55:59 -0400
Received: (qmail 11155 invoked by uid 78); 26 Jul 2006 22:55:59 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 26 Jul 2006 22:55:59 -0000
Message-ID: <44C7F300.3020109@andybierman.com>
Date: Wed, 26 Jul 2006 15:56:00 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: netconf@ops.ietf.org
Subject: Re: Character encoding for Netconf messages?
References: <B8C821F9E0675D44BFA994C28C0120E5E2537E@antitop.jnpr.net> <000901c6b104$d99bf4e0$6501a8c0@oemcomputer>
In-Reply-To: <000901c6b104$d99bf4e0$6501a8c0@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: b280b4db656c3ca28dd62e5e0b03daa8

Randy Presuhn wrote:
> Hi -
> 
> If we specify a mandatory-to-implement encoding, I'd strongly suggest
> that it be UTF-8.
> 

Excellent topic for a VERY TBD WG work item!!!  :-)

(I agree with you, but I'm coding for internationalization.)

That's not an easy decision, or one that should be made
as part of some ad-hoc design process.


> Randy

Andy


> 
> ----- Original Message ----- 
> From: "Kent Watsen" <kwatsen@juniper.net>
> To: <netconf@ops.ietf.org>
> Sent: Tuesday, July 25, 2006 7:46 PM
> Subject: Character encoding for Netconf messages?
> 
> 
> 
> 
> The Netconf spec does not require XML declarations (i.e. <?xml
> version="1.0" encoding="UTF-8" ?>).  However, both the SSH and SOAP
> mapping specs show the use of XML declarations; though the BEEP mapping
> spec does not...  
> 
>  
> 
> Should NetConf specify a mandatory encoding (e.g. USASCII) or leave it
> up to implementations to decide?   If it is up to the implementations to
> decide, then would that require the client to defer sending its <hello>
> until after receiving the server's <hello> in order to determine the
> encoding to use?
> 
>  
> 
> Would it make sense for the <hello> to be USASCII and to list all
> supported encodings as capabilities? - this seems flexible but then the
> NetConf spec would need to require an XML declaration on every message
> 
>  
> 
> Thanks!
> 
> Kent
> 
>  
> 
> --
> 
> Kent Watsen
> 
> Software 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/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 27 07:24:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G63yl-0003X7-6t
	for netconf-archive@lists.ietf.org; Thu, 27 Jul 2006 07:24:35 -0400
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 1G62RK-0001Am-5Q
	for netconf-archive@lists.ietf.org; Thu, 27 Jul 2006 05:45:58 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1G62Fm-0006Vf-BS
	for netconf-archive@lists.ietf.org; Thu, 27 Jul 2006 05:34:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G62BP-0009em-NG
	for netconf-data@psg.com; Thu, 27 Jul 2006 09:29: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=BAYES_00,HTML_MESSAGE 
	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 <jfehrle@juniper.net>)
	id 1G5W0J-0007CG-7Q
	for netconf@ops.ietf.org; Tue, 25 Jul 2006 23:07:55 +0000
Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126])
  by borg.juniper.net with ESMTP; 25 Jul 2006 16:07:56 -0700
X-IronPort-AV: i="4.07,181,1151910000"; 
   d="scan'208,217"; a="571128744:sNHT71809728"
Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 25 Jul 2006 16:07:59 -0700
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_01C6B03F.2C07A621"
Subject: Character encoding for Netconf messages?
Date: Tue, 25 Jul 2006 16:07:59 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5FBF602@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Character encoding for Netconf messages?
Thread-Index: AcawPy4d2AnUYMA7TQGqstUxaHD6GA==
From: "Jim Fehrle" <jfehrle@juniper.net>
To: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 25 Jul 2006 23:07:59.0890 (UTC) FILETIME=[2C46BF20:01C6B03F]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B03F.2C07A621
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

How can an application determine what character set is being used

in Netconf messages?  Is this specified with an element like:

=20

<?xml version=3D"1.0" encoding=3D"UTF-8" ?>

=20

in each message, or can it be set once for the connection in the
<hello>?

=20

If UTF-8 isn't mandated, how can the application determine what encoding

the device can accept?  (aside from an error message for an unsupported
encoding)

=20

Jim Fehrle

Juniper Networks

=20

=20

=20


------_=_NextPart_001_01C6B03F.2C07A621
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>How can an application determine what character set =
is being
used<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>in Netconf messages?&nbsp; Is this specified with an =
element
like:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&lt;?xml =
version=3D&quot;1.0&quot;
encoding=3D&quot;UTF-8&quot; ?&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>in each message, or can it be set once for the =
connection in
the &lt;hello&gt;?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If UTF-8 isn&#8217;t mandated, how can the =
application
determine what encoding<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>the device can accept? &nbsp;(aside from an error =
message
for an unsupported encoding)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial'>Jim =
Fehrle</span></font></st1:PersonName><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Juniper Networks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6B03F.2C07A621--



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 27 16:36:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6Car-0001b1-H1
	for netconf-archive@lists.ietf.org; Thu, 27 Jul 2006 16:36:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G6Caq-0003MU-13
	for netconf-archive@lists.ietf.org; Thu, 27 Jul 2006 16:36:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G6CW2-0008Jb-Iw
	for netconf-data@psg.com; Thu, 27 Jul 2006 20:31: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,HTML_MESSAGE 
	autolearn=ham version=3.1.1
Received: from [207.17.137.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1G6CW1-0008JQ-Ue
	for netconf@ops.ietf.org; Thu, 27 Jul 2006 20:31:30 +0000
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
  by kremlin.juniper.net with ESMTP; 27 Jul 2006 13:31:31 -0700
X-IronPort-AV: i="4.07,189,1151910000"; 
   d="scan'208,217"; a="566308787:sNHT78639120"
Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 27 Jul 2006 13:31:35 -0700
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_01C6B1BB.A77E3BA6"
Subject: RE: Character encoding for Netconf messages?
Date: Thu, 27 Jul 2006 13:31:35 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E2538C@antitop.jnpr.net>
In-Reply-To: <B8C821F9E0675D44BFA994C28C0120E5FBF602@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Character encoding for Netconf messages?
Thread-Index: AcawPy4d2AnUYMA7TQGqstUxaHD6GABe7lhw
From: "Kent Watsen" <kwatsen@juniper.net>
To: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 27 Jul 2006 20:31:35.0903 (UTC) FILETIME=[A7CF76F0:01C6B1BB]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d

This is a multi-part message in MIME format.

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

Sorry, please ignore this message - it is an earlier version of the one
I sent out two days ago...

=20

Jim is my colleague and had some mailing-list subscription issue - he
didn't mean to send this out

=20

Thanks,

Kent

=20

=20

________________________________

From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Jim Fehrle
Sent: Tuesday, July 25, 2006 4:08 PM
To: netconf@ops.ietf.org
Subject: Character encoding for Netconf messages?

=20

How can an application determine what character set is being used

in Netconf messages?  Is this specified with an element like:

=20

<?xml version=3D"1.0" encoding=3D"UTF-8" ?>

=20

in each message, or can it be set once for the connection in the
<hello>?

=20

If UTF-8 isn't mandated, how can the application determine what encoding

the device can accept?  (aside from an error message for an unsupported
encoding)

=20

Jim Fehrle

Juniper Networks

=20

=20

=20


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Sorry, please ignore this message =
&#8211;
it is an earlier version of the one I sent out two days =
ago...<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Jim is my colleague and had some
mailing-list subscription issue &#8211; he didn&#8217;t mean to send =
this out<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:country-region =
w:st=3D"on"><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Kent</span></font></st1:country-region></st1:place><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Jim Fehrle<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 25, =
2006 4:08
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
netconf@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Character =
encoding for
Netconf messages?</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>How can an application determine what character set =
is being
used<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>in Netconf messages?&nbsp; Is this specified with an =
element
like:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&lt;?xml =
version=3D&quot;1.0&quot;
encoding=3D&quot;UTF-8&quot; ?&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>in each message, or can it be set once for the =
connection in
the &lt;hello&gt;?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If UTF-8 isn&#8217;t mandated, how can the =
application
determine what encoding<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>the device can accept? &nbsp;(aside from an error =
message
for an unsupported encoding)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial'>Jim =
Fehrle</span></font></st1:PersonName><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Juniper Networks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6B1BB.A77E3BA6--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 Jul 29 14:08:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6tEI-0004IP-8P
	for netconf-archive@lists.ietf.org; Sat, 29 Jul 2006 14:08:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G6tEG-0002sd-QX
	for netconf-archive@lists.ietf.org; Sat, 29 Jul 2006 14:08:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1G6t8y-000PGB-7a
	for netconf-data@psg.com; Sat, 29 Jul 2006 18:02: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=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1G6t8u-000PFs-Ot
	for netconf@ops.ietf.org; Sat, 29 Jul 2006 18:02:28 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
	by mail2.sharplabs.com (Postfix) with ESMTP id 9F8461E14A0;
	Sat, 29 Jul 2006 11:02:23 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72)
	id <PXBCPWQA>; Sat, 29 Jul 2006 11:02:23 -0700
Message-ID: <789E617C880666438EDEE30C2A3E8D10EE92@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: 'Andy Bierman' <ietf@andybierman.com>, Randy Presuhn
	 <randy_presuhn@mindspring.com>
Cc: netconf@ops.ietf.org
Subject: RE: Character encoding for Netconf messages?
Date: Sat, 29 Jul 2006 11:02:17 -0700
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: 789c141a303c09204b537a4078e2a63f

Hi,

The IESG policy on charsets has been stable for years,
since publication of BCP 18/RFC 2277 (January 1998).
Verbatim from section 3.1 'What charset to use':

  "All protocols MUST identify, for all character data, which charset is
   in use.

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track."

So, either an IETF standards-track protocol MUST only support
UTF-8 (so that tagging is irrelevant over the wire) or it MUST
always tag the charset in use in every over-the-wire message.

If Netconf permits the use of UTF-16 over the wire without an
'encoding' attribute in the XML declaration, then Netconf needs
a variance - not easy to get.

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, July 26, 2006 6:56 PM
> To: Randy Presuhn
> Cc: netconf@ops.ietf.org
> Subject: Re: Character encoding for Netconf messages?
> 
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> > If we specify a mandatory-to-implement encoding, I'd 
> strongly suggest
> > that it be UTF-8.
> > 
> 
> Excellent topic for a VERY TBD WG work item!!!  :-)
> 
> (I agree with you, but I'm coding for internationalization.)
> 
> That's not an easy decision, or one that should be made
> as part of some ad-hoc design process.
> 
> 
> > Randy
> 
> Andy
> 
> 
> > 
> > ----- Original Message ----- 
> > From: "Kent Watsen" <kwatsen@juniper.net>
> > To: <netconf@ops.ietf.org>
> > Sent: Tuesday, July 25, 2006 7:46 PM
> > Subject: Character encoding for Netconf messages?
> > 
> > 
> > 
> > 
> > The Netconf spec does not require XML declarations (i.e. <?xml
> > version="1.0" encoding="UTF-8" ?>).  However, both the SSH and SOAP
> > mapping specs show the use of XML declarations; though the 
> BEEP mapping
> > spec does not...  
> > 
> >  
> > 
> > Should NetConf specify a mandatory encoding (e.g. USASCII) 
> or leave it
> > up to implementations to decide?   If it is up to the 
> implementations to
> > decide, then would that require the client to defer sending 
> its <hello>
> > until after receiving the server's <hello> in order to determine the
> > encoding to use?
> > 
> >  
> > 
> > Would it make sense for the <hello> to be USASCII and to list all
> > supported encodings as capabilities? - this seems flexible 
> but then the
> > NetConf spec would need to require an XML declaration on 
> every message
> > 
> >  
> > 
> > Thanks!
> > 
> > Kent
> > 
> >  
> > 
> > --
> > 
> > Kent Watsen
> > 
> > Software 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/>
> > 
> > 
> 
> 
> --
> to unsubscribe send a message to netconf-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 outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 7/28/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/>