From owner-netconf@ops.ietf.org Wed May 02 12:54:02 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HjI5a-0007dY-2x
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 12:54:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HjI5Y-00063d-In
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 12:54:02 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HjHyh-0009U7-3D
	for netconf-data@psg.com; Wed, 02 May 2007 16:46:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HjHyd-0009Tl-Qf
	for netconf@ops.ietf.org; Wed, 02 May 2007 16:46:53 +0000
Received: (qmail 90043 invoked from network); 2 May 2007 16:46:51 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp107.sbc.mail.mud.yahoo.com with SMTP; 2 May 2007 16:46:50 -0000
X-YMail-OSG: DoEhmosVM1n622XMV6I50cZb5YCVuB_XUgnL6VYcp8h7S95EkttAWoCrYR7xH8bqnY2gM66q3zFq2OWS3ajxdKjOYtjyJkEMFkp_
Message-ID: <4638C056.5000608@andybierman.com>
Date: Wed, 02 May 2007 09:46:14 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Notification data model structure
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610

Hi,

I want to propose a minor change to the 'state' data models
in the Notifications draft, and some XSD improvements.

Currently, the 'eventStreams', 'namedProfile', and 'namedProfiles'
elements are all top-level elements in the MIB.
(I call the conceptual data under the <config> node the NETCONF MIB.)

I think this is a really bad idea.
We will probably be adding lots of elements over time, and some thought
needs to go into the data organization.

I am proposing that a top-level element called 'netconf' be added.
The 'eventStreams' and 'namedProfiles' elements will be child nodes
of 'netconf'. The 'namedProfile' element will be a child node of 'namedProfiles',
as intended.

Over time, the ability to retrieve all the data
related to the NETCONF protocol itself with the simple filter "<netconf/>"
will become obvious, if it isn't already.  The namespace ID
could be 'netmod'.  I don't know the XSD details involved,
but an element called 'netconf' of type 'any' seems possible.

The XSD should be redone so that the table 'row' structs are
defines as <complexTypes> instead of unnamed types within an <element>.
I think the following version of the XSD is easier to understand,
and reflects the intended data structures more correctly.


Andy

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

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
     xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:event:1.0"
     targetNamespace="urn:ietf:params:xml:ns:netmod:event:1.0"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
     <xs:annotation>
         <xs:documentation xml:lang="en">
             A schema that can be used to learn about current
             event streams and to manage named profiles.
         </xs:documentation>
     </xs:annotation>


   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
         schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
         schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
   <xs:import
         namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
         schemaLocation=
         "urn:ietf:params:xml:ns:netconf:notification:1.0"/>

  <xs:complexType name="EventStream">
    <xs:annotation>
      <xs:documentation>
        Stream name and description
       </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="description" type="xs:string"/>
      <xs:element name="replaySupport" type="xs:boolean"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="EventStreams">
    <xs:annotation>
      <xs:documentation>
        The list of event streams supported by the system.
        When a query is issued, the returned set of streams is
        determined based on user privileges
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name="stream" type="EventStream" minOccurs="0"
          maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="NamedProfile">
    <xs:annotation>
      <xs:documentation>
        A named profile, which is a saved set of parameters
        associated that may be associated with zero or more
        active subscriptions.

        This object can be created, read, deleted and its
        individual components can be modified.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name="name">
         <xs:annotation>
           <xs:documentation>
              The name associated with the profile.

              This object is readable and modifiable.
           </xs:documentation>
          </xs:annotation>
       </xs:element>

       <xs:element name="stream"  minOccurs="0">
         <xs:annotation>
           <xs:documentation xml:lang="en">
               The event stream associated with this named
               profile.

               This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="filter"
          type="netconf:filterInlineType"  minOccurs="0">
         <xs:annotation>
           <xs:documentation xml:lang="en">
              The filters associated with this named profile.
              This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="lastModified" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>
              The timestamp of the last modification to this
              named Profile. Note that modification of the
              profile does not cause an immediate update
              to all applicable subscription. Therefore,
              this time should be compared with the last
              modified time associated with the
              subscription. If this time is earlier, then
              the subscription is using the exact set of
              parameters associated with this named profile.
              If this time is later, then the subscription
              is using an earlier version of this named
              profile and the exact parameters may not
              match.

              This object is read-only.
            </xs:documentation>
          </xs:annotation>
        </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="NamedProfiles">
     <xs:annotation>
       <xs:documentation>
         The list of named profiles configured on the system.
       </xs:documentation>
     </xs:annotation>
     <xs:sequence>
       <xs:element name="namedProfile" type="NamedProfile"
           minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <xs:element name="eventStreams" type="EventStreams"/>

   <xs:element name="namedProfiles" type="NamedProfiles"/>

</xs:schema>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 02 15:11:12 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HjKEK-0003AP-2s
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 15:11:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HjKBV-0005bx-SR
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 15:08:18 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HjK6V-0005ja-U5
	for netconf-data@psg.com; Wed, 02 May 2007 19:03:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.63 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1HjK6S-0005jB-79
	for netconf@ops.ietf.org; Wed, 02 May 2007 19:03:06 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l42J2wq06330
	for <netconf@ops.ietf.org>; Wed, 2 May 2007 19:02:58 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification data model structure
Date: Wed, 2 May 2007 15:02:44 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40ECCB530@zcarhxm2.corp.nortel.com>
In-Reply-To: <4638C056.5000608@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification data model structure
Thread-Index: AceM2svj2TemBmuRSaCIAGxs/ccDxQAEJynQ
References: <4638C056.5000608@andybierman.com>
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: 612a16ba5c5f570bfc42b3ac5606ac53

Hi

I was getting ready to press send on the update ...

I can easily enough add a <netconf> wrapper to the content schema in
this draft. I guess then in theory we would then define the monitoring
information in
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-monitoring-00
.txt to extend that object.=20

I'm not sure what the procedure is for making these sort of changes post
working group last call.

For the second issue, this seems more subjective. Do we expect people
will use these complex types?

Sharon



-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, May 02, 2007 12:46 PM
To: Netconf (E-mail)
Subject: Notification data model structure

Hi,

I want to propose a minor change to the 'state' data models in the
Notifications draft, and some XSD improvements.

Currently, the 'eventStreams', 'namedProfile', and 'namedProfiles'
elements are all top-level elements in the MIB.
(I call the conceptual data under the <config> node the NETCONF MIB.)

I think this is a really bad idea.
We will probably be adding lots of elements over time, and some thought
needs to go into the data organization.

I am proposing that a top-level element called 'netconf' be added.
The 'eventStreams' and 'namedProfiles' elements will be child nodes of
'netconf'. The 'namedProfile' element will be a child node of
'namedProfiles', as intended.

Over time, the ability to retrieve all the data related to the NETCONF
protocol itself with the simple filter "<netconf/>"
will become obvious, if it isn't already.  The namespace ID could be
'netmod'.  I don't know the XSD details involved, but an element called
'netconf' of type 'any' seems possible.

The XSD should be redone so that the table 'row' structs are defines as
<complexTypes> instead of unnamed types within an <element>.
I think the following version of the XSD is easier to understand, and
reflects the intended data structures more correctly.


Andy

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

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
     xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ncEvent=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"
     xmlns:manageEvent=3D"urn:ietf:params:xml:ns:netmod:event:1.0"
     targetNamespace=3D"urn:ietf:params:xml:ns:netmod:event:1.0"
     elementFormDefault=3D"qualified"
     attributeFormDefault=3D"unqualified">
     <xs:annotation>
         <xs:documentation xml:lang=3D"en">
             A schema that can be used to learn about current
             event streams and to manage named profiles.
         </xs:documentation>
     </xs:annotation>


   <xs:import namespace=3D"http://www.w3.org/XML/1998/namespace"
         schemaLocation=3D"http://www.w3.org/2001/xml.xsd"/>
   <xs:import namespace=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
         schemaLocation=3D"urn:ietf:params:xml:ns:netconf:base:1.0"/>
   <xs:import
         namespace=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"
         schemaLocation=3D
         "urn:ietf:params:xml:ns:netconf:notification:1.0"/>

  <xs:complexType name=3D"EventStream">
    <xs:annotation>
      <xs:documentation>
        Stream name and description
       </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name=3D"name" type=3D"xs:string"/>
      <xs:element name=3D"description" type=3D"xs:string"/>
      <xs:element name=3D"replaySupport" type=3D"xs:boolean"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name=3D"EventStreams">
    <xs:annotation>
      <xs:documentation>
        The list of event streams supported by the system.
        When a query is issued, the returned set of streams is
        determined based on user privileges
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name=3D"stream" type=3D"EventStream" minOccurs=3D"0"
          maxOccurs=3D"unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name=3D"NamedProfile">
    <xs:annotation>
      <xs:documentation>
        A named profile, which is a saved set of parameters
        associated that may be associated with zero or more
        active subscriptions.

        This object can be created, read, deleted and its
        individual components can be modified.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name=3D"name">
         <xs:annotation>
           <xs:documentation>
              The name associated with the profile.

              This object is readable and modifiable.
           </xs:documentation>
          </xs:annotation>
       </xs:element>

       <xs:element name=3D"stream"  minOccurs=3D"0">
         <xs:annotation>
           <xs:documentation xml:lang=3D"en">
               The event stream associated with this named
               profile.

               This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name=3D"filter"
          type=3D"netconf:filterInlineType"  minOccurs=3D"0">
         <xs:annotation>
           <xs:documentation xml:lang=3D"en">
              The filters associated with this named profile.
              This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name=3D"lastModified" type=3D"xs:dateTime">
         <xs:annotation>
           <xs:documentation>
              The timestamp of the last modification to this
              named Profile. Note that modification of the
              profile does not cause an immediate update
              to all applicable subscription. Therefore,
              this time should be compared with the last
              modified time associated with the
              subscription. If this time is earlier, then
              the subscription is using the exact set of
              parameters associated with this named profile.
              If this time is later, then the subscription
              is using an earlier version of this named
              profile and the exact parameters may not
              match.

              This object is read-only.
            </xs:documentation>
          </xs:annotation>
        </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name=3D"NamedProfiles">
     <xs:annotation>
       <xs:documentation>
         The list of named profiles configured on the system.
       </xs:documentation>
     </xs:annotation>
     <xs:sequence>
       <xs:element name=3D"namedProfile" type=3D"NamedProfile"
           minOccurs=3D"0" maxOccurs=3D"unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <xs:element name=3D"eventStreams" type=3D"EventStreams"/>

   <xs:element name=3D"namedProfiles" type=3D"NamedProfiles"/>

</xs:schema>


--
to unsubscribe send a message to netconf-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 May 02 15:18:03 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HjKKx-0006DL-Hb
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 15:18:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HjKKw-0007A5-Sm
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 15:18:03 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HjKGm-0007Tt-Jf
	for netconf-data@psg.com; Wed, 02 May 2007 19:13:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.203] (helo=smtp104.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HjKGi-0007TJ-Gu
	for netconf@ops.ietf.org; Wed, 02 May 2007 19:13:42 +0000
Received: (qmail 14968 invoked from network); 2 May 2007 19:13:39 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp104.sbc.mail.mud.yahoo.com with SMTP; 2 May 2007 19:13:39 -0000
X-YMail-OSG: gjt2LF8VM1ngKzangLyFKJoNK89zkXvhisVYiEf9jy_ZWqRzjTUn6ukQotFEpX725elS5oh1i28ebZizIyFx8TKiVsz03wnkaMkk
Message-ID: <4638E2C0.8040106@andybierman.com>
Date: Wed, 02 May 2007 12:13:04 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification data model structure
References: <4638C056.5000608@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40ECCB530@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40ECCB530@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771

Sharon Chisholm wrote:
> Hi
> 
> I was getting ready to press send on the update ...
> 
> I can easily enough add a <netconf> wrapper to the content schema in
> this draft. I guess then in theory we would then define the monitoring
> information in
> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-monitoring-00
> .txt to extend that object. 
> 
> I'm not sure what the procedure is for making these sort of changes post
> working group last call.
> 
> For the second issue, this seems more subjective. Do we expect people
> will use these complex types?
> 

IMO, it makes the XSD easier to read, but more importantly,
it allows vendors (or even the IETF) to define proper extensions
or restrictions in their schemas.

> Sharon

Andy


> 
> 
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Wednesday, May 02, 2007 12:46 PM
> To: Netconf (E-mail)
> Subject: Notification data model structure
> 
> Hi,
> 
> I want to propose a minor change to the 'state' data models in the
> Notifications draft, and some XSD improvements.
> 
> Currently, the 'eventStreams', 'namedProfile', and 'namedProfiles'
> elements are all top-level elements in the MIB.
> (I call the conceptual data under the <config> node the NETCONF MIB.)
> 
> I think this is a really bad idea.
> We will probably be adding lots of elements over time, and some thought
> needs to go into the data organization.
> 
> I am proposing that a top-level element called 'netconf' be added.
> The 'eventStreams' and 'namedProfiles' elements will be child nodes of
> 'netconf'. The 'namedProfile' element will be a child node of
> 'namedProfiles', as intended.
> 
> Over time, the ability to retrieve all the data related to the NETCONF
> protocol itself with the simple filter "<netconf/>"
> will become obvious, if it isn't already.  The namespace ID could be
> 'netmod'.  I don't know the XSD details involved, but an element called
> 'netconf' of type 'any' seems possible.
> 
> The XSD should be redone so that the table 'row' structs are defines as
> <complexTypes> instead of unnamed types within an <element>.
> I think the following version of the XSD is easier to understand, and
> reflects the intended data structures more correctly.
> 
> 
> Andy
> 
> ------------------------------------------------------------------------
> -----
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>      xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
>      xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
>      xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:event:1.0"
>      targetNamespace="urn:ietf:params:xml:ns:netmod:event:1.0"
>      elementFormDefault="qualified"
>      attributeFormDefault="unqualified">
>      <xs:annotation>
>          <xs:documentation xml:lang="en">
>              A schema that can be used to learn about current
>              event streams and to manage named profiles.
>          </xs:documentation>
>      </xs:annotation>
> 
> 
>    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
>          schemaLocation="http://www.w3.org/2001/xml.xsd"/>
>    <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
>          schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
>    <xs:import
>          namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
>          schemaLocation=
>          "urn:ietf:params:xml:ns:netconf:notification:1.0"/>
> 
>   <xs:complexType name="EventStream">
>     <xs:annotation>
>       <xs:documentation>
>         Stream name and description
>        </xs:documentation>
>     </xs:annotation>
>     <xs:sequence>
>       <xs:element name="name" type="xs:string"/>
>       <xs:element name="description" type="xs:string"/>
>       <xs:element name="replaySupport" type="xs:boolean"/>
>     </xs:sequence>
>   </xs:complexType>
> 
>   <xs:complexType name="EventStreams">
>     <xs:annotation>
>       <xs:documentation>
>         The list of event streams supported by the system.
>         When a query is issued, the returned set of streams is
>         determined based on user privileges
>       </xs:documentation>
>     </xs:annotation>
>     <xs:sequence>
>        <xs:element name="stream" type="EventStream" minOccurs="0"
>           maxOccurs="unbounded"/>
>     </xs:sequence>
>   </xs:complexType>
> 
>   <xs:complexType name="NamedProfile">
>     <xs:annotation>
>       <xs:documentation>
>         A named profile, which is a saved set of parameters
>         associated that may be associated with zero or more
>         active subscriptions.
> 
>         This object can be created, read, deleted and its
>         individual components can be modified.
>       </xs:documentation>
>     </xs:annotation>
>     <xs:sequence>
>        <xs:element name="name">
>          <xs:annotation>
>            <xs:documentation>
>               The name associated with the profile.
> 
>               This object is readable and modifiable.
>            </xs:documentation>
>           </xs:annotation>
>        </xs:element>
> 
>        <xs:element name="stream"  minOccurs="0">
>          <xs:annotation>
>            <xs:documentation xml:lang="en">
>                The event stream associated with this named
>                profile.
> 
>                This object is readable and modifiable.
>            </xs:documentation>
>          </xs:annotation>
>        </xs:element>
> 
>        <xs:element name="filter"
>           type="netconf:filterInlineType"  minOccurs="0">
>          <xs:annotation>
>            <xs:documentation xml:lang="en">
>               The filters associated with this named profile.
>               This object is readable and modifiable.
>            </xs:documentation>
>          </xs:annotation>
>        </xs:element>
> 
>        <xs:element name="lastModified" type="xs:dateTime">
>          <xs:annotation>
>            <xs:documentation>
>               The timestamp of the last modification to this
>               named Profile. Note that modification of the
>               profile does not cause an immediate update
>               to all applicable subscription. Therefore,
>               this time should be compared with the last
>               modified time associated with the
>               subscription. If this time is earlier, then
>               the subscription is using the exact set of
>               parameters associated with this named profile.
>               If this time is later, then the subscription
>               is using an earlier version of this named
>               profile and the exact parameters may not
>               match.
> 
>               This object is read-only.
>             </xs:documentation>
>           </xs:annotation>
>         </xs:element>
>      </xs:sequence>
>    </xs:complexType>
> 
>    <xs:complexType name="NamedProfiles">
>      <xs:annotation>
>        <xs:documentation>
>          The list of named profiles configured on the system.
>        </xs:documentation>
>      </xs:annotation>
>      <xs:sequence>
>        <xs:element name="namedProfile" type="NamedProfile"
>            minOccurs="0" maxOccurs="unbounded"/>
>      </xs:sequence>
>    </xs:complexType>
> 
>    <xs:element name="eventStreams" type="EventStreams"/>
> 
>    <xs:element name="namedProfiles" type="NamedProfiles"/>
> 
> </xs:schema>
> 
> 
> --
> to unsubscribe send a message to netconf-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 May 02 16:44:12 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HjLgK-00008G-CE
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 16:44:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HjLgJ-0004MV-1N
	for netconf-archive@lists.ietf.org; Wed, 02 May 2007 16:44:12 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HjLcQ-000Pm3-NA
	for netconf-data@psg.com; Wed, 02 May 2007 20:40:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1HjLcM-000Pkd-OO
	for netconf@ops.ietf.org; Wed, 02 May 2007 20:40:09 +0000
Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51])
  by nj300815-nj-outbound.avaya.com with ESMTP; 02 May 2007 16:40:05 -0400
X-IronPort-AV: i="4.14,482,1170651600"; 
   d="scan'208"; a="10889596:sNHT7074924"
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: Notification data model structure
Date: Wed, 2 May 2007 23:39:43 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0CC41E02@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification data model structure
Thread-Index: AceM2svj2TemBmuRSaCIAGxs/ccDxQAEJynQAAON+AA=
References: <4638C056.5000608@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40ECCB530@zcarhxm2.corp.nortel.com>
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Sharon Chisholm" <schishol@nortel.com>,
	"Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081


In line.=20

Dan

=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, May 02, 2007 10:03 PM
> To: Netconf (E-mail)
> Subject: RE: Notification data model structure
>=20
> Hi
>=20
> I was getting ready to press send on the update ...
>=20
> I can easily enough add a <netconf> wrapper to the content=20
> schema in this draft. I guess then in theory we would then=20
> define the monitoring information in=20
> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-mon
> itoring-00
> .txt to extend that object.=20
>=20
> I'm not sure what the procedure is for making these sort of=20
> changes post working group last call.

The document is still in the WG hands, so you are allowed to do any
change you want. The chairs should establish the process to make sure
the changes enjoy the consensus of the WG (another LC, fast track LC,
question the list, etc.)

>=20
> For the second issue, this seems more subjective. Do we=20
> expect people will use these complex types?

I would say yes (contributor opinion)

>=20
> Sharon
>=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 May 03 11:20:26 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hjd6Y-0005bO-ID
	for netconf-archive@lists.ietf.org; Thu, 03 May 2007 11:20:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hjd6X-0003wa-4Z
	for netconf-archive@lists.ietf.org; Thu, 03 May 2007 11:20:26 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hjcz3-0005al-LI
	for netconf-data@psg.com; Thu, 03 May 2007 15:12:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1Hjcyz-0005aI-Jj
	for netconf@ops.ietf.org; Thu, 03 May 2007 15:12:39 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail2.sharplabs.com (Postfix) with ESMTP id 207E81E1346;
	Thu,  3 May 2007 08:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at sharplabs.com
Received: from mail2.sharplabs.com ([127.0.0.1])
	by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id KndzF3e3ysxq; Thu,  3 May 2007 08:12:34 -0700 (PDT)
Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8])
	by mail2.sharplabs.com (Postfix) with ESMTP id EAA541E12EB;
	Thu,  3 May 2007 08:12:33 -0700 (PDT)
Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 3 May 2007 08:12:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification data model structure
Date: Thu, 3 May 2007 08:12:33 -0700
Message-ID: <FCC7D7D1DB94054EB491EED9D274727D030EFB@wabex2.sharpamericas.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0CC41E02@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification data model structure
Thread-Index: AceM2svj2TemBmuRSaCIAGxs/ccDxQAEJynQAAON+AAAKPCukA==
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>,
	"Sharon Chisholm" <schishol@nortel.com>,
	"Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 03 May 2007 15:12:33.0770 (UTC) FILETIME=[79DFC4A0:01C78D95]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1

Hi,

As Andy just said, named complex types can have clean
vendor extensions - unnamed types require hacking the
schema - in IEEE-ISTO PWG standards we ONLY used named
types for every element, for that very reason.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
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 Romascanu, Dan (Dan)
Sent: Wednesday, May 02, 2007 3:40 PM
To: Sharon Chisholm; Netconf (E-mail)
Subject: RE: Notification data model structure



In line.=20

Dan

=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, May 02, 2007 10:03 PM
> To: Netconf (E-mail)
> Subject: RE: Notification data model structure
>=20
> Hi
>=20
> I was getting ready to press send on the update ...
>=20
> I can easily enough add a <netconf> wrapper to the content=20
> schema in this draft. I guess then in theory we would then=20
> define the monitoring information in=20
> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-mon
> itoring-00
> .txt to extend that object.=20
>=20
> I'm not sure what the procedure is for making these sort of=20
> changes post working group last call.

The document is still in the WG hands, so you are allowed to do any
change you want. The chairs should establish the process to make sure
the changes enjoy the consensus of the WG (another LC, fast track LC,
question the list, etc.)

>=20
> For the second issue, this seems more subjective. Do we=20
> expect people will use these complex types?

I would say yes (contributor opinion)

>=20
> Sharon
>=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/>

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.467 / Virus Database: 269.6.2/785 - Release Date: 5/2/2007 =
2:16 PM
=20

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



From owner-netconf@ops.ietf.org Fri May 04 20:26:44 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hk86m-0001mw-QK
	for netconf-archive@lists.ietf.org; Fri, 04 May 2007 20:26:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hk86l-0002h2-Fv
	for netconf-archive@lists.ietf.org; Fri, 04 May 2007 20:26:44 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hk808-000DhW-I9
	for netconf-data@psg.com; Sat, 05 May 2007 00:19:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.201] (helo=smtp102.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hk805-000DhE-Jm
	for netconf@ops.ietf.org; Sat, 05 May 2007 00:19:51 +0000
Received: (qmail 78439 invoked from network); 5 May 2007 00:19:45 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp102.sbc.mail.mud.yahoo.com with SMTP; 5 May 2007 00:19:44 -0000
X-YMail-OSG: DkBdqW4VM1mQNuQM.4rKBrFBAtqw1xkM9jdCt.bnFfuu99.s
Message-ID: <463BCD7C.6080207@andybierman.com>
Date: Fri, 04 May 2007 17:19:08 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Notification Schema Bug
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Hi,

The notification element definition is obsolete, based on the
decision to remove the parameters from the ReplayCompleteNotification.
There is no <data> element in the notification, like <rpc-reply>.
The <notification> element is a wrapper, just like the <rpc> element.
This allows proper extension by any organization.  The XSD for
the <notification> element must be done the same way as the <rpc> element.

Current text: notification-06: page 21:

     <xs:complexType name="NotificationType">
        <xs:sequence>
          <xs:element name="data" type="netconf:dataInlineType" />
        </xs:sequence>
     </xs:complexType>

     <xs:element name="notification" type="NotificationType"/>


Proposed replacement text for page 21:

     <xs:complexType name="NotificationContentType"/>

     <xs:element name="notificationContent"
                 type="NotificationContentType" abstract="true"/>

     <xs:complexType name="NotificationType">
       <xs:sequence>
         <xs:element ref="notificationContent"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name="notification" type="NotificationType"/>


The replayCompleteNotification can be defined in another XSD and namespace:

     <xs:complexType name="ReplayCompleteNotificationType">
       <xs:complexContent>
         <xs:extension base="NotificationContentType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="replayCompleteNotification"
                 type="ReplayCompleteNotificationType"
                 substitutionGroup="notificationContent"/>


Of course, a notification with parameters would not have an empty 
<extension>
like this one.


Andy





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



From owner-netconf@ops.ietf.org Sun May 06 13:22:28 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HkkRI-0005TT-Le
	for netconf-archive@lists.ietf.org; Sun, 06 May 2007 13:22:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HkkRH-0005Vj-A3
	for netconf-archive@lists.ietf.org; Sun, 06 May 2007 13:22:28 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HkkJs-0003a8-8c
	for netconf-data@psg.com; Sun, 06 May 2007 17:14:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.210] (helo=smtp111.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HkkJp-0003Zn-61
	for netconf@ops.ietf.org; Sun, 06 May 2007 17:14:47 +0000
Received: (qmail 54679 invoked from network); 6 May 2007 17:14:44 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp111.sbc.mail.mud.yahoo.com with SMTP; 6 May 2007 17:14:43 -0000
X-YMail-OSG: ezSYjcUVM1m7h9egY.FOMZAdXWi89.SGkEhWWqtj2D0KyHY2
Message-ID: <463E0CE0.6030409@andybierman.com>
Date: Sun, 06 May 2007 10:14:08 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: element naming style
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

Hi,

After thinking about it again, I believe the naming style
that Sharon proposed in Prague is the best compromise
between CLI and SMI naming styles.

Using cli-style-names for RPC operations and RPC parameters
and using smiStyleNames for data provides a visual hint
that these are different types of names, treated differently
in the protocol (and implementation).

I want to apologize to Sharon for making a big deal out of
element naming style at the WG meeting in Prague,
and not realizing she was right in the first place.

The current draft should be changed wrt/ 2 RPC parameters
in the <create-subscription> RPC method.  There is currently:
   stream
   filter
   named-profile
   startTime
   stopTime

I propose the following name changes, to improve consistency:

   startTime  --> start-time
   stopTime   --> stop-time


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 May 07 12:03:36 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl5gV-0002VD-E1
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 12:03:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl5gU-0003k0-3I
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 12:03:35 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl5YI-0004ms-1U
	for netconf-data@psg.com; Mon, 07 May 2007 15:55:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.63 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1Hl5YE-0004kz-HC
	for netconf@ops.ietf.org; Mon, 07 May 2007 15:55:04 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l47FswA13159
	for <netconf@ops.ietf.org>; Mon, 7 May 2007 15:54:58 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Schema Bug
Date: Mon, 7 May 2007 11:54:49 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com>
In-Reply-To: <463BCD7C.6080207@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Schema Bug
Thread-Index: AceOrEUECaI37XuCRdCI4M1jXQSr8gCE4KFA
References: <463BCD7C.6080207@andybierman.com>
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: c3a18ef96977fc9bcc21a621cbf1174b

Hi

If we go this way, we should also add a little note somewhere that
content defined as notifications can also be retrieved via the <get>
operation. This allows a single definition of content instead of forcing
everything to be defined twice like SNMP did. It becomes a little less
obvious when it is an extension of the notification.

Sharon=20

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 04, 2007 8:19 PM
To: Netconf (E-mail)
Subject: Notification Schema Bug

Hi,

The notification element definition is obsolete, based on the decision
to remove the parameters from the ReplayCompleteNotification.
There is no <data> element in the notification, like <rpc-reply>.
The <notification> element is a wrapper, just like the <rpc> element.
This allows proper extension by any organization.  The XSD for the
<notification> element must be done the same way as the <rpc> element.

Current text: notification-06: page 21:

     <xs:complexType name=3D"NotificationType">
        <xs:sequence>
          <xs:element name=3D"data" type=3D"netconf:dataInlineType" />
        </xs:sequence>
     </xs:complexType>

     <xs:element name=3D"notification" type=3D"NotificationType"/>


Proposed replacement text for page 21:

     <xs:complexType name=3D"NotificationContentType"/>

     <xs:element name=3D"notificationContent"
                 type=3D"NotificationContentType" abstract=3D"true"/>

     <xs:complexType name=3D"NotificationType">
       <xs:sequence>
         <xs:element ref=3D"notificationContent"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name=3D"notification" type=3D"NotificationType"/>


The replayCompleteNotification can be defined in another XSD and
namespace:

     <xs:complexType name=3D"ReplayCompleteNotificationType">
       <xs:complexContent>
         <xs:extension base=3D"NotificationContentType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name=3D"replayCompleteNotification"
                 type=3D"ReplayCompleteNotificationType"
                 substitutionGroup=3D"notificationContent"/>


Of course, a notification with parameters would not have an empty
<extension> like this one.


Andy





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

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



From owner-netconf@ops.ietf.org Mon May 07 13:02:35 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl6bb-0005Sv-KY
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 13:02:35 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl6bZ-0003YK-5z
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 13:02:35 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl6XL-0008u5-1s
	for netconf-data@psg.com; Mon, 07 May 2007 16:58:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.209] (helo=smtp110.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hl6XH-0008tn-KD
	for netconf@ops.ietf.org; Mon, 07 May 2007 16:58:09 +0000
Received: (qmail 21513 invoked from network); 7 May 2007 16:58:06 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp110.sbc.mail.mud.yahoo.com with SMTP; 7 May 2007 16:58:06 -0000
X-YMail-OSG: dnZPvwAVM1lEqwbjiST0fuR0HRvf0.x82CWQENeh4SjRTKBITcsu6yF72ksd5GrrzATd2JmNwNdjTnivG15HjgV5Uw--
Message-ID: <463F5A78.60402@andybierman.com>
Date: Mon, 07 May 2007 09:57:28 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Schema Bug
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e

Sharon Chisholm wrote:
> Hi
> 
> If we go this way, we should also add a little note somewhere that
> content defined as notifications can also be retrieved via the <get>
> operation. This allows a single definition of content instead of forcing
> everything to be defined twice like SNMP did. It becomes a little less
> obvious when it is an extension of the notification.
> 

I disagree.
This is outside the scope of this document, and part of
a Notification Logging MIB instead.  However, such a MIB
would be rather redundant, given the replay feature within
the notification draft.

If named complexTypes are used for the content, then the 'redundant'
element definitions (for <get> and <notification>) are trivial to write,
and the actual semantics are only defined once.


> Sharon

Andy

> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Friday, May 04, 2007 8:19 PM
> To: Netconf (E-mail)
> Subject: Notification Schema Bug
> 
> Hi,
> 
> The notification element definition is obsolete, based on the decision
> to remove the parameters from the ReplayCompleteNotification.
> There is no <data> element in the notification, like <rpc-reply>.
> The <notification> element is a wrapper, just like the <rpc> element.
> This allows proper extension by any organization.  The XSD for the
> <notification> element must be done the same way as the <rpc> element.
> 
> Current text: notification-06: page 21:
> 
>      <xs:complexType name="NotificationType">
>         <xs:sequence>
>           <xs:element name="data" type="netconf:dataInlineType" />
>         </xs:sequence>
>      </xs:complexType>
> 
>      <xs:element name="notification" type="NotificationType"/>
> 
> 
> Proposed replacement text for page 21:
> 
>      <xs:complexType name="NotificationContentType"/>
> 
>      <xs:element name="notificationContent"
>                  type="NotificationContentType" abstract="true"/>
> 
>      <xs:complexType name="NotificationType">
>        <xs:sequence>
>          <xs:element ref="notificationContent"/>
>        </xs:sequence>
>      </xs:complexType>
> 
>      <xs:element name="notification" type="NotificationType"/>
> 
> 
> The replayCompleteNotification can be defined in another XSD and
> namespace:
> 
>      <xs:complexType name="ReplayCompleteNotificationType">
>        <xs:complexContent>
>          <xs:extension base="NotificationContentType"/>
>        </xs:complexContent>
>      </xs:complexType>
> 
>      <xs:element name="replayCompleteNotification"
>                  type="ReplayCompleteNotificationType"
>                  substitutionGroup="notificationContent"/>
> 
> 
> Of course, a notification with parameters would not have an empty
> <extension> like this one.
> 
> 
> Andy
> 
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Mon May 07 13:40:32 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl7CK-0002mx-5b
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 13:40:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl7CJ-0003Gd-Nc
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 13:40:32 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl78U-000FtA-PB
	for netconf-data@psg.com; Mon, 07 May 2007 17:36:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.63 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1Hl78R-000Fsm-6P
	for netconf@ops.ietf.org; Mon, 07 May 2007 17:36:33 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l47HaQe05345;
	Mon, 7 May 2007 17:36:26 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Schema Bug
Date: Mon, 7 May 2007 13:36:16 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40EDD5EDF@zcarhxm2.corp.nortel.com>
In-Reply-To: <463F5A78.60402@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Schema Bug
Thread-Index: AceQyOaHxyqb+UTMQ92iDru7PlpMpgAAXS5g
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com> <463F5A78.60402@andybierman.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172

Hi

Notification logging isn't the use case I was referring to. Here are
some that have come up.

- An interface has changed notification where the same information is
sent via a <get> you get via a notification
- A configuration change entity which sends to snippet of configuration
that has changed (this case is a bit different)
- An list of alarms which can be queried to retrieve active ones, but
each individual alarm definition is actually what is sent over the wire.


These sort of cases were part of the reason the notification definitions
were not too tied to just notifications. Notification is an operation on
the data, so you don't want to limit the definition to just be able to
be sent via notifications.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Monday, May 07, 2007 12:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Netconf (E-mail)
Subject: Re: Notification Schema Bug

Sharon Chisholm wrote:
> Hi
>=20
> If we go this way, we should also add a little note somewhere that=20
> content defined as notifications can also be retrieved via the <get>=20
> operation. This allows a single definition of content instead of=20
> forcing everything to be defined twice like SNMP did. It becomes a=20
> little less obvious when it is an extension of the notification.
>=20

I disagree.
This is outside the scope of this document, and part of a Notification
Logging MIB instead.  However, such a MIB would be rather redundant,
given the replay feature within the notification draft.

If named complexTypes are used for the content, then the 'redundant'
element definitions (for <get> and <notification>) are trivial to write,
and the actual semantics are only defined once.


> Sharon

Andy

>=20
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20
> On Behalf Of Andy Bierman
> Sent: Friday, May 04, 2007 8:19 PM
> To: Netconf (E-mail)
> Subject: Notification Schema Bug
>=20
> Hi,
>=20
> The notification element definition is obsolete, based on the decision

> to remove the parameters from the ReplayCompleteNotification.
> There is no <data> element in the notification, like <rpc-reply>.
> The <notification> element is a wrapper, just like the <rpc> element.
> This allows proper extension by any organization.  The XSD for the=20
> <notification> element must be done the same way as the <rpc> element.
>=20
> Current text: notification-06: page 21:
>=20
>      <xs:complexType name=3D"NotificationType">
>         <xs:sequence>
>           <xs:element name=3D"data" type=3D"netconf:dataInlineType" />
>         </xs:sequence>
>      </xs:complexType>
>=20
>      <xs:element name=3D"notification" type=3D"NotificationType"/>
>=20
>=20
> Proposed replacement text for page 21:
>=20
>      <xs:complexType name=3D"NotificationContentType"/>
>=20
>      <xs:element name=3D"notificationContent"
>                  type=3D"NotificationContentType" abstract=3D"true"/>
>=20
>      <xs:complexType name=3D"NotificationType">
>        <xs:sequence>
>          <xs:element ref=3D"notificationContent"/>
>        </xs:sequence>
>      </xs:complexType>
>=20
>      <xs:element name=3D"notification" type=3D"NotificationType"/>
>=20
>=20
> The replayCompleteNotification can be defined in another XSD and
> namespace:
>=20
>      <xs:complexType name=3D"ReplayCompleteNotificationType">
>        <xs:complexContent>
>          <xs:extension base=3D"NotificationContentType"/>
>        </xs:complexContent>
>      </xs:complexType>
>=20
>      <xs:element name=3D"replayCompleteNotification"
>                  type=3D"ReplayCompleteNotificationType"
>                  substitutionGroup=3D"notificationContent"/>
>=20
>=20
> Of course, a notification with parameters would not have an empty=20
> <extension> like this one.
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the

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

> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=20
>=20


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



From owner-netconf@ops.ietf.org Mon May 07 14:01:03 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl7WB-00084V-PH
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 14:01:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl7WA-00031O-2g
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 14:01:03 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl7S3-000H64-4P
	for netconf-data@psg.com; Mon, 07 May 2007 17:56:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.205] (helo=smtp106.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hl7Rz-000H5f-NN
	for netconf@ops.ietf.org; Mon, 07 May 2007 17:56:45 +0000
Received: (qmail 96637 invoked from network); 7 May 2007 17:56:42 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp106.sbc.mail.mud.yahoo.com with SMTP; 7 May 2007 17:56:41 -0000
X-YMail-OSG: QI.dOp4VM1mZTUiDmU1ihETpeXDJpqBzGUPPt8wREvwpmdiYRXw0ugck_ZE0Wq7CUyyuTVMqF3e.EFZVcT4UKw_YfQ--
Message-ID: <463F6832.9060502@andybierman.com>
Date: Mon, 07 May 2007 10:56:02 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Schema Bug
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com> <463F5A78.60402@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5EDF@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40EDD5EDF@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48

Sharon Chisholm wrote:
> Hi
> 
> Notification logging isn't the use case I was referring to. Here are
> some that have come up.
> 
> - An interface has changed notification where the same information is
> sent via a <get> you get via a notification
> - A configuration change entity which sends to snippet of configuration
> that has changed (this case is a bit different)
> - An list of alarms which can be queried to retrieve active ones, but
> each individual alarm definition is actually what is sent over the wire.
> 
> 
> These sort of cases were part of the reason the notification definitions
> were not too tied to just notifications. Notification is an operation on
> the data, so you don't want to limit the definition to just be able to
> be sent via notifications.
> 

XSD works great for this use case.
1) Define the content (syntax and semantics) with a named type.
2) Define accessible elements as needed, in notification content,
    RPC parameter content, or data model content.

There is no reason to say anything in the protocol document
about how notification content can also be retrieved with
a <get> operation.

It is up to the vendor to add yet another stored notification
retrieval mechanism.  It is up to the vendor to decide what
data is retrievable with a <get> operation.


> Sharon

Andy

> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Monday, May 07, 2007 12:57 PM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: Netconf (E-mail)
> Subject: Re: Notification Schema Bug
> 
> Sharon Chisholm wrote:
>> Hi
>>
>> If we go this way, we should also add a little note somewhere that 
>> content defined as notifications can also be retrieved via the <get> 
>> operation. This allows a single definition of content instead of 
>> forcing everything to be defined twice like SNMP did. It becomes a 
>> little less obvious when it is an extension of the notification.
>>
> 
> I disagree.
> This is outside the scope of this document, and part of a Notification
> Logging MIB instead.  However, such a MIB would be rather redundant,
> given the replay feature within the notification draft.
> 
> If named complexTypes are used for the content, then the 'redundant'
> element definitions (for <get> and <notification>) are trivial to write,
> and the actual semantics are only defined once.
> 
> 
>> Sharon
> 
> Andy
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] 
>> On Behalf Of Andy Bierman
>> Sent: Friday, May 04, 2007 8:19 PM
>> To: Netconf (E-mail)
>> Subject: Notification Schema Bug
>>
>> Hi,
>>
>> The notification element definition is obsolete, based on the decision
> 
>> to remove the parameters from the ReplayCompleteNotification.
>> There is no <data> element in the notification, like <rpc-reply>.
>> The <notification> element is a wrapper, just like the <rpc> element.
>> This allows proper extension by any organization.  The XSD for the 
>> <notification> element must be done the same way as the <rpc> element.
>>
>> Current text: notification-06: page 21:
>>
>>      <xs:complexType name="NotificationType">
>>         <xs:sequence>
>>           <xs:element name="data" type="netconf:dataInlineType" />
>>         </xs:sequence>
>>      </xs:complexType>
>>
>>      <xs:element name="notification" type="NotificationType"/>
>>
>>
>> Proposed replacement text for page 21:
>>
>>      <xs:complexType name="NotificationContentType"/>
>>
>>      <xs:element name="notificationContent"
>>                  type="NotificationContentType" abstract="true"/>
>>
>>      <xs:complexType name="NotificationType">
>>        <xs:sequence>
>>          <xs:element ref="notificationContent"/>
>>        </xs:sequence>
>>      </xs:complexType>
>>
>>      <xs:element name="notification" type="NotificationType"/>
>>
>>
>> The replayCompleteNotification can be defined in another XSD and
>> namespace:
>>
>>      <xs:complexType name="ReplayCompleteNotificationType">
>>        <xs:complexContent>
>>          <xs:extension base="NotificationContentType"/>
>>        </xs:complexContent>
>>      </xs:complexType>
>>
>>      <xs:element name="replayCompleteNotification"
>>                  type="ReplayCompleteNotificationType"
>>                  substitutionGroup="notificationContent"/>
>>
>>
>> Of course, a notification with parameters would not have an empty 
>> <extension> like this one.
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> 
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> 
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Mon May 07 14:10:15 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl7f5-00026i-Hk
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 14:10:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl7f5-0005i4-1P
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 14:10:15 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl7bU-000HrA-Nd
	for netconf-data@psg.com; Mon, 07 May 2007 18:06:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.63 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1Hl7bQ-000Hq2-JF
	for netconf@ops.ietf.org; Mon, 07 May 2007 18:06:30 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l47I6Og29390
	for <netconf@ops.ietf.org>; Mon, 7 May 2007 18:06:25 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Schema Bug
Date: Mon, 7 May 2007 14:06:21 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40EDD5FB4@zcarhxm2.corp.nortel.com>
In-Reply-To: <463F6832.9060502@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Schema Bug
Thread-Index: AceQ0RaJHFVVkyosQaGjMzk4ZoWdrgAAR1uw
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com> <463F5A78.60402@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5EDF@zcarhxm2.corp.nortel.com> <463F6832.9060502@andybierman.com>
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: a92270ba83d7ead10c5001bb42ec3221

 hi

I just want to make sure we are not setting a precedent with how
notifications are defined that would preclude the same information being
used for both, preferably without defining a complex type that gets used
in two places.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Monday, May 07, 2007 1:56 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Netconf (E-mail)
Subject: Re: Notification Schema Bug

Sharon Chisholm wrote:
> Hi
>=20
> Notification logging isn't the use case I was referring to. Here are=20
> some that have come up.
>=20
> - An interface has changed notification where the same information is=20
> sent via a <get> you get via a notification
> - A configuration change entity which sends to snippet of=20
> configuration that has changed (this case is a bit different)
> - An list of alarms which can be queried to retrieve active ones, but=20
> each individual alarm definition is actually what is sent over the
wire.
>=20
>=20
> These sort of cases were part of the reason the notification=20
> definitions were not too tied to just notifications. Notification is=20
> an operation on the data, so you don't want to limit the definition to

> just be able to be sent via notifications.
>=20

XSD works great for this use case.
1) Define the content (syntax and semantics) with a named type.
2) Define accessible elements as needed, in notification content,
    RPC parameter content, or data model content.

There is no reason to say anything in the protocol document about how
notification content can also be retrieved with a <get> operation.

It is up to the vendor to add yet another stored notification retrieval
mechanism.  It is up to the vendor to decide what data is retrievable
with a <get> operation.


> Sharon

Andy

>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Monday, May 07, 2007 12:57 PM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: Netconf (E-mail)
> Subject: Re: Notification Schema Bug
>=20
> Sharon Chisholm wrote:
>> Hi
>>
>> If we go this way, we should also add a little note somewhere that=20
>> content defined as notifications can also be retrieved via the <get>=20
>> operation. This allows a single definition of content instead of=20
>> forcing everything to be defined twice like SNMP did. It becomes a=20
>> little less obvious when it is an extension of the notification.
>>
>=20
> I disagree.
> This is outside the scope of this document, and part of a Notification

> Logging MIB instead.  However, such a MIB would be rather redundant,=20
> given the replay feature within the notification draft.
>=20
> If named complexTypes are used for the content, then the 'redundant'
> element definitions (for <get> and <notification>) are trivial to=20
> write, and the actual semantics are only defined once.
>=20
>=20
>> Sharon
>=20
> Andy
>=20
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
>> On Behalf Of Andy Bierman
>> Sent: Friday, May 04, 2007 8:19 PM
>> To: Netconf (E-mail)
>> Subject: Notification Schema Bug
>>
>> Hi,
>>
>> The notification element definition is obsolete, based on the=20
>> decision
>=20
>> to remove the parameters from the ReplayCompleteNotification.
>> There is no <data> element in the notification, like <rpc-reply>.
>> The <notification> element is a wrapper, just like the <rpc> element.
>> This allows proper extension by any organization.  The XSD for the=20
>> <notification> element must be done the same way as the <rpc>
element.
>>
>> Current text: notification-06: page 21:
>>
>>      <xs:complexType name=3D"NotificationType">
>>         <xs:sequence>
>>           <xs:element name=3D"data" type=3D"netconf:dataInlineType" =
/>
>>         </xs:sequence>
>>      </xs:complexType>
>>
>>      <xs:element name=3D"notification" type=3D"NotificationType"/>
>>
>>
>> Proposed replacement text for page 21:
>>
>>      <xs:complexType name=3D"NotificationContentType"/>
>>
>>      <xs:element name=3D"notificationContent"
>>                  type=3D"NotificationContentType" abstract=3D"true"/>
>>
>>      <xs:complexType name=3D"NotificationType">
>>        <xs:sequence>
>>          <xs:element ref=3D"notificationContent"/>
>>        </xs:sequence>
>>      </xs:complexType>
>>
>>      <xs:element name=3D"notification" type=3D"NotificationType"/>
>>
>>
>> The replayCompleteNotification can be defined in another XSD and
>> namespace:
>>
>>      <xs:complexType name=3D"ReplayCompleteNotificationType">
>>        <xs:complexContent>
>>          <xs:extension base=3D"NotificationContentType"/>
>>        </xs:complexContent>
>>      </xs:complexType>
>>
>>      <xs:element name=3D"replayCompleteNotification"
>>                  type=3D"ReplayCompleteNotificationType"
>>                  substitutionGroup=3D"notificationContent"/>
>>
>>
>> Of course, a notification with parameters would not have an empty=20
>> <extension> like this one.
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
>> the
>=20
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with=20
>> the
>=20
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the

> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=20
>=20


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



From owner-netconf@ops.ietf.org Mon May 07 15:01:36 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hl8Sm-00012s-Eo
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 15:01:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hl8Sl-0002tH-UZ
	for netconf-archive@lists.ietf.org; Mon, 07 May 2007 15:01:36 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hl8Ns-000L2q-LP
	for netconf-data@psg.com; Mon, 07 May 2007 18:56:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.207] (helo=smtp108.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hl8No-000L2b-Ma
	for netconf@ops.ietf.org; Mon, 07 May 2007 18:56:30 +0000
Received: (qmail 35003 invoked from network); 7 May 2007 18:56:27 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.242 with plain)
  by smtp108.sbc.mail.mud.yahoo.com with SMTP; 7 May 2007 18:56:27 -0000
X-YMail-OSG: GlIDsdgVM1mamhrap7E.EI2jZJhjjtiwbHAseZ5yPuqwMjfWz54jGdp2FczZJj73Kd3OcxYggZQl8bGcRO__QuYZpg--
Message-ID: <463F7634.2070309@andybierman.com>
Date: Mon, 07 May 2007 11:55:48 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Schema Bug
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5C69@zcarhxm2.corp.nortel.com> <463F5A78.60402@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5EDF@zcarhxm2.corp.nortel.com> <463F6832.9060502@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EDD5FB4@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40EDD5FB4@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53

Sharon Chisholm wrote:
>  hi
> 
> I just want to make sure we are not setting a precedent with how
> notifications are defined that would preclude the same information being
> used for both, preferably without defining a complex type that gets used
> in two places.

I don't understand.
Named types are available to provide the precise feature that we need here,
all within the domain of the data model designer, as intended.
What XSD mechanism are you proposing instead?

There is no reason the Notifications document should require that any
particular data be available in any particular namespace or location
within the agent's conceptual data model, in order to be
sent in a <notification> message.

There are a couple ways to tell your XSD tools that <foo> in a notification
is the same as the /acme/router-config/blah/foo element in the
agent's data model, but this document is not the right place to
make any requirements on such a mapping.


> 
> Sharon


Andy

> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Monday, May 07, 2007 1:56 PM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: Netconf (E-mail)
> Subject: Re: Notification Schema Bug
> 
> Sharon Chisholm wrote:
>> Hi
>>
>> Notification logging isn't the use case I was referring to. Here are 
>> some that have come up.
>>
>> - An interface has changed notification where the same information is 
>> sent via a <get> you get via a notification
>> - A configuration change entity which sends to snippet of 
>> configuration that has changed (this case is a bit different)
>> - An list of alarms which can be queried to retrieve active ones, but 
>> each individual alarm definition is actually what is sent over the
> wire.
>>
>> These sort of cases were part of the reason the notification 
>> definitions were not too tied to just notifications. Notification is 
>> an operation on the data, so you don't want to limit the definition to
> 
>> just be able to be sent via notifications.
>>
> 
> XSD works great for this use case.
> 1) Define the content (syntax and semantics) with a named type.
> 2) Define accessible elements as needed, in notification content,
>     RPC parameter content, or data model content.
> 
> There is no reason to say anything in the protocol document about how
> notification content can also be retrieved with a <get> operation.
> 
> It is up to the vendor to add yet another stored notification retrieval
> mechanism.  It is up to the vendor to decide what data is retrievable
> with a <get> operation.
> 
> 
>> Sharon
> 
> Andy
> 
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com]
>> Sent: Monday, May 07, 2007 12:57 PM
>> To: Chisholm, Sharon (CAR:ZZ00)
>> Cc: Netconf (E-mail)
>> Subject: Re: Notification Schema Bug
>>
>> Sharon Chisholm wrote:
>>> Hi
>>>
>>> If we go this way, we should also add a little note somewhere that 
>>> content defined as notifications can also be retrieved via the <get> 
>>> operation. This allows a single definition of content instead of 
>>> forcing everything to be defined twice like SNMP did. It becomes a 
>>> little less obvious when it is an extension of the notification.
>>>
>> I disagree.
>> This is outside the scope of this document, and part of a Notification
> 
>> Logging MIB instead.  However, such a MIB would be rather redundant, 
>> given the replay feature within the notification draft.
>>
>> If named complexTypes are used for the content, then the 'redundant'
>> element definitions (for <get> and <notification>) are trivial to 
>> write, and the actual semantics are only defined once.
>>
>>
>>> Sharon
>> Andy
>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
>>> On Behalf Of Andy Bierman
>>> Sent: Friday, May 04, 2007 8:19 PM
>>> To: Netconf (E-mail)
>>> Subject: Notification Schema Bug
>>>
>>> Hi,
>>>
>>> The notification element definition is obsolete, based on the 
>>> decision
>>> to remove the parameters from the ReplayCompleteNotification.
>>> There is no <data> element in the notification, like <rpc-reply>.
>>> The <notification> element is a wrapper, just like the <rpc> element.
>>> This allows proper extension by any organization.  The XSD for the 
>>> <notification> element must be done the same way as the <rpc>
> element.
>>> Current text: notification-06: page 21:
>>>
>>>      <xs:complexType name="NotificationType">
>>>         <xs:sequence>
>>>           <xs:element name="data" type="netconf:dataInlineType" />
>>>         </xs:sequence>
>>>      </xs:complexType>
>>>
>>>      <xs:element name="notification" type="NotificationType"/>
>>>
>>>
>>> Proposed replacement text for page 21:
>>>
>>>      <xs:complexType name="NotificationContentType"/>
>>>
>>>      <xs:element name="notificationContent"
>>>                  type="NotificationContentType" abstract="true"/>
>>>
>>>      <xs:complexType name="NotificationType">
>>>        <xs:sequence>
>>>          <xs:element ref="notificationContent"/>
>>>        </xs:sequence>
>>>      </xs:complexType>
>>>
>>>      <xs:element name="notification" type="NotificationType"/>
>>>
>>>
>>> The replayCompleteNotification can be defined in another XSD and
>>> namespace:
>>>
>>>      <xs:complexType name="ReplayCompleteNotificationType">
>>>        <xs:complexContent>
>>>          <xs:extension base="NotificationContentType"/>
>>>        </xs:complexContent>
>>>      </xs:complexType>
>>>
>>>      <xs:element name="replayCompleteNotification"
>>>                  type="ReplayCompleteNotificationType"
>>>                  substitutionGroup="notificationContent"/>
>>>
>>>
>>> Of course, a notification with parameters would not have an empty 
>>> <extension> like this one.
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with 
>>> the
>>> word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with 
>>> the
>>> word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> 
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Wed May 09 15:39:54 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hls0w-0005h7-Cn
	for netconf-archive@lists.ietf.org; Wed, 09 May 2007 15:39:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hls0v-0004pe-0d
	for netconf-archive@lists.ietf.org; Wed, 09 May 2007 15:39:54 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HlrsC-0000Jd-Rq
	for netconf-data@psg.com; Wed, 09 May 2007 19:30:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1Hlrs9-0000JF-Av
	for netconf@ops.ietf.org; Wed, 09 May 2007 19:30:51 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l49JUjk13405
	for <netconf@ops.ietf.org>; Wed, 9 May 2007 19:30:45 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Schema Bug
Date: Wed, 9 May 2007 15:30:43 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40EE7BBC3@zcarhxm2.corp.nortel.com>
In-Reply-To: <463BCD7C.6080207@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Schema Bug
Thread-Index: AceOrEUECaI37XuCRdCI4M1jXQSr8gDwnNmw
References: <463BCD7C.6080207@andybierman.com>
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: 22bbb45ef41b733eb2d03ee71ece8243

Hi

I could not get this to validate. The XML Schema definition of the
replay complete didn't validate and neither did a random instance of a
notification that I tried. In the spirit of what Andy is suggesting, I
propose the same definition of notification, but the following
definition of the replay complete notification

    <xs:element name=3D"replayComplete" minOccurs=3D"0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay=20
                portion of a subscription.
            </xs:documentation> =20
        </xs:annotation>
        <xs:complexType>
          <xs:complexContent>
              <xs:extension
base=3D"netconf:NotificationType"></xs:extension>             =20
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

Instead of =20

<xs:element name=3D"replayComplete" minOccurs=3D"0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay=20
                portion of a subscription.
            </xs:documentation> =20
        </xs:annotation>
    </xs:element>=20


I can also define things like

    <xs:element name=3D"fooNotification" >
        <xs:complexType>
          <xs:complexContent>
              <xs:extension base=3D"NotificationType">
                  <xs:sequence>
                      <xs:element name=3D"eventClass"/>
                  </xs:sequence>
              </xs:extension> =20
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

My validator lets me do a <get> on this, but I'm not sure how smart it
is.

Sharon
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 04, 2007 8:19 PM
To: Netconf (E-mail)
Subject: Notification Schema Bug

Hi,

The notification element definition is obsolete, based on the decision
to remove the parameters from the ReplayCompleteNotification.
There is no <data> element in the notification, like <rpc-reply>.
The <notification> element is a wrapper, just like the <rpc> element.
This allows proper extension by any organization.  The XSD for the
<notification> element must be done the same way as the <rpc> element.

Current text: notification-06: page 21:

     <xs:complexType name=3D"NotificationType">
        <xs:sequence>
          <xs:element name=3D"data" type=3D"netconf:dataInlineType" />
        </xs:sequence>
     </xs:complexType>

     <xs:element name=3D"notification" type=3D"NotificationType"/>


Proposed replacement text for page 21:

     <xs:complexType name=3D"NotificationContentType"/>

     <xs:element name=3D"notificationContent"
                 type=3D"NotificationContentType" abstract=3D"true"/>

     <xs:complexType name=3D"NotificationType">
       <xs:sequence>
         <xs:element ref=3D"notificationContent"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name=3D"notification" type=3D"NotificationType"/>


The replayCompleteNotification can be defined in another XSD and
namespace:

     <xs:complexType name=3D"ReplayCompleteNotificationType">
       <xs:complexContent>
         <xs:extension base=3D"NotificationContentType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name=3D"replayCompleteNotification"
                 type=3D"ReplayCompleteNotificationType"
                 substitutionGroup=3D"notificationContent"/>


Of course, a notification with parameters would not have an empty
<extension> like this one.


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 May 09 22:31:57 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HlyRh-00078u-8N
	for netconf-archive@lists.ietf.org; Wed, 09 May 2007 22:31:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HlyRe-0000FE-V7
	for netconf-archive@lists.ietf.org; Wed, 09 May 2007 22:31:57 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HlyJj-000LCg-22
	for netconf-data@psg.com; Thu, 10 May 2007 02:23:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [207.17.137.119] (helo=smtpb.juniper.net)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1HlyJg-000LCS-PQ
	for netconf@ops.ietf.org; Thu, 10 May 2007 02:23:41 +0000
Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10])
  by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 09 May 2007 19:23:40 -0700
Received: from idle.juniper.net ([172.25.4.26])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l4A2NZJ72838
	for <netconf@ops.ietf.org>; Wed, 9 May 2007 19:23:39 -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 l4A2Ud9t020870
	for <netconf@ops.ietf.org>; Wed, 9 May 2007 22:30:44 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200705100230.l4A2Ud9t020870@idle.juniper.net>
To: netconf@ops.ietf.org
Subject: port <830>
Date: Wed, 09 May 2007 22:30:39 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

I just noticed that the port number in RFC4742 is written
inside chevrons:

   In order to allow NETCONF traffic to be easily identified and
   filtered by firewalls and other network devices, NETCONF servers MUST
   default to providing access to the "netconf" SSH subsystem only when
   the SSH session is established using the IANA-assigned TCP port
   <830>.  Servers SHOULD be configurable to allow access to the netconf
   SSH subsystem over other ports.

This looks odd in the text, but is really busted in the example:

   [user@client]$ ssh -s server.example.org -p <830> netconf

Is this intentional?

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 May 10 03:40:25 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hm3GD-0003BJ-QT
	for netconf-archive@lists.ietf.org; Thu, 10 May 2007 03:40:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hm3GC-0003iF-Fr
	for netconf-archive@lists.ietf.org; Thu, 10 May 2007 03:40:25 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hm37c-0008Dg-21
	for netconf-data@psg.com; Thu, 10 May 2007 07:31:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1Hm37Z-0008DI-75
	for netconf@ops.ietf.org; Thu, 10 May 2007 07:31:30 +0000
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
  by ams-iport-1.cisco.com with ESMTP; 10 May 2007 09:31:28 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4A7VR3r012341;
	Thu, 10 May 2007 09:31:27 +0200
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4225.cisco.com [10.61.80.128])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4A7VRlZ006981;
	Thu, 10 May 2007 07:31:27 GMT
Message-ID: <4642CA47.7090501@cisco.com>
Date: Thu, 10 May 2007 09:31:19 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: netconf@ops.ietf.org
Subject: Re: port <830>
References: <200705100230.l4A2Ud9t020870@idle.juniper.net>
In-Reply-To: <200705100230.l4A2Ud9t020870@idle.juniper.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=426; t=1178782287; x=1179646287;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=lear@cisco.com;
	z=From:=20Eliot=20Lear=20<lear@cisco.com>
	|Subject:=20Re=3A=20port=20<830>
	|Sender:=20;
	bh=Xv7pK0d/j0RugLZ5KrK2wRiYmXjQU4FHvacNZsVMTeU=;
	b=BvT8ZrC2ZY9f//b3BaBZ3D/UWf67mJ8gr6/oYXKw4dDN4gTNQcyLvEYNftmJp0+k0GkSuT1M
	QxAM1UKPedgN3PXMjh/TYXUy9tYg7aSmQv8cP1FNkpVwOsfwjJq+yBto;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s
	ig from cisco.com/amsdkim1002 verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

Phil Shafer wrote:
> I just noticed that the port number in RFC4742 is written
> inside chevrons:
>
>    [...]
>
> This looks odd in the text, but is really busted in the example:
>
>    [user@client]$ ssh -s server.example.org -p <830> netconf
>
> Is this intentional?
>   

Yes, I noticed this as well.  That looks like a goof between the RFC 
Editor and the authors where <830> I suspect was <TBD>.

Eliot

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



From owner-netconf@ops.ietf.org Thu May 10 11:57:37 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HmB1M-0007aX-W5
	for netconf-archive@lists.ietf.org; Thu, 10 May 2007 11:57:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HmB1L-0000F4-Gc
	for netconf-archive@lists.ietf.org; Thu, 10 May 2007 11:57:36 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HmAro-0009vQ-QU
	for netconf-data@psg.com; Thu, 10 May 2007 15:47:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.209] (helo=smtp110.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HmArl-0009ut-Dv
	for netconf@ops.ietf.org; Thu, 10 May 2007 15:47:43 +0000
Received: (qmail 54957 invoked from network); 10 May 2007 15:47:40 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp110.sbc.mail.mud.yahoo.com with SMTP; 10 May 2007 15:47:40 -0000
X-YMail-OSG: 2NrjTz8VM1m3bfFjnaNkm.HjFyLhfGL1JT7WO1dJbMKPpZEzTxvaU0mV8VMNlZpYI90_D6EsvUixPt.yBLpj5iiTBw--
Message-ID: <46433E74.1020308@andybierman.com>
Date: Thu, 10 May 2007 08:47:00 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Schema Bug
References: <463BCD7C.6080207@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40EE7BBC3@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40EE7BBC3@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b

Sharon Chisholm wrote:
> Hi
> 
> I could not get this to validate. The XML Schema definition of the
> replay complete didn't validate and neither did a random instance of a
> notification that I tried. In the spirit of what Andy is suggesting, I
> propose the same definition of notification, but the following
> definition of the replay complete notification
> 

The problem is that the default namespace is used incorrectly.

It is a good idea to set the default namespace (xmlns="foo")
to the target namespace (targetNamespace="foo") so definitions
within the module that reference other definitions from that
module are the only ones without a prefix.

The
It is important that the replayCompleteNotification be defined
as a complexType, to allow proper extensions for those vendors that
might ever want to do that (maybe even the WG).


Why can't you take the 'replayComplete' element and make it a ReplayComplete
complexType instead, so the element 'replayComplete' is a separate definition?

Can you see if the following fix works:

------------------------
--> Set the default namespace to the target namespace

Proposed replacement text for page 21:

     <xs:complexType name="NotificationContentType"/>

     <xs:element name="notificationContent"
                 type="NotificationContentType" abstract="true"/>

     <xs:complexType name="NotificationType">
       <xs:sequence>
         <xs:element ref="notificationContent"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name="notification" type="NotificationType"/>


--> In a different XSD:
   --> set the default namespace to the target namespace
   --> set the 'notif' prefix to the target namespace from the previous module

The replayCompleteNotification can be defined in another XSD and namespace:

     <xs:complexType name="ReplayCompleteNotificationType">
       <xs:complexContent>
         <xs:extension base="notif:NotificationContentType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="replayComplete"
                 type="ReplayCompleteNotificationType"
                 substitutionGroup="notif:notificationContent"/>

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


[Note changes in 'base' and 'substitutionGroup' QNames]

Andy



>     <xs:element name="replayComplete" minOccurs="0">
>         <xs:annotation>
>             <xs:documentation>
>                 This notification is sent to signal the end of a replay 
>                 portion of a subscription.
>             </xs:documentation>  
>         </xs:annotation>
>         <xs:complexType>
>           <xs:complexContent>
>               <xs:extension
> base="netconf:NotificationType"></xs:extension>              
>           </xs:complexContent>
>         </xs:complexType>
>     </xs:element>
> 
> Instead of  
> 
> <xs:element name="replayComplete" minOccurs="0">
>         <xs:annotation>
>             <xs:documentation>
>                 This notification is sent to signal the end of a replay 
>                 portion of a subscription.
>             </xs:documentation>  
>         </xs:annotation>
>     </xs:element> 
> 
> 
> I can also define things like
> 
>     <xs:element name="fooNotification" >
>         <xs:complexType>
>           <xs:complexContent>
>               <xs:extension base="NotificationType">
>                   <xs:sequence>
>                       <xs:element name="eventClass"/>
>                   </xs:sequence>
>               </xs:extension>  
>           </xs:complexContent>
>         </xs:complexType>
>     </xs:element>
> 
> My validator lets me do a <get> on this, but I'm not sure how smart it
> is.
> 
> Sharon
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Friday, May 04, 2007 8:19 PM
> To: Netconf (E-mail)
> Subject: Notification Schema Bug
> 
> Hi,
> 
> The notification element definition is obsolete, based on the decision
> to remove the parameters from the ReplayCompleteNotification.
> There is no <data> element in the notification, like <rpc-reply>.
> The <notification> element is a wrapper, just like the <rpc> element.
> This allows proper extension by any organization.  The XSD for the
> <notification> element must be done the same way as the <rpc> element.
> 
> Current text: notification-06: page 21:
> 
>      <xs:complexType name="NotificationType">
>         <xs:sequence>
>           <xs:element name="data" type="netconf:dataInlineType" />
>         </xs:sequence>
>      </xs:complexType>
> 
>      <xs:element name="notification" type="NotificationType"/>
> 
> 
> Proposed replacement text for page 21:
> 
>      <xs:complexType name="NotificationContentType"/>
> 
>      <xs:element name="notificationContent"
>                  type="NotificationContentType" abstract="true"/>
> 
>      <xs:complexType name="NotificationType">
>        <xs:sequence>
>          <xs:element ref="notificationContent"/>
>        </xs:sequence>
>      </xs:complexType>
> 
>      <xs:element name="notification" type="NotificationType"/>
> 
> 
> The replayCompleteNotification can be defined in another XSD and
> namespace:
> 
>      <xs:complexType name="ReplayCompleteNotificationType">
>        <xs:complexContent>
>          <xs:extension base="NotificationContentType"/>
>        </xs:complexContent>
>      </xs:complexType>
> 
>      <xs:element name="replayCompleteNotification"
>                  type="ReplayCompleteNotificationType"
>                  substitutionGroup="notificationContent"/>
> 
> 
> Of course, a notification with parameters would not have an empty
> <extension> like this one.
> 
> 
> Andy
> 
> 
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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



From owner-netconf@ops.ietf.org Tue May 15 18:56:45 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ho5wj-0007kZ-L0
	for netconf-archive@lists.ietf.org; Tue, 15 May 2007 18:56:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ho5we-0005nZ-Vw
	for netconf-archive@lists.ietf.org; Tue, 15 May 2007 18:56:45 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ho5qJ-000Gnk-O3
	for netconf-data@psg.com; Tue, 15 May 2007 22:50:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no 
	version=3.1.7
Received: from [156.154.24.139] (helo=ns4.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1Ho5qH-000Gmr-6c
	for netconf@ops.ietf.org; Tue, 15 May 2007 22:50:06 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by ns4.neustar.com (Postfix) with ESMTP id 5A9A92AC76;
	Tue, 15 May 2007 22:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Ho5qE-00043C-4N; Tue, 15 May 2007 18:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-notification-07.txt 
Message-Id: <E1Ho5qE-00043C-4N@stiedprstage1.ietf.org>
Date: Tue, 15 May 2007 18:50:02 -0400
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8

--NextPart

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

	Title		: NETCONF Event Notifications
	Author(s)	: H. Trevino, S. Chisholm
	Filename	: draft-ietf-netconf-notification-07.txt
	Pages		: 37
	Date		: 2007-5-15
	
This document defines mechanisms which provide an asynchronous
   message notification delivery service for the NETCONF protocol.  This
   is an optional capability built on top of the base NETCONF
   definition.  This document defines the capabilities and operations
   necessary to support this service.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<2007-5-15161532.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-notification-07.txt

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

Content-Type: text/plain
Content-ID:	<2007-5-15161532.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From owner-netconf@ops.ietf.org Tue May 15 19:37:16 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ho6Zw-0006kz-Em
	for netconf-archive@lists.ietf.org; Tue, 15 May 2007 19:37:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ho6Zv-0006eZ-TZ
	for netconf-archive@lists.ietf.org; Tue, 15 May 2007 19:37:16 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ho6VN-000JN8-AV
	for netconf-data@psg.com; Tue, 15 May 2007 23:32:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Ho6VK-000JMl-MO
	for netconf@ops.ietf.org; Tue, 15 May 2007 23:32:31 +0000
Received: (qmail 71461 invoked from network); 15 May 2007 23:32:29 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp114.sbc.mail.mud.yahoo.com with SMTP; 15 May 2007 23:32:29 -0000
X-YMail-OSG: .OZ5H1kVM1l3d8CJcDTUluAXk5YihIbHcQKaUlZ_SJlLFSYLxclIDXd9KvRjgcSdH3kxaorKu5Fz.IfV3oLG8DVsug--
Message-ID: <464A42E4.1050304@andybierman.com>
Date: Tue, 15 May 2007 16:31:48 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: few quick comments on notification-07
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Hi,

Reading quickly through the new draft, I noticed a few things:

1) the namedProfile has an element called stream and the create-subscription
   RPC has a parameter called stream (in addition to named-profile 
parameter).

   The stream element in the namedProfile does not have any meaning,
   according to the create-subscription text.  The stream parameter is used,
   and the stream element in the namedProfile is ignored.  What is the point
   of having the stream element in the namedProfile?

2) There is nothing in the XSD that would indicate to an XSD tool that
   the read-only timestamp in the namedProfile must not be sent as part
   of the <edit-config> to configure a named profile.  I don't think
   this object should be in the data model, but if others think this
   is important, then I guess it will stay.  The value of this object
   is not explained anywhere -- it is just assumed that read-only
   timestamps should be mixed with config data without even mentioning 
it at all.

3) The replayComplete notification contains an eventClass element.
   The WG agreed that this notification will not have any content.
   This element must be removed.

4) The XSD for the replayCompleteNotificationType and the notification
   element are wrong.  The schema in the draft does not
   represent the normative text in the rest of the draft.

   The following notifications are valid, but this is not what the XSD 
allows:

    <notification>
      <replayComplete/>
    </notification>

    <notification>
     <blah xmlns="example.com"/>
    </notification>

I believe the XSD actually described the following XML:

   <replayComplete>
     <data/>
     <eventClass>blah</eventClass>
   </replayComplete>

which is completely wrong.

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 May 16 05:35:10 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoFuY-0000OH-2U
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 05:35:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoFuW-0008Bc-BC
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 05:35:10 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoFnm-0001MV-MI
	for netconf-data@psg.com; Wed, 16 May 2007 09:28:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoFnj-0001M8-8F
	for netconf@ops.ietf.org; Wed, 16 May 2007 09:28:09 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 63C321B80C3
	for <netconf@ops.ietf.org>; Wed, 16 May 2007 11:27:54 +0200 (CEST)
Date: Wed, 16 May 2007 11:27:46 +0200 (CEST)
Message-Id: <20070516.112746.09414354.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: comments on notification-07 draft
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 5.1.51 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: 48472a944c87678fcfe8db15ffecdfff

Hi,

Here are some comments on the latest draft.  Some comments are the
same as before
(http://ops.ietf.org/lists/netconf/netconf.2007/msg00035.html).


  o  2.1.1 

     The missing-element's error-info is broken:

         Error-info: <startTime Description: An expected element is
         missing.

     I think that you should define an error-app-tag for the second
     error, i.e. replay asked for when it's not available.  


  o  2.1.1.1 

     create-subscription needs a xmlns attribute, e.g.

       <netconf:rpc message-id="101"
                    xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
         <create-subscription xmlns="urn:ietf:params:netconf:capability:notification:1.0">
         </create-subscription>
       </netconf:rpc>


  o  3.2.5.1

     The example shows how to get the <eventStreams> subtree.  But in
     this draft, you have added a top-level node 'netconf' to the
     schema.  Thus, the <get> request must be:

       <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <get>
           <filter type="subtree">
            <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
              <eventStreams/>
            </netconf>
          </filter>
        </get>
      </rpc>

     and similar for the reply.


   o  3.2.5.1

     In the rpc-reply example, none of the streams returned have the
     element 'replayLogStartTime', which according to the schema must
     be there.  Personally, I'd rather see the schema modified so that
     replayLogStartTime has minOccurs="0", and the description
     changed to:

         The start time of the log used to support the replay
         function. If replay is not supported, this element is not
         present.


   o  3.4

     The 'replayComplete' element is defined not as a top-level
     element, but as a child to 'netconf'.


   o  3.4

     I've pointed out before that the 'stream' element makes no sense
     within a named profile.  If you think it does, the text for
     create-subscription must be modified to allow for this case.


   o  3.6
  
     Why does this section talk about "multiple filters"?  In the
     schema for 'create-subscription', the description for the
     'filter' parameter says: 

         This is mutually exclusive with the named profile parameter.

     So when/how can multiple filters be specified?


   o  5.1

     I've also said before that this example doesn't make much sense.
     It also contains some XML errors.

     First of all, the <event> wrapper isn't mentioned in the text.
     Second, you have the structure:

         event/events/eventEntry

     What does that mean?  If a client receives a single notification,
     would it be an 'event'?  Or an 'eventEntry'?  Or maybe 'events'?

     I think the following would be more clear:

         Sample event list

                 <event>
                   <eventClass>fault</eventClass>
                   <reportingEntity>
                     <card>Ethernet0</card>
                   </reportingEntity>
                   <severity>major</severity>
                 </event>

                 <event>
                   <eventClass>fault</eventClass>
                   <reportingEntity>
                     <card>Ethernet2</card>
                   </reportingEntity>
                   <severity>critical</severity>
                 </event>

                 <event>
                   <eventClass>fault</eventClass>
                   <reportingEntity>
                     <card>ATM1</card>
                   </reportingEntity>
                   <severity>minor</severity>
                 </event>

                 <event>
                   <eventClass>state</eventClass>
                   <reportingEntity>
                     <card>Ethernet0</card>
                   </reportingEntity>
                   <operState>enabled</operState>
                 </event>

      And subtree filter:

        <netconf:rpc netconf:message-id="101"
                     xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
          <create-subscription
              xmlns="urn:ietf:params:netconf:capability:notification:1.0">
            <filter netconf:type="subtree">
              <event xmlns="http://example.com/event/1.0">
                <eventClass>fault</eventClass>
                <severity>critical</severity>
              </event>
              <event xmlns="http://example.com/event/1.0">
                <eventClass>fault</eventClass>
                <severity>major</severity>
              </event>
              <event xmlns="http://example.com/event/1.0">
                <eventClass>fault</eventClass>
                <severity>minor</severity>
              </event>
            </filter>
          </create-subscription>
        </netconf:rpc>


      And XPath filter:

        <netconf:rpc netconf:message-id="101"
                     xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
          <create-subscription
                xmlns="urn:ietf:params:netconf:capability:notification:1.0">
            <filter netconf:type="xpath"
              select="/event[(eventClass='fault' and
                    (severity='minor' or severity='major'
                     or severity='critical'))]"/>
        </create-subscription>
      </netconf:rpc>


     Note that all examples in 5.1 and 5.2 have gotten the namespace
     for <create-subscription> wrong.



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 16 05:54:59 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoGDj-0004H9-Kl
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 05:54:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoGDi-00050x-AT
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 05:54:59 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoG8e-0002pT-G1
	for netconf-data@psg.com; Wed, 16 May 2007 09:49:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoG8b-0002p9-G2
	for netconf@ops.ietf.org; Wed, 16 May 2007 09:49:43 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 2519F1B80C3;
	Wed, 16 May 2007 11:49:40 +0200 (CEST)
Date: Wed, 16 May 2007 11:49:32 +0200 (CEST)
Message-Id: <20070516.114932.02843406.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <464A42E4.1050304@andybierman.com>
References: <464A42E4.1050304@andybierman.com>
X-Mailer: Mew version 5.1.51 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: 4adaf050708fb13be3316a9eee889caa

Andy Bierman <ietf@andybierman.com> wrote:
> 2) There is nothing in the XSD that would indicate to an XSD tool that
>    the read-only timestamp in the namedProfile must not be sent as part
>    of the <edit-config> to configure a named profile.  I don't think
>    this object should be in the data model, but if others think this
>    is important, then I guess it will stay.  The value of this object
>    is not explained anywhere -- it is just assumed that read-only
>    timestamps should be mixed with config data without even mentioning 
> it at all.

It is mentioned in the description clause.

But I think that there are more serious issues with this data model,
and I have pointed it out before.   The intention is that this DM can
be modified with an edit-config.  But there is nothing in the schema
that says what the key for a namedProfile is.  So how do you modify
one?

Also, it says that the 'name' paramater (which I would guess is
supposed to be the key) is modifiable.  How is this done using an
edit-config?

filter has minOccurs=0.  What exactly does that mean?  Can I create a
namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
contents of the device's datastore, and not an instance document?

The filter itself is also supposed to be modifiable.  Now, the filter
can contain _any_ XML (if it's a subtree filter), and we're supposed
to be able to use edit-config to modify parts of it...?

IMO, if we are going to include this DM, the text needs to describe
how this is supposed to work, otherwise we won't see interoperable
implementations.

I suggest that for the filter parameter, the XML should be treated as
an opaque data structure, which can be deleted, created and replaced
in its entirety only.


/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 May 16 11:19:35 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoLHr-0000E4-J6
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 11:19:35 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoLHn-0005aJ-7P
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 11:19:35 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoLAj-000Nu3-Gi
	for netconf-data@psg.com; Wed, 16 May 2007 15:12:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HoLAV-000Nsr-Gh
	for netconf@ops.ietf.org; Wed, 16 May 2007 15:12:01 +0000
Received: (qmail 74738 invoked from network); 16 May 2007 15:11:58 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp114.sbc.mail.mud.yahoo.com with SMTP; 16 May 2007 15:11:58 -0000
X-YMail-OSG: N_LIIEwVM1nEaDdL41y5QbdCGTz8SxkCKqE.8H6XVn_rRRto
Message-ID: <464B1F14.9060805@andybierman.com>
Date: Wed, 16 May 2007 08:11:16 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
References: <464A42E4.1050304@andybierman.com> <20070516.114932.02843406.mbj@tail-f.com>
In-Reply-To: <20070516.114932.02843406.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.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> 2) There is nothing in the XSD that would indicate to an XSD tool that
>>    the read-only timestamp in the namedProfile must not be sent as part
>>    of the <edit-config> to configure a named profile.  I don't think
>>    this object should be in the data model, but if others think this
>>    is important, then I guess it will stay.  The value of this object
>>    is not explained anywhere -- it is just assumed that read-only
>>    timestamps should be mixed with config data without even mentioning 
>> it at all.
> 
> It is mentioned in the description clause.
> 
> But I think that there are more serious issues with this data model,
> and I have pointed it out before.   The intention is that this DM can
> be modified with an edit-config.  But there is nothing in the schema
> that says what the key for a namedProfile is.  So how do you modify
> one?
> 
> Also, it says that the 'name' paramater (which I would guess is
> supposed to be the key) is modifiable.  How is this done using an
> edit-config?
> 
> filter has minOccurs=0.  What exactly does that mean?  Can I create a
> namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
> contents of the device's datastore, and not an instance document?
> 
> The filter itself is also supposed to be modifiable.  Now, the filter
> can contain _any_ XML (if it's a subtree filter), and we're supposed
> to be able to use edit-config to modify parts of it...?
> 
> IMO, if we are going to include this DM, the text needs to describe
> how this is supposed to work, otherwise we won't see interoperable
> implementations.
> 
> I suggest that for the filter parameter, the XML should be treated as
> an opaque data structure, which can be deleted, created and replaced
> in its entirety only.
> 

I am concerned about adding poorly understood CLRs on top of a poorly
designed data model as a band-aid, and ending up with a non-interoperable
standard.

Due to the nature of subtree filtering, it cannot be implemented
with 'conventional' XML parsers at all.  Invalid declarations are
just no-match conditions, not errors.  Applying the <edit-config>
operation attribute to the filter is difficult, if not impossible,
in such cases.

The real issue is having a data model object of type 'any' in a
configuration database.  The real issue is that we don't
have much common understanding of the differences between XML instance
documents and NETCONF configuration databases.

> 
> /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 Wed May 16 11:33:22 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoLVB-0000QZ-B5
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 11:33:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoLV8-00019j-SB
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 11:33:21 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoLPu-000P0G-0L
	for netconf-data@psg.com; Wed, 16 May 2007 15:27:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoLPq-000Ozx-E8
	for netconf@ops.ietf.org; Wed, 16 May 2007 15:27:52 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id B2F441B80C4;
	Wed, 16 May 2007 17:27:47 +0200 (CEST)
Date: Wed, 16 May 2007 17:27:40 +0200 (CEST)
Message-Id: <20070516.172740.80379702.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <464B1F14.9060805@andybierman.com>
References: <464A42E4.1050304@andybierman.com>
	<20070516.114932.02843406.mbj@tail-f.com>
	<464B1F14.9060805@andybierman.com>
X-Mailer: Mew version 5.1.51 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: a2c12dacc0736f14d6b540e805505a86

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> 2) There is nothing in the XSD that would indicate to an XSD tool that
> >>    the read-only timestamp in the namedProfile must not be sent as part
> >>    of the <edit-config> to configure a named profile.  I don't think
> >>    this object should be in the data model, but if others think this
> >>    is important, then I guess it will stay.  The value of this object
> >>    is not explained anywhere -- it is just assumed that read-only
> >>    timestamps should be mixed with config data without even mentioning 
> >> it at all.
> > 
> > It is mentioned in the description clause.
> > 
> > But I think that there are more serious issues with this data model,
> > and I have pointed it out before.   The intention is that this DM can
> > be modified with an edit-config.  But there is nothing in the schema
> > that says what the key for a namedProfile is.  So how do you modify
> > one?
> > 
> > Also, it says that the 'name' paramater (which I would guess is
> > supposed to be the key) is modifiable.  How is this done using an
> > edit-config?
> > 
> > filter has minOccurs=0.  What exactly does that mean?  Can I create a
> > namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
> > contents of the device's datastore, and not an instance document?
> > 
> > The filter itself is also supposed to be modifiable.  Now, the filter
> > can contain _any_ XML (if it's a subtree filter), and we're supposed
> > to be able to use edit-config to modify parts of it...?
> > 
> > IMO, if we are going to include this DM, the text needs to describe
> > how this is supposed to work, otherwise we won't see interoperable
> > implementations.
> > 
> > I suggest that for the filter parameter, the XML should be treated as
> > an opaque data structure, which can be deleted, created and replaced
> > in its entirety only.
> > 
> 
> I am concerned about adding poorly understood CLRs on top of a poorly
> designed data model as a band-aid, and ending up with a non-interoperable
> standard.
> 
> Due to the nature of subtree filtering, it cannot be implemented
> with 'conventional' XML parsers at all.  Invalid declarations are
> just no-match conditions, not errors.

Absolutely.

> Applying the <edit-config>
> operation attribute to the filter is difficult, if not impossible,
> in such cases.

Suppose we have this filter stored in a namedProfile:

  <foo hoo="1">
    <bar>2</bar>
    <baz>3</baz>
  </foo>

And I do the following edit-config:

  <foo hoo="2" nc:operation="merge">
    <bar>3</bar>
    <baz>3</baz>
  </foo>

Are you saying that there's a single correct data-model agnostic
answer what the resulting config looks like?

> The real issue is having a data model object of type 'any' in a
> configuration database.

Yes.

> The real issue is that we don't
> have much common understanding of the differences between XML instance
> documents and NETCONF configuration databases.

So what's your suggestion?  Do you agree that this is a problem?

I don't think this is a CLR - if the type is 'any', we do
delete/replace/create on the entire thing.   One alternative would be
to not allow 'any', which in this case means remove namedProfiles.


/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 May 16 12:09:16 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoM3w-0000DV-Qs
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 12:09:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoM3v-0002zs-Al
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 12:09:16 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoLwL-0001XV-0P
	for netconf-data@psg.com; Wed, 16 May 2007 16:01:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.200] (helo=smtp101.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HoLwH-0001XD-So
	for netconf@ops.ietf.org; Wed, 16 May 2007 16:01:23 +0000
Received: (qmail 37398 invoked from network); 16 May 2007 16:01:21 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp101.sbc.mail.mud.yahoo.com with SMTP; 16 May 2007 16:01:20 -0000
X-YMail-OSG: AfPLSh0VM1laD8oZDoUBxoBLqc6SJJl7PmVboprsS55lhrBc
Message-ID: <464B2AA6.6070800@andybierman.com>
Date: Wed, 16 May 2007 09:00:38 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
References: <464A42E4.1050304@andybierman.com>	<20070516.114932.02843406.mbj@tail-f.com>	<464B1F14.9060805@andybierman.com> <20070516.172740.80379702.mbj@tail-f.com>
In-Reply-To: <20070516.172740.80379702.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.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>> Andy Bierman <ietf@andybierman.com> wrote:
>>>> 2) There is nothing in the XSD that would indicate to an XSD tool that
>>>>    the read-only timestamp in the namedProfile must not be sent as part
>>>>    of the <edit-config> to configure a named profile.  I don't think
>>>>    this object should be in the data model, but if others think this
>>>>    is important, then I guess it will stay.  The value of this object
>>>>    is not explained anywhere -- it is just assumed that read-only
>>>>    timestamps should be mixed with config data without even mentioning 
>>>> it at all.
>>> It is mentioned in the description clause.
>>>
>>> But I think that there are more serious issues with this data model,
>>> and I have pointed it out before.   The intention is that this DM can
>>> be modified with an edit-config.  But there is nothing in the schema
>>> that says what the key for a namedProfile is.  So how do you modify
>>> one?
>>>
>>> Also, it says that the 'name' paramater (which I would guess is
>>> supposed to be the key) is modifiable.  How is this done using an
>>> edit-config?
>>>
>>> filter has minOccurs=0.  What exactly does that mean?  Can I create a
>>> namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
>>> contents of the device's datastore, and not an instance document?
>>>
>>> The filter itself is also supposed to be modifiable.  Now, the filter
>>> can contain _any_ XML (if it's a subtree filter), and we're supposed
>>> to be able to use edit-config to modify parts of it...?
>>>
>>> IMO, if we are going to include this DM, the text needs to describe
>>> how this is supposed to work, otherwise we won't see interoperable
>>> implementations.
>>>
>>> I suggest that for the filter parameter, the XML should be treated as
>>> an opaque data structure, which can be deleted, created and replaced
>>> in its entirety only.
>>>
>> I am concerned about adding poorly understood CLRs on top of a poorly
>> designed data model as a band-aid, and ending up with a non-interoperable
>> standard.
>>
>> Due to the nature of subtree filtering, it cannot be implemented
>> with 'conventional' XML parsers at all.  Invalid declarations are
>> just no-match conditions, not errors.
> 
> Absolutely.
> 
>> Applying the <edit-config>
>> operation attribute to the filter is difficult, if not impossible,
>> in such cases.
> 
> Suppose we have this filter stored in a namedProfile:
> 
>   <foo hoo="1">
>     <bar>2</bar>
>     <baz>3</baz>
>   </foo>
> 
> And I do the following edit-config:
> 
>   <foo hoo="2" nc:operation="merge">
>     <bar>3</bar>
>     <baz>3</baz>
>   </foo>
> 
> Are you saying that there's a single correct data-model agnostic
> answer what the resulting config looks like?

no -- it doesn't even make sense to apply the edit-config
operations to type 'any' in every case.

For your example, my code would produce the following result,
since type 'any' means zero or more instances of arbitrary
unnamed nodes. (As always, attributes are zero or one instance.)

   <foo hoo="2">
     <bar>2</bar>
     <bar>3</bar>
     <baz>3</baz>
     <baz>3</baz>
   </foo>


> 
>> The real issue is having a data model object of type 'any' in a
>> configuration database.
> 
> Yes.
> 
>> The real issue is that we don't
>> have much common understanding of the differences between XML instance
>> documents and NETCONF configuration databases.
> 
> So what's your suggestion?  Do you agree that this is a problem?
> 

yes.
A giant red flag goes up when I see massive implementation complexity
for a loosely defined standard, since this always leads to interoperability
problems.

> I don't think this is a CLR - if the type is 'any', we do
> delete/replace/create on the entire thing.   One alternative would be
> to not allow 'any', which in this case means remove namedProfiles.

The concern I have is that the protocol defines the edit-config operations
and it doesn't say in RFC 4741 that if the agent identifies a sub-node
within the configuration contents of type 'any', then all 'operation'
attribute declarations within that subtree will be ignored, and a 'replace'
operation will be performed on the node of type 'any' instead.

This is a hack, not a CLR.

This is an important issue because these named profiles are
mandatory-to-implement.  They are completely redundant as well.
There are no interoperability problems possible when type 'any'
is passed as an RPC parameter, but this is not true for the
edit-config operation on configuration data of type 'any'.

We have nothing in SMIv2 like type 'any'.
IMO, it is an extremely bad idea to use this data type
in a NETCONF configuration database.  All data should
be named and strongly typed instead.  This is a case where
the protocol WG is getting into data modeling issues it
doesn't fully understand.

Perhaps named profiles should be removed (deferred) until NETMOD
figures out what rules should be defined for standard NETCONF data models.


> 
> 
> /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 Wed May 16 12:48:20 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoMfk-00045M-T3
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 12:48:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoMfk-0005MM-Bk
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 12:48:20 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoMa2-0004Xt-L3
	for netconf-data@psg.com; Wed, 16 May 2007 16:42:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoMZz-0004Xe-Nh
	for netconf@ops.ietf.org; Wed, 16 May 2007 16:42:25 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 8C0471B80C3;
	Wed, 16 May 2007 18:42:22 +0200 (CEST)
Date: Wed, 16 May 2007 18:42:15 +0200 (CEST)
Message-Id: <20070516.184215.117699908.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <464B2AA6.6070800@andybierman.com>
References: <464B1F14.9060805@andybierman.com>
	<20070516.172740.80379702.mbj@tail-f.com>
	<464B2AA6.6070800@andybierman.com>
X-Mailer: Mew version 5.1.51 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: f4c2cf0bccc868e4cc88dace71fb3f44

Andy Bierman <ietf@andybierman.com> wrote:
> > So what's your suggestion?  Do you agree that this is a problem?
> > 
> 
> yes.
> A giant red flag goes up when I see massive implementation complexity
> for a loosely defined standard, since this always leads to interoperability
> problems.
> 
> > I don't think this is a CLR - if the type is 'any', we do
> > delete/replace/create on the entire thing.   One alternative would be
> > to not allow 'any', which in this case means remove namedProfiles.
> 
> The concern I have is that the protocol defines the edit-config operations
> and it doesn't say in RFC 4741 that if the agent identifies a sub-node
> within the configuration contents of type 'any', then all 'operation'
> attribute declarations within that subtree will be ignored, and a 'replace'
> operation will be performed on the node of type 'any' instead.
> 
> This is a hack, not a CLR.

The idea was that the agent would just *allow* these operations, not
silently convert a delete into a replace.  So if it receives a
'operation' attribute somewhere within the 'filter', it would raise an
error.

I think this is a clean way to handle 'any'.

> This is an important issue because these named profiles are
> mandatory-to-implement.  They are completely redundant as well.
> There are no interoperability problems possible when type 'any'
> is passed as an RPC parameter, but this is not true for the
> edit-config operation on configuration data of type 'any'.
> 
> We have nothing in SMIv2 like type 'any'.
> IMO, it is an extremely bad idea to use this data type
> in a NETCONF configuration database.  All data should
> be named and strongly typed instead.  This is a case where
> the protocol WG is getting into data modeling issues it
> doesn't fully understand.

I agree, but I can see that it is useful in some circumstances,
e.g. a logging mib is much easier to define with an 'any' type.

> Perhaps named profiles should be removed (deferred) until NETMOD
> figures out what rules should be defined for standard NETCONF data models.

Unless we can agree on how 'any' should be handled (at least in this
case), I think it's best to defer this.


/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 May 16 13:18:01 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoN8T-0005xO-IC
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 13:18:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoN8R-0000ku-3k
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 13:18:01 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoN3p-0006fS-FF
	for netconf-data@psg.com; Wed, 16 May 2007 17:13:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.204] (helo=smtp105.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HoN3m-0006f9-C7
	for netconf@ops.ietf.org; Wed, 16 May 2007 17:13:12 +0000
Received: (qmail 78201 invoked from network); 16 May 2007 17:13:09 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp105.sbc.mail.mud.yahoo.com with SMTP; 16 May 2007 17:13:09 -0000
X-YMail-OSG: 8C7oH28VM1k0yefiQk6sO61A.z1NIKtSAyXHVFpTwCAAIKNj
Message-ID: <464B3B7B.5000707@andybierman.com>
Date: Wed, 16 May 2007 10:12:27 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
References: <464B1F14.9060805@andybierman.com>	<20070516.172740.80379702.mbj@tail-f.com>	<464B2AA6.6070800@andybierman.com> <20070516.184215.117699908.mbj@tail-f.com>
In-Reply-To: <20070516.184215.117699908.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.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>>> So what's your suggestion?  Do you agree that this is a problem?
>>>
>> yes.
>> A giant red flag goes up when I see massive implementation complexity
>> for a loosely defined standard, since this always leads to interoperability
>> problems.
>>
>>> I don't think this is a CLR - if the type is 'any', we do
>>> delete/replace/create on the entire thing.   One alternative would be
>>> to not allow 'any', which in this case means remove namedProfiles.
>> The concern I have is that the protocol defines the edit-config operations
>> and it doesn't say in RFC 4741 that if the agent identifies a sub-node
>> within the configuration contents of type 'any', then all 'operation'
>> attribute declarations within that subtree will be ignored, and a 'replace'
>> operation will be performed on the node of type 'any' instead.
>>
>> This is a hack, not a CLR.
> 
> The idea was that the agent would just *allow* these operations, not
> silently convert a delete into a replace.  So if it receives a
> 'operation' attribute somewhere within the 'filter', it would raise an
> error.
> 
> I think this is a clean way to handle 'any'.

So an operation-not-supported error gets returned instead?
The actual edit-operation in effect at any node depends on
the operation attribute(s) and the default-operation parameter.
The default is 'merge'.  So a merge on type 'any' can silently
turn into a 'replace' instead?

I think the specification of this clean way to handle 'any'
needs much more thought around the corner-cases.

> 
>> This is an important issue because these named profiles are
>> mandatory-to-implement.  They are completely redundant as well.
>> There are no interoperability problems possible when type 'any'
>> is passed as an RPC parameter, but this is not true for the
>> edit-config operation on configuration data of type 'any'.
>>
>> We have nothing in SMIv2 like type 'any'.
>> IMO, it is an extremely bad idea to use this data type
>> in a NETCONF configuration database.  All data should
>> be named and strongly typed instead.  This is a case where
>> the protocol WG is getting into data modeling issues it
>> doesn't fully understand.
> 
> I agree, but I can see that it is useful in some circumstances,
> e.g. a logging mib is much easier to define with an 'any' type.

Yes, but that is monitoring data that is not affected by edit-config.
I should of said "writable data".  This is not a problem for read-only data.

> 
>> Perhaps named profiles should be removed (deferred) until NETMOD
>> figures out what rules should be defined for standard NETCONF data models.
> 
> Unless we can agree on how 'any' should be handled (at least in this
> case), I think it's best to defer this.
> 
> 
> /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 Wed May 16 13:48:55 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoNcN-00013Z-5s
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 13:48:55 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoNcM-0007S2-Nq
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 13:48:55 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoNX6-0008d3-4N
	for netconf-data@psg.com; Wed, 16 May 2007 17:43:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoNX3-0008cl-6q
	for netconf@ops.ietf.org; Wed, 16 May 2007 17:43:26 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id D263D1B80C3;
	Wed, 16 May 2007 19:43:23 +0200 (CEST)
Date: Wed, 16 May 2007 19:43:16 +0200 (CEST)
Message-Id: <20070516.194316.63807660.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <464B3B7B.5000707@andybierman.com>
References: <464B2AA6.6070800@andybierman.com>
	<20070516.184215.117699908.mbj@tail-f.com>
	<464B3B7B.5000707@andybierman.com>
X-Mailer: Mew version 5.1.51 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: 32b73d73e8047ed17386f9799119ce43

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >>> So what's your suggestion?  Do you agree that this is a problem?
> >>>
> >> yes.
> >> A giant red flag goes up when I see massive implementation complexity
> >> for a loosely defined standard, since this always leads to interoperability
> >> problems.
> >>
> >>> I don't think this is a CLR - if the type is 'any', we do
> >>> delete/replace/create on the entire thing.   One alternative would be
> >>> to not allow 'any', which in this case means remove namedProfiles.
> >> The concern I have is that the protocol defines the edit-config operations
> >> and it doesn't say in RFC 4741 that if the agent identifies a sub-node
> >> within the configuration contents of type 'any', then all 'operation'
> >> attribute declarations within that subtree will be ignored, and a 'replace'
> >> operation will be performed on the node of type 'any' instead.
> >>
> >> This is a hack, not a CLR.
> > 
> > The idea was that the agent would just *allow* these operations, not
> > silently convert a delete into a replace.  So if it receives a
> > 'operation' attribute somewhere within the 'filter', it would raise an
> > error.
> > 
> > I think this is a clean way to handle 'any'.
> 
> So an operation-not-supported error gets returned instead?

I'm not sure that's the correct error code.  Compare with this case.
Suppose a 'service' has two keys, 'ip' and 'port'.  What error message
do you get if you send:

   <service nc:operation="create">
     <ip>10.0.0.1</ip>
     <port nc:operation="delete">80</port>
     ...
   </service>

> The actual edit-operation in effect at any node depends on
> the operation attribute(s) and the default-operation parameter.
> The default is 'merge'.  So a merge on type 'any' can silently
> turn into a 'replace' instead?

In the same way as merge "silently turns into a replace" on an
integer:

   <ifMtu nc:operation="merge">1500</ifMtu>

vs.

   <ifMtu nc:operation="replace">1500</ifMtu>



> I think the specification of this clean way to handle 'any'
> needs much more thought around the corner-cases.

Well, it's not even written down, so you're probably right.  We
currently do not support 'any' in this way, but this is the way I've
planned to support it.

> >> This is an important issue because these named profiles are
> >> mandatory-to-implement.  They are completely redundant as well.
> >> There are no interoperability problems possible when type 'any'
> >> is passed as an RPC parameter, but this is not true for the
> >> edit-config operation on configuration data of type 'any'.
> >>
> >> We have nothing in SMIv2 like type 'any'.
> >> IMO, it is an extremely bad idea to use this data type
> >> in a NETCONF configuration database.  All data should
> >> be named and strongly typed instead.  This is a case where
> >> the protocol WG is getting into data modeling issues it
> >> doesn't fully understand.
> > 
> > I agree, but I can see that it is useful in some circumstances,
> > e.g. a logging mib is much easier to define with an 'any' type.
> 
> Yes, but that is monitoring data that is not affected by edit-config.
> I should of said "writable data".  This is not a problem for read-only data.

Ok.


/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 May 16 15:36:58 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoPIw-0007zh-4z
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 15:36:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoPIt-0005az-PV
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 15:36:58 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoPCa-000Fzs-Lf
	for netconf-data@psg.com; Wed, 16 May 2007 19:30:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HoPCX-000Fyy-K1
	for netconf@ops.ietf.org; Wed, 16 May 2007 19:30:23 +0000
Received: (qmail 50920 invoked from network); 16 May 2007 19:30:16 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp114.sbc.mail.mud.yahoo.com with SMTP; 16 May 2007 19:30:16 -0000
X-YMail-OSG: s2tZ3qwVM1lVmSEtDMET4YMhiysvppGu0PDxWE3bGw6ONXn_
Message-ID: <464B5B9E.1040108@andybierman.com>
Date: Wed, 16 May 2007 12:29:34 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
References: <464B2AA6.6070800@andybierman.com>	<20070516.184215.117699908.mbj@tail-f.com>	<464B3B7B.5000707@andybierman.com> <20070516.194316.63807660.mbj@tail-f.com>
In-Reply-To: <20070516.194316.63807660.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.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

 >....
>> The actual edit-operation in effect at any node depends on
>> the operation attribute(s) and the default-operation parameter.
>> The default is 'merge'.  So a merge on type 'any' can silently
>> turn into a 'replace' instead?
> 
> In the same way as merge "silently turns into a replace" on an
> integer:
> 
>    <ifMtu nc:operation="merge">1500</ifMtu>
> 
> vs.
> 
>    <ifMtu nc:operation="replace">1500</ifMtu>
> 
> 


Except 'any' can have child nodes, so the difference is noticeable.

   <foo>
     <a/>
   </foo>

merged with

   <foo>
     <b/>
   </foo>

results in

   <foo>
     <a/>
     <b/>
   </foo>

or

   <foo>
     <b/>
     <a/>
   </foo>


but not

   <foo>
     <b/>
   </foo>


> 
> /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 Wed May 16 16:02:48 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoPhw-0001zm-Aj
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 16:02:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoPhu-0001Ra-Vx
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 16:02:48 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoPdM-000Hq7-4B
	for netconf-data@psg.com; Wed, 16 May 2007 19:58:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HoPdJ-000Hpn-7j
	for netconf@ops.ietf.org; Wed, 16 May 2007 19:58:02 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 49F061B80C3;
	Wed, 16 May 2007 21:57:58 +0200 (CEST)
Date: Wed, 16 May 2007 21:57:51 +0200 (CEST)
Message-Id: <20070516.215751.10233808.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <464B5B9E.1040108@andybierman.com>
References: <464B3B7B.5000707@andybierman.com>
	<20070516.194316.63807660.mbj@tail-f.com>
	<464B5B9E.1040108@andybierman.com>
X-Mailer: Mew version 5.1.51 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: 52f7a77164458f8c7b36b66787c853da

Maybe this is getting off topic.

Andy Bierman <ietf@andybierman.com> wrote:
>  >....
> >> The actual edit-operation in effect at any node depends on
> >> the operation attribute(s) and the default-operation parameter.
> >> The default is 'merge'.  So a merge on type 'any' can silently
> >> turn into a 'replace' instead?
> > 
> > In the same way as merge "silently turns into a replace" on an
> > integer:
> > 
> >    <ifMtu nc:operation="merge">1500</ifMtu>
> > 
> > vs.
> > 
> >    <ifMtu nc:operation="replace">1500</ifMtu>
> > 
> > 
> 
> 
> Except 'any' can have child nodes, so the difference is noticeable.
> 
>    <foo>
>      <a/>
>    </foo>
> 
> merged with
> 
>    <foo>
>      <b/>
>    </foo>
> 
> results in
> 
>    <foo>
>      <a/>
>      <b/>
>    </foo>
> 
> or
> 
>    <foo>
>      <b/>
>      <a/>
>    </foo>
> 
> 
> but not
> 
>    <foo>
>      <b/>
>    </foo>

I think I know one implementation where this is the case, if foo is
defined to have a <choice> of a or b as children.



/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 May 16 16:45:27 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoQND-0007rd-74
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 16:45:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HoQNC-0007Gl-Sx
	for netconf-archive@lists.ietf.org; Wed, 16 May 2007 16:45:27 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HoQHu-000KHQ-BZ
	for netconf-data@psg.com; Wed, 16 May 2007 20:39:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.208] (helo=smtp109.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HoQHr-000KHC-OX
	for netconf@ops.ietf.org; Wed, 16 May 2007 20:39:57 +0000
Received: (qmail 48635 invoked from network); 16 May 2007 20:39:54 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.98 with plain)
  by smtp109.sbc.mail.mud.yahoo.com with SMTP; 16 May 2007 20:39:54 -0000
X-YMail-OSG: lg9cCmQVM1mObEWkXEh2l7u8_p3fxaIlE9GGmWfwE_rspMiy
Message-ID: <464B6BF0.7050300@andybierman.com>
Date: Wed, 16 May 2007 13:39:12 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: few quick comments on notification-07
References: <464B3B7B.5000707@andybierman.com>	<20070516.194316.63807660.mbj@tail-f.com>	<464B5B9E.1040108@andybierman.com> <20070516.215751.10233808.mbj@tail-f.com>
In-Reply-To: <20070516.215751.10233808.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.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d

Martin Bjorklund wrote:
> Maybe this is getting off topic.
> 
> Andy Bierman <ietf@andybierman.com> wrote:
>>  >....
>>>> The actual edit-operation in effect at any node depends on
>>>> the operation attribute(s) and the default-operation parameter.
>>>> The default is 'merge'.  So a merge on type 'any' can silently
>>>> turn into a 'replace' instead?
>>> In the same way as merge "silently turns into a replace" on an
>>> integer:
>>>
>>>    <ifMtu nc:operation="merge">1500</ifMtu>
>>>
>>> vs.
>>>
>>>    <ifMtu nc:operation="replace">1500</ifMtu>
>>>
>>>
>>
>> Except 'any' can have child nodes, so the difference is noticeable.
>>
>>    <foo>
>>      <a/>
>>    </foo>
>>
>> merged with
>>
>>    <foo>
>>      <b/>
>>    </foo>
>>
>> results in
>>
>>    <foo>
>>      <a/>
>>      <b/>
>>    </foo>
>>
>> or
>>
>>    <foo>
>>      <b/>
>>      <a/>
>>    </foo>
>>
>>
>> but not
>>
>>    <foo>
>>      <b/>
>>    </foo>
> 
> I think I know one implementation where this is the case, if foo is
> defined to have a <choice> of a or b as children.
> 
> 

If <foo> is type 'choice' then it isn't type 'any'.
The 'b' result would be correct if <foo> was defined
as a choice of <a> or <b>.

(Merging choices correctly is fairly painful if one or more
of the choices is a 'group' instead of an 'element',
especially when dealing with defaults.)

> 
> /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 May 17 13:02:54 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HojNO-0006NN-B3
	for netconf-archive@lists.ietf.org; Thu, 17 May 2007 13:02:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HojNL-0000Gw-Tx
	for netconf-archive@lists.ietf.org; Thu, 17 May 2007 13:02:54 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HojFM-000Cp3-UO
	for netconf-data@psg.com; Thu, 17 May 2007 16:54:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE 
	autolearn=ham version=3.1.7
Received: from [61.144.161.53] (helo=szxga01-in.huawei.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <liyan_77@huawei.com>)
	id 1HojFK-000Cof-7n
	for netconf@ops.ietf.org; Thu, 17 May 2007 16:54:35 +0000
Received: from huawei.com (szxga01-in [172.24.2.3])
 by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0JI700LA32YPT4@szxga01-in.huawei.com> for
 netconf@ops.ietf.org; Fri, 18 May 2007 00:54:25 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
 by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0JI7008B42YORO@szxga01-in.huawei.com> for
 netconf@ops.ietf.org; Fri, 18 May 2007 00:54:25 +0800 (CST)
Received: from jys5011175 ([10.192.21.52])
 by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0JI70030I2YKYF@szxml03-in.huawei.com> for
 netconf@ops.ietf.org; Fri, 18 May 2007 00:54:24 +0800 (CST)
Date: Fri, 18 May 2007 00:54:20 +0800
From: Li Yan <liyan_77@huawei.com>
Subject: Some trivial comments on notification-07
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Message-id: <009601c798a4$04b92710$3415c00a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: multipart/alternative;
 boundary="Boundary_(ID_dKhsAI5pcu2y2tHks3EzSg)"
X-Priority: 3
X-MSMail-priority: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e

This is a multi-part message in MIME format.

--Boundary_(ID_dKhsAI5pcu2y2tHks3EzSg)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi,
I find some trivial mistakes in this revision.

o pg 3, ToC: Sec. 2.1 title: Capitalize 'receive'.

o pg 4, Figure 1: The vertical lines are untidy.

o pg 8, the first paragraph: 
        If the startTime specified is earlier then the log can support,
                                              ^^^^
        'then' should be 'than'.

o pg 11, Sec. 3.1.2: The indent of elements are untidy. This problem occurs throughout the document.

o pg 12, Figure 4 should be Figure 2.

o pg 22, Figure 8 should be Figure 3.

o pg 31, Sec. 5.2, the second example:
        The filtering criteria evaluation does not consist with the XPath expression.
(( state | config) & ((fault & severity=critical) | (fault &
 ^               ^ ^
   severity=major) | (fault & severity = minor) | (fault &
   card=Ethernet0)))

<filter netconf:type="xpath"
    select="//eventEntry[(eventClass='fault' and
            severity='minor') or
            (eventClass='fault' and severity='major') or
            (eventClass='fault' and severity='critical') or
            (eventClass='fault' and card='Ethernet0') or
                                                      ^^
             eventClass='state' or eventClass='config' ]"/>
            ^                                         ^ 

Yan

--Boundary_(ID_dKhsAI5pcu2y2tHks3EzSg)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Hi,</FONT></DIV>
<DIV><FONT size=2>I find some&nbsp;trivial mistakes in this 
revision.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>o pg 3, ToC: Sec. 2.1 title: Capitalize 
'receive'.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 4, Figure 1: The vertical lines are untidy.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 8, the first paragraph: 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the startTime specified is 
earlier then the log can 
support,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^^^^<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'then' should be 
'than'.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 11, Sec. 3.1.2: The indent of elements are untidy. This 
problem occurs throughout the document.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 12, Figure 4 should be Figure 2.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 22, Figure 8 should be Figure 3.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>o pg 31, Sec. 5.2, the second 
example:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The filtering criteria 
evaluation does not consist with the XPath expression.<BR>(( state | config) 
&amp; ((fault &amp; severity=critical) | (fault 
&amp;<BR>&nbsp;^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^ ^<BR>&nbsp;&nbsp; severity=major) | (fault &amp; severity = minor) | (fault 
&amp;<BR>&nbsp;&nbsp; card=Ethernet0)))</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>&lt;filter netconf:type="xpath"<BR>&nbsp;&nbsp;&nbsp; 
select="//eventEntry[(eventClass='fault' 
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
severity='minor') 
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(eventClass='fault' and severity='major') 
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(eventClass='fault' and severity='critical') 
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
(eventClass='fault' and card='Ethernet0') 
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^^<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
eventClass='state' or eventClass='config' 
]"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
^ </FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Yan</FONT></DIV></BODY></HTML>

--Boundary_(ID_dKhsAI5pcu2y2tHks3EzSg)--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 18 11:12:27 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp483-0005jd-VQ
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 11:12:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hp482-0004yu-Iq
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 11:12:27 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hp40f-000G0O-L1
	for netconf-data@psg.com; Fri, 18 May 2007 15:04:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hp40c-000Fzw-7I
	for netconf@ops.ietf.org; Fri, 18 May 2007 15:04:48 +0000
Received: (qmail 25840 invoked from network); 18 May 2007 15:04:45 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp103.sbc.mail.mud.yahoo.com with SMTP; 18 May 2007 15:04:45 -0000
X-YMail-OSG: uO2KCAQVM1kMkvhjL5SWVFVEeFrzQxyXNuI7.tZD1jSX.ghoR1mXP4dRXBgPbQJpC9C_crCvd_C9J9b_OVpBBoPRtA--
Message-ID: <464DC062.7090400@andybierman.com>
Date: Fri, 18 May 2007 08:04:02 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Begin Working Group Last Call: draft-ietf-netconf-notification-07.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

Hi,

The NETCONF WG is concluding work on the NETCONF Notifications document.
The WG is urged to review the latest draft as soon as possible and send
comments to the WG mailing list:

http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-07.txt

At this time, only corrections and strong objections are being considered.

An issue with the named profiles has been raised, in which there
is concern that the <edit-config> operation cannot be implemented in
an interoperable manner for the <filter> element.

Do you think named profiles are important to keep in this document?

Do you think the edit-config interoperability problem is important?

Do you understand the XSDs?  Are they correct?

Do you understand the examples?  Are they correct?

Do you understand how new notifications in new XSDs would be defined?

Do you understand how create-subscription works with named profiles?

Do you understand how notification replay works?

Should the <notification> element allow 'anyAttribute' like the <rpc> 
element?
Currently attributes are not allowed at all in the <notification> element.

Please send your comments to the WG mailing list by June 8, 2007 at 5PM ET.

thanks,
Andy




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



From owner-netconf@ops.ietf.org Fri May 18 12:37:49 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp5Sf-0004FF-GY
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 12:37:49 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hp5Sd-0004am-58
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 12:37:49 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hp5Le-000MoH-KV
	for netconf-data@psg.com; Fri, 18 May 2007 16:30:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hp5Lb-000Mo5-IW
	for netconf@ops.ietf.org; Fri, 18 May 2007 16:30:32 +0000
Received: (qmail 89101 invoked from network); 18 May 2007 16:30:30 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp114.sbc.mail.mud.yahoo.com with SMTP; 18 May 2007 16:30:30 -0000
X-YMail-OSG: 56PzuaMVM1nsNuV9miNhyFzWzQmdqihAcUe6W6vTRj5JLxnN
Message-ID: <464DD47B.8020502@andybierman.com>
Date: Fri, 18 May 2007 09:29:47 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: correct error code
References: <464B2AA6.6070800@andybierman.com>	<20070516.184215.117699908.mbj@tail-f.com>	<464B3B7B.5000707@andybierman.com> <20070516.194316.63807660.mbj@tail-f.com>
In-Reply-To: <20070516.194316.63807660.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.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>...
>>> I think this is a clean way to handle 'any'.
>> So an operation-not-supported error gets returned instead?
> 
> I'm not sure that's the correct error code.  Compare with this case.
> Suppose a 'service' has two keys, 'ip' and 'port'.  What error message
> do you get if you send:
> 
>    <service nc:operation="create">
>      <ip>10.0.0.1</ip>
>      <port nc:operation="delete">80</port>
>      ...
>    </service>
> 

This should be operation-failed, not operation-not-supported error.


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 May 18 13:12:03 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp5zn-0004DU-QE
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 13:12:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hp5zl-0006zh-OT
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 13:12:03 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hp5uu-000PUv-GT
	for netconf-data@psg.com; Fri, 18 May 2007 17:07:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [203.200.1.48] (helo=mail.tataelxsi.co.in)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.63 (FreeBSD))
	(envelope-from <shilpab@tataelxsi.co.in>)
	id 1HoeDW-000HEp-3a
	for netconf@ops.ietf.org; Thu, 17 May 2007 11:32:23 +0000
Received: from shilpab (59.160.207.226.ill-bgl.static.vsnl.net.in [59.160.207.226] (may be forged))
	by mail.tataelxsi.co.in (MOS 3.8.3-GA)
	with ESMTP id CKM56809 (AUTH shilpab);
	Thu, 17 May 2007 17:02:17 +0530 (IST)
Reply-To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
From: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
To: <netconf@ops.ietf.org>
Subject: Plz help regarding implemetation of NETCONF over SSH
Date: Thu, 17 May 2007 17:03:48 +0530
Message-ID: <000c01c79877$3d5c0740$a021320a@telxsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in
X-Junkmail-SD-Raw: score=unknown,
	refid=str=0001.0A09020B.464C3D42.0008,ss=1,fgs=0,
	ip=59.160.207.226,
	so=2006-12-09 10:45:40,
	dmn=5.3.10/2007-02-21
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Hi,
we r implementing netconf protocol.netconf over soap is over.
now we want to implement netconf over ssh.for that we have downloaded
openssh & mindterm client,but we r not getting actually how to start.plz can
u guide me.
plz tell me if there is any good site from which i can get some help.
bye & take care.
Thanks & Regards,

Shilpa
Senior Engineer -D & -D
Tata Elxsi,Bangalore-48


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 18 14:59:32 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp7fo-0008Fd-3Z
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 14:59:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hp7fm-0000l4-5I
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 14:59:32 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hp7ao-0008K9-Ev
	for netconf-data@psg.com; Fri, 18 May 2007 18:54:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.203] (helo=smtp104.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hp7al-0008Jm-M5
	for netconf@ops.ietf.org; Fri, 18 May 2007 18:54:21 +0000
Received: (qmail 3284 invoked from network); 18 May 2007 18:54:16 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp104.sbc.mail.mud.yahoo.com with SMTP; 18 May 2007 18:54:15 -0000
X-YMail-OSG: pHhjhWsVM1ngLXI3O5junxDi5lehR2NnlZL4jUols5hLNEH9
Message-ID: <464DF62D.5040906@andybierman.com>
Date: Fri, 18 May 2007 11:53:33 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
CC:  netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH
References: <000c01c79877$3d5c0740$a021320a@telxsi.com>
In-Reply-To: <000c01c79877$3d5c0740$a021320a@telxsi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

Shilpa Jayantilal Bharkhada wrote:
> Hi,
> we r implementing netconf protocol.netconf over soap is over.
> now we want to implement netconf over ssh.for that we have downloaded
> openssh & mindterm client,but we r not getting actually how to start.plz can
> u guide me.
> plz tell me if there is any good site from which i can get some help.

I don't know of any WEB site to help you, but I can tell you
some of my implementation experience.

On the agent side, you can run a thin client as your openssh 'netconf'
subsystem, and connect to your agent process somehow to
establish the session.

On the client side, I found libssh2 much easier to use than
openssh.  Following the sftp code examples, it was pretty easy
to figure out how to connect to the netconf subsystem.

> bye & take care.
> Thanks & Regards,
> 
> Shilpa
> Senior Engineer -D & -D
> Tata Elxsi,Bangalore-48
> 

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 May 18 16:34:16 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp99U-00068o-BF
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 16:34:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hp99T-000151-1C
	for netconf-archive@lists.ietf.org; Fri, 18 May 2007 16:34:16 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hp93b-000Egt-9t
	for netconf-data@psg.com; Fri, 18 May 2007 20:28:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hp93Y-000Egf-IE
	for netconf@ops.ietf.org; Fri, 18 May 2007 20:28:10 +0000
Received: (qmail 30176 invoked from network); 18 May 2007 20:28:04 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp103.sbc.mail.mud.yahoo.com with SMTP; 18 May 2007 20:28:03 -0000
X-YMail-OSG: A4C_MIMVM1mahElvvW4Auk_DsJ60T4lgwFkLxyAk1cLOYdBK
Message-ID: <464E0C29.2090301@andybierman.com>
Date: Fri, 18 May 2007 13:27:21 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: edit-config and 'any' data type
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Hi,

Martin and I are the only ones who probably care about
this issue, but I just wanted to mention one more thing.

The edit-config operation is data-dependent.
The conceptual data structures on top of the XML can influence
how various corner cases in the protocol are handled, not to
mention the obvious differences that choices and keyed data introduce.

The 'any' data type has no such conceptual data structure
associated with it.  Operations that work on the actual
data structure are not going to work the same way when
that data structure is part of a subtree filter.

(It is like SMIv2 OPAQUE, but with an XML sub-tree instead of a string.)

I suppose it is good enough to just mention in the notifications
document that the edit-config operation on the contents of
the 'filter' sub-tree (within the namedProfile) is undefined,
and unpredictable results may occur if this is done.


Andy


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



From owner-netconf@ops.ietf.org Sun May 20 19:50:28 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HpvAS-0006lx-Lr
	for netconf-archive@lists.ietf.org; Sun, 20 May 2007 19:50:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HpvAR-0001G7-9h
	for netconf-archive@lists.ietf.org; Sun, 20 May 2007 19:50:28 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hpv2C-000G2F-Dx
	for netconf-data@psg.com; Sun, 20 May 2007 23:41:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.208] (helo=smtp109.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hpv29-000G21-M5
	for netconf@ops.ietf.org; Sun, 20 May 2007 23:41:55 +0000
Received: (qmail 54629 invoked from network); 20 May 2007 23:41:52 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp109.sbc.mail.mud.yahoo.com with SMTP; 20 May 2007 23:41:52 -0000
X-YMail-OSG: VWaItX0VM1kE4BkaFmYcqh7iWdNmaIIckDXh.dwnRng_vAAj
Message-ID: <4650DC95.40509@andybierman.com>
Date: Sun, 20 May 2007 16:41:09 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: subtree filtering: content match nodes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

Hi,

I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
with subtree filtering.

The text in the 2nd sentence explicitly states  wrt/ to
a content match node:  "it represents an exact-match filter".

I cannot find any text anywhere that mentions canonical data formats,
or schema data type conversion.  It is extremely likely that an
agent implementation will need to convert between a numeric data type
and a string representation of that data type to support this feature.

For interoperability, we should have a precise meaning of 'exact match'.

Does 'exact match' mean that the agent MUST NOT convert the
filter value to any schema-defined data type (i.e., convert number
to canonical and/or internal format, or adjust string whitespace or
convert character entities)?

Instead, the agent must compare a string representation of the internal
value to the exact filter string value.

Or is the agent allowed to convert the raw filter string to an internal
(schema defined) data type before comparing it to the value from the
target config?

IMO, the post-conversion compare is more user-friendly.

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 Mon May 21 03:03:04 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hq1v6-0003uG-Km
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 03:03:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hq1v6-0005EW-6N
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 03:03:04 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hq1lP-0006yS-Tb
	for netconf-data@psg.com; Mon, 21 May 2007 06:53:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Hq1lN-0006yD-4a
	for netconf@ops.ietf.org; Mon, 21 May 2007 06:53:02 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 459981B80C3;
	Mon, 21 May 2007 08:52:58 +0200 (CEST)
Date: Mon, 21 May 2007 08:52:40 +0200 (CEST)
Message-Id: <20070521.085240.45494485.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4650DC95.40509@andybierman.com>
References: <4650DC95.40509@andybierman.com>
X-Mailer: Mew version 5.1.51 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: 02ec665d00de228c50c93ed6b5e4fc1a

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
> with subtree filtering.
> 
> The text in the 2nd sentence explicitly states  wrt/ to
> a content match node:  "it represents an exact-match filter".
> 
> I cannot find any text anywhere that mentions canonical data formats,
> or schema data type conversion.  It is extremely likely that an
> agent implementation will need to convert between a numeric data type
> and a string representation of that data type to support this feature.
> 
> For interoperability, we should have a precise meaning of 'exact match'.
> 
> Does 'exact match' mean that the agent MUST NOT convert the
> filter value to any schema-defined data type (i.e., convert number
> to canonical and/or internal format, or adjust string whitespace or
> convert character entities)?
> 
> Instead, the agent must compare a string representation of the internal
> value to the exact filter string value.
> 
> Or is the agent allowed to convert the raw filter string to an internal
> (schema defined) data type before comparing it to the value from the
> target config?
> 
> IMO, the post-conversion compare is more user-friendly.

I fully agree.

But we also have this text in 6.2.5:

   o  Leading and trailing whitespace characters are ignored, but any
      whitespace characters within a block of text characters are not
      ignored or modified.

I think that's a mistake.  If I have a xs:string in my db which has
the value " hello ", I cannot match it with a subtree filter.  IMO, it
would have been better to not try to do whitespace adjustments, but
instead follow the normal rules imposed by the datatype.

But I guess the reason for all this is:

   The agent does not need to utilize any data-model specific
   semantics during processing, allowing for simple and centralized
   implementation strategies.


... and now instead for example it's not clear if the float '1.0'
"exactly matches" '1.00' or '1.



/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 May 21 10:44:10 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hq97K-0004Mt-0w
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 10:44:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hq97I-0008W4-Jn
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 10:44:09 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hq8xa-0008XS-I5
	for netconf-data@psg.com; Mon, 21 May 2007 14:34:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.229.96] (helo=smtp109.sbc.mail.re2.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hq8xX-0008X8-77
	for netconf@ops.ietf.org; Mon, 21 May 2007 14:34:05 +0000
Received: (qmail 91138 invoked from network); 21 May 2007 14:34:02 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp109.sbc.mail.re2.yahoo.com with SMTP; 21 May 2007 14:34:02 -0000
X-YMail-OSG: zzdQiwUVM1nOW0GO1iYykcnFSA0nAD1PG6yIbuKiaf1CvIte
Message-ID: <4651ADAF.2050902@andybierman.com>
Date: Mon, 21 May 2007 07:33:19 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
References: <4650DC95.40509@andybierman.com> <20070521.085240.45494485.mbj@tail-f.com>
In-Reply-To: <20070521.085240.45494485.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.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
>> with subtree filtering.
>>
>> The text in the 2nd sentence explicitly states  wrt/ to
>> a content match node:  "it represents an exact-match filter".
>>
>> I cannot find any text anywhere that mentions canonical data formats,
>> or schema data type conversion.  It is extremely likely that an
>> agent implementation will need to convert between a numeric data type
>> and a string representation of that data type to support this feature.
>>
>> For interoperability, we should have a precise meaning of 'exact match'.
>>
>> Does 'exact match' mean that the agent MUST NOT convert the
>> filter value to any schema-defined data type (i.e., convert number
>> to canonical and/or internal format, or adjust string whitespace or
>> convert character entities)?
>>
>> Instead, the agent must compare a string representation of the internal
>> value to the exact filter string value.
>>
>> Or is the agent allowed to convert the raw filter string to an internal
>> (schema defined) data type before comparing it to the value from the
>> target config?
>>
>> IMO, the post-conversion compare is more user-friendly.
> 
> I fully agree.
> 
> But we also have this text in 6.2.5:
> 
>    o  Leading and trailing whitespace characters are ignored, but any
>       whitespace characters within a block of text characters are not
>       ignored or modified.
> 
> I think that's a mistake.  If I have a xs:string in my db which has
> the value " hello ", I cannot match it with a subtree filter.  IMO, it
> would have been better to not try to do whitespace adjustments, but
> instead follow the normal rules imposed by the datatype.

Yes.
And the following filter cannot be given  -- &sp;hello&sp; -- because
character entities are not replaced first.  You can never search for
the '<' and '>' characters either.

> 
> But I guess the reason for all this is:
> 
>    The agent does not need to utilize any data-model specific
>    semantics during processing, allowing for simple and centralized
>    implementation strategies.
> 
> 
> ... and now instead for example it's not clear if the float '1.0'
> "exactly matches" '1.00' or '1.
> 
> 

The string "1.0" does not match "1" or "+1" or "+1.0".

> 
> /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 May 21 11:29:25 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hq9p7-0007pv-Rs
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 11:29:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hq9p7-0001aE-DN
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 11:29:25 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hq9jK-000C3j-1b
	for netconf-data@psg.com; Mon, 21 May 2007 15:23:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.209] (helo=smtp110.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hq9jH-000C3L-3o
	for netconf@ops.ietf.org; Mon, 21 May 2007 15:23:24 +0000
Received: (qmail 16756 invoked from network); 21 May 2007 15:23:22 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp110.sbc.mail.mud.yahoo.com with SMTP; 21 May 2007 15:23:21 -0000
X-YMail-OSG: dqIau6YVM1kOj_TzXnwnb2WVMKY.mgd_2WniOMh7.SfDj5vE
Message-ID: <4651B93E.6000305@andybierman.com>
Date: Mon, 21 May 2007 08:22:38 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
References: <4650DC95.40509@andybierman.com> <20070521.085240.45494485.mbj@tail-f.com>
In-Reply-To: <20070521.085240.45494485.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.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
>> with subtree filtering.
>>
>> The text in the 2nd sentence explicitly states  wrt/ to
>> a content match node:  "it represents an exact-match filter".
>>
>> I cannot find any text anywhere that mentions canonical data formats,
>> or schema data type conversion.  It is extremely likely that an
>> agent implementation will need to convert between a numeric data type
>> and a string representation of that data type to support this feature.
>>
>> For interoperability, we should have a precise meaning of 'exact match'.
>>
>> Does 'exact match' mean that the agent MUST NOT convert the
>> filter value to any schema-defined data type (i.e., convert number
>> to canonical and/or internal format, or adjust string whitespace or
>> convert character entities)?
>>
>> Instead, the agent must compare a string representation of the internal
>> value to the exact filter string value.
>>
>> Or is the agent allowed to convert the raw filter string to an internal
>> (schema defined) data type before comparing it to the value from the
>> target config?
>>
>> IMO, the post-conversion compare is more user-friendly.
> 
> I fully agree.
> 
> But we also have this text in 6.2.5:
> 
>    o  Leading and trailing whitespace characters are ignored, but any
>       whitespace characters within a block of text characters are not
>       ignored or modified.

This was put in to account for sloppy encoding like:

   <foo>
     1.0
   </foo>

Good managers will avoid introducing significant whitespace into XML content.

> 
> I think that's a mistake.  If I have a xs:string in my db which has
> the value " hello ", I cannot match it with a subtree filter.  IMO, it
> would have been better to not try to do whitespace adjustments, but
> instead follow the normal rules imposed by the datatype.
> 
> But I guess the reason for all this is:
> 
>    The agent does not need to utilize any data-model specific
>    semantics during processing, allowing for simple and centralized
>    implementation strategies.
> 
> 
> ... and now instead for example it's not clear if the float '1.0'
> "exactly matches" '1.00' or '1.
> 

I see -- the phrase 'does not need' is not the same as MUST NOT.
Good.  IMO, agents should follow the Postel Principle here, not this text.

<rant>
This is why some of us old-timers are so concerned out CLRs.
When this subtree filtering was specified, text was added
which was thought to help agent implementations.

It turns out (IMO) there are several aspects of subtree filtering
that cannot be supported without special code, and the text meant
to help is actually causing a problem instead.  Without any implementation
experience input at the time it was written, there was no reason
to suspect this would happen.

When a manager sends <foo>1.0</foo> within an edit-config operation,
it will of course be converted to the appropriate data type before it is
compared to the target (e.g., find the corresponding keyed entry,
validate and set the value).

When the same manager sends <foo>1.0</foo> within a <filter> element,
the filter may fail, depending on the exact string sent and the
agent implementation (i.e., convert internal value to string for
exact-match comparison).  Detecting bugs like this can be a nightmare.

A double whammy -- extra work for the agent and astonished, broken managers.
</rant>


> 
> 
> /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 May 21 15:40:30 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqDk6-0000bq-8k
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 15:40:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqDk3-0003zG-EQ
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 15:40:30 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqDWG-0007Mu-55
	for netconf-data@psg.com; Mon, 21 May 2007 19:26:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1HqDWB-0007Mb-RS
	for netconf@ops.ietf.org; Mon, 21 May 2007 19:26:09 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail2.sharplabs.com (Postfix) with ESMTP id CB9911E1774;
	Mon, 21 May 2007 12:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at sharplabs.com
Received: from mail2.sharplabs.com ([127.0.0.1])
	by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 2cxdR5Eo9ZZa; Mon, 21 May 2007 12:26:03 -0700 (PDT)
Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8])
	by mail2.sharplabs.com (Postfix) with ESMTP id 157E41E1791;
	Mon, 21 May 2007 12:26:02 -0700 (PDT)
Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 21 May 2007 12:26:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: subtree filtering: content match nodes
Date: Mon, 21 May 2007 12:26:02 -0700
Message-ID: <FCC7D7D1DB94054EB491EED9D274727D030F2E@wabex2.sharpamericas.com>
In-Reply-To: <4651B93E.6000305@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: subtree filtering: content match nodes
Thread-Index: AcebvSab8RR9Rm8JTCaQxEGiAOYrrwAKPDCw
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Martin Bjorklund" <mbj@tail-f.com>
Cc: <netconf@ops.ietf.org>
X-OriginalArrivalTime: 21 May 2007 19:26:02.0653 (UTC) FILETIME=[DE82A4D0:01C79BDD]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb

Hi,

IMHO - Netconf has/had no business attempting to redefine
canonical XML documents/fragments.  There's a perfectly
good existing specification "Canonical XML Version 1.0"
(RFC 3076) that got significant input from W3C experts.

Cheers,
- Ira

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

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Monday, May 21, 2007 10:23 AM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes


Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> I just read sec. 6.2.5 again in RFC 4741, and found yet another =
'concern'
>> with subtree filtering.
>>
>> The text in the 2nd sentence explicitly states  wrt/ to
>> a content match node:  "it represents an exact-match filter".
>>
>> I cannot find any text anywhere that mentions canonical data formats,
>> or schema data type conversion.  It is extremely likely that an
>> agent implementation will need to convert between a numeric data type
>> and a string representation of that data type to support this =
feature.
>>
>> For interoperability, we should have a precise meaning of 'exact =
match'.
>>
>> Does 'exact match' mean that the agent MUST NOT convert the
>> filter value to any schema-defined data type (i.e., convert number
>> to canonical and/or internal format, or adjust string whitespace or
>> convert character entities)?
>>
>> Instead, the agent must compare a string representation of the =
internal
>> value to the exact filter string value.
>>
>> Or is the agent allowed to convert the raw filter string to an =
internal
>> (schema defined) data type before comparing it to the value from the
>> target config?
>>
>> IMO, the post-conversion compare is more user-friendly.
>=20
> I fully agree.
>=20
> But we also have this text in 6.2.5:
>=20
>    o  Leading and trailing whitespace characters are ignored, but any
>       whitespace characters within a block of text characters are not
>       ignored or modified.

This was put in to account for sloppy encoding like:

   <foo>
     1.0
   </foo>

Good managers will avoid introducing significant whitespace into XML =
content.

>=20
> I think that's a mistake.  If I have a xs:string in my db which has
> the value " hello ", I cannot match it with a subtree filter.  IMO, it
> would have been better to not try to do whitespace adjustments, but
> instead follow the normal rules imposed by the datatype.
>=20
> But I guess the reason for all this is:
>=20
>    The agent does not need to utilize any data-model specific
>    semantics during processing, allowing for simple and centralized
>    implementation strategies.
>=20
>=20
> ... and now instead for example it's not clear if the float '1.0'
> "exactly matches" '1.00' or '1.
>=20

I see -- the phrase 'does not need' is not the same as MUST NOT.
Good.  IMO, agents should follow the Postel Principle here, not this =
text.

<rant>
This is why some of us old-timers are so concerned out CLRs.
When this subtree filtering was specified, text was added
which was thought to help agent implementations.

It turns out (IMO) there are several aspects of subtree filtering
that cannot be supported without special code, and the text meant
to help is actually causing a problem instead.  Without any =
implementation
experience input at the time it was written, there was no reason
to suspect this would happen.

When a manager sends <foo>1.0</foo> within an edit-config operation,
it will of course be converted to the appropriate data type before it is
compared to the target (e.g., find the corresponding keyed entry,
validate and set the value).

When the same manager sends <foo>1.0</foo> within a <filter> element,
the filter may fail, depending on the exact string sent and the
agent implementation (i.e., convert internal value to string for
exact-match comparison).  Detecting bugs like this can be a nightmare.

A double whammy -- extra work for the agent and astonished, broken =
managers.
</rant>


>=20
>=20
> /martin
>=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/>

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 =
2:01 PM
=20

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



From owner-netconf@ops.ietf.org Mon May 21 15:45:03 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqDoV-0003SL-7o
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 15:45:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqDoU-0004yT-QI
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 15:45:03 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqDgL-00083w-Jm
	for netconf-data@psg.com; Mon, 21 May 2007 19:36:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [61.144.161.54] (helo=szxga02-in.huawei.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <liyan_77@huawei.com>)
	id 1HqDgH-00083L-25
	for netconf@ops.ietf.org; Mon, 21 May 2007 19:36:35 +0000
Received: from huawei.com (szxga02-in [172.24.2.6])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0JIE00CMJP4RT0@szxga02-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 22 May 2007 03:36:28 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug
 8 2006)) with ESMTP id <0JIE00BMVP4RHN@szxga02-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 22 May 2007 03:36:27 +0800 (CST)
Received: from jys5011175 ([10.192.21.51])
 by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0JIE002D0P4L1D@szxml04-in.huawei.com> for
 netconf@ops.ietf.org; Tue, 22 May 2007 03:36:26 +0800 (CST)
Date: Tue, 22 May 2007 03:36:21 +0800
From: Li Yan <liyan_77@huawei.com>
Subject: Re: subtree filtering: content match nodes
To: Andy Bierman <ietf@andybierman.com>, Martin Bjorklund <mbj@tail-f.com>
Cc: netconf@ops.ietf.org
Message-id: <009301c79bdf$50be4e90$3315c00a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <4650DC95.40509@andybierman.com>
 <20070521.085240.45494485.mbj@tail-f.com> <4651ADAF.2050902@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

Hi,
There is no such text (like sec. 6.2.5) to describe how the XPath filter matches the leaf node content in RFC 4741.
Does XPath filtering have the same issue?

Yan

----- Original Message ----- 
From: "Andy Bierman" <ietf@andybierman.com>
To: "Martin Bjorklund" <mbj@tail-f.com>
Cc: <netconf@ops.ietf.org>
Sent: Monday, May 21, 2007 10:33 PM
Subject: Re: subtree filtering: content match nodes


Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
>> with subtree filtering.
>>
>> The text in the 2nd sentence explicitly states  wrt/ to
>> a content match node:  "it represents an exact-match filter".
>>
>> I cannot find any text anywhere that mentions canonical data formats,
>> or schema data type conversion.  It is extremely likely that an
>> agent implementation will need to convert between a numeric data type
>> and a string representation of that data type to support this feature.
>>
>> For interoperability, we should have a precise meaning of 'exact match'.
>>
>> Does 'exact match' mean that the agent MUST NOT convert the
>> filter value to any schema-defined data type (i.e., convert number
>> to canonical and/or internal format, or adjust string whitespace or
>> convert character entities)?
>>
>> Instead, the agent must compare a string representation of the internal
>> value to the exact filter string value.
>>
>> Or is the agent allowed to convert the raw filter string to an internal
>> (schema defined) data type before comparing it to the value from the
>> target config?
>>
>> IMO, the post-conversion compare is more user-friendly.
> 
> I fully agree.
> 
> But we also have this text in 6.2.5:
> 
>    o  Leading and trailing whitespace characters are ignored, but any
>       whitespace characters within a block of text characters are not
>       ignored or modified.
> 
> I think that's a mistake.  If I have a xs:string in my db which has
> the value " hello ", I cannot match it with a subtree filter.  IMO, it
> would have been better to not try to do whitespace adjustments, but
> instead follow the normal rules imposed by the datatype.

Yes.
And the following filter cannot be given  -- &sp;hello&sp; -- because
character entities are not replaced first.  You can never search for
the '<' and '>' characters either.

> 
> But I guess the reason for all this is:
> 
>    The agent does not need to utilize any data-model specific
>    semantics during processing, allowing for simple and centralized
>    implementation strategies.
> 
> 
> ... and now instead for example it's not clear if the float '1.0'
> "exactly matches" '1.00' or '1.
> 
> 

The string "1.0" does not match "1" or "+1" or "+1.0".

> 
> /martin

Andy



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

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



From owner-netconf@ops.ietf.org Mon May 21 16:05:09 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqE7x-0000ex-3W
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 16:05:09 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqE7v-0004oZ-GG
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 16:05:09 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqDrv-0009Er-EI
	for netconf-data@psg.com; Mon, 21 May 2007 19:48:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.212] (helo=smtp113.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HqDrr-0009ET-Ib
	for netconf@ops.ietf.org; Mon, 21 May 2007 19:48:33 +0000
Received: (qmail 81773 invoked from network); 21 May 2007 19:48:27 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp113.sbc.mail.mud.yahoo.com with SMTP; 21 May 2007 19:48:26 -0000
X-YMail-OSG: s2Zd4CoVM1kKCCgDhM6LSoKaxae9X2xeYq_ymDA7qVmNZX3Td3mRTvBNnFudjCODDTMlRBocgHSMKsycs.wLC3InDL7awoNs3HVL
Message-ID: <4651F75F.8060608@andybierman.com>
Date: Mon, 21 May 2007 12:47:43 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: Martin Bjorklund <mbj@tail-f.com>,  netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
References: <FCC7D7D1DB94054EB491EED9D274727D030F2E@wabex2.sharpamericas.com>
In-Reply-To: <FCC7D7D1DB94054EB491EED9D274727D030F2E@wabex2.sharpamericas.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

McDonald, Ira wrote:
> Hi,
> 
> IMHO - Netconf has/had no business attempting to redefine
> canonical XML documents/fragments.  There's a perfectly
> good existing specification "Canonical XML Version 1.0"
> (RFC 3076) that got significant input from W3C experts.
> 

You mean this document:
http://www.w3.org/TR/xml-c14n

The NETCONF WG is not redefining any aspect of this document.
I don't see any text that describes normalizing numbers.

> Cheers,
> - Ira

Andy

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



From owner-netconf@ops.ietf.org Mon May 21 16:24:08 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqEQK-000208-PP
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 16:24:08 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqEQI-00041a-ON
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 16:24:08 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqEKa-000C8w-FO
	for netconf-data@psg.com; Mon, 21 May 2007 20:18:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HqEKW-000C8Q-7c
	for netconf@ops.ietf.org; Mon, 21 May 2007 20:18:10 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 0F69F1B80C3;
	Mon, 21 May 2007 22:18:04 +0200 (CEST)
Date: Mon, 21 May 2007 22:18:02 +0200 (CEST)
Message-Id: <20070521.221802.111647745.mbj@tail-f.com>
To: liyan_77@huawei.com
Cc: ietf@andybierman.com, netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <009301c79bdf$50be4e90$3315c00a@china.huawei.com>
References: <20070521.085240.45494485.mbj@tail-f.com>
	<4651ADAF.2050902@andybierman.com>
	<009301c79bdf$50be4e90$3315c00a@china.huawei.com>
X-Mailer: Mew version 5.1.51 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Li Yan <liyan_77@huawei.com> wrote:
> Hi,
> There is no such text (like sec. 6.2.5) to describe how the XPath
> filter matches the leaf node content in RFC 4741.  Does XPath
> filtering have the same issue?

I don't think so.  XPath defines comparisons in terms of the nodes'
string-values (possibly by converting to a number).

However, what the string-value for a particular element looks like
isn't defined.  If you use XSD or RelaxNG, you probably will use the
canonical representation of the lexical value in replies to
<get>/<get-config>.  IMO, this is something a "SMI for NETCONF" has to
address.

IMO, subtree filtering should also have been defined to not be
data-model agnostic, and instead compare the canonical form. which
depends on the type.


/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 May 21 19:16:26 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqH74-0001cX-P7
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 19:16:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqH73-0006oz-9O
	for netconf-archive@lists.ietf.org; Mon, 21 May 2007 19:16:26 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqGzb-0001YV-Um
	for netconf-data@psg.com; Mon, 21 May 2007 23:08:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.208] (helo=smtp109.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HqGzY-0001Y2-Bh
	for netconf@ops.ietf.org; Mon, 21 May 2007 23:08:42 +0000
Received: (qmail 92541 invoked from network); 21 May 2007 23:08:39 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.184.135 with plain)
  by smtp109.sbc.mail.mud.yahoo.com with SMTP; 21 May 2007 23:08:39 -0000
X-YMail-OSG: pCfCK.kVM1lrT3ESojMy61y5hVG7z6QGDsS0S8Ja3g5rarqa
Message-ID: <4652264A.8010307@andybierman.com>
Date: Mon, 21 May 2007 16:07:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  liyan_77@huawei.com,  netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes
References: <20070521.085240.45494485.mbj@tail-f.com>	<4651ADAF.2050902@andybierman.com>	<009301c79bdf$50be4e90$3315c00a@china.huawei.com> <20070521.221802.111647745.mbj@tail-f.com>
In-Reply-To: <20070521.221802.111647745.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.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Martin Bjorklund wrote:
> Li Yan <liyan_77@huawei.com> wrote:
>> Hi,
>> There is no such text (like sec. 6.2.5) to describe how the XPath
>> filter matches the leaf node content in RFC 4741.  Does XPath
>> filtering have the same issue?
> 
> I don't think so.  XPath defines comparisons in terms of the nodes'
> string-values (possibly by converting to a number).
> 
> However, what the string-value for a particular element looks like
> isn't defined.  If you use XSD or RelaxNG, you probably will use the
> canonical representation of the lexical value in replies to
> <get>/<get-config>.  IMO, this is something a "SMI for NETCONF" has to
> address.
> 
> IMO, subtree filtering should also have been defined to not be
> data-model agnostic, and instead compare the canonical form. which
> depends on the type.
> 

Agreed.
My biggest concern is preventing a situation where the same XML
used in an <edit-config> works differently than when used in a <get>.

For example, if an agent accepts "1.00", "1.0", or "1", as the
value of an 'float' index component during an edit operation,
and they all resolve to the same data model entry (e.g., /foo[index=1.0]),
then those index values should also resolve to that same entry
when used in a <filter> element.


> 
> /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 Tue May 22 12:43:32 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqXSO-00021l-4j
	for netconf-archive@lists.ietf.org; Tue, 22 May 2007 12:43:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqXSM-0003vf-IR
	for netconf-archive@lists.ietf.org; Tue, 22 May 2007 12:43:32 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqXL5-000DXm-5S
	for netconf-data@psg.com; Tue, 22 May 2007 16:35:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1HqXL2-000DXM-2M
	for netconf@ops.ietf.org; Tue, 22 May 2007 16:35:57 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail2.sharplabs.com (Postfix) with ESMTP id 209471E18F8;
	Tue, 22 May 2007 09:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at sharplabs.com
Received: from mail2.sharplabs.com ([127.0.0.1])
	by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id pJmdW358EGfU; Tue, 22 May 2007 09:35:47 -0700 (PDT)
Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8])
	by mail2.sharplabs.com (Postfix) with ESMTP id 9FE991E18E3;
	Tue, 22 May 2007 09:35:47 -0700 (PDT)
Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 22 May 2007 09:35:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: subtree filtering: content match nodes
Date: Tue, 22 May 2007 09:35:46 -0700
Message-ID: <FCC7D7D1DB94054EB491EED9D274727D030F32@wabex2.sharpamericas.com>
In-Reply-To: <4651F75F.8060608@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: subtree filtering: content match nodes
Thread-Index: Aceb4QgMGrSi3w14Tp2yvG3mdnWVpgAtYpbw
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Martin Bjorklund" <mbj@tail-f.com>,
	<netconf@ops.ietf.org>
X-OriginalArrivalTime: 22 May 2007 16:35:47.0183 (UTC) FILETIME=[40075FF0:01C79C8F]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

Hi Andy,

You're right of course to cite the W3C standards-track
equivalent to RFC 3076 below - thanks.

Rooting around just now on the W3C site about XPath,
I found the following interesting documents (all of
which became full Recommendations in January 2007):

XQuery 1.0 and XPath 2.0 Formal Semantics
http://www.w3.org/TR/2007/REC-xquery-semantics-20070123/

XML Path Language (XPath) 2.0
http://www.w3.org/TR/2007/REC-xpath20-20070123/

XQuery 1.0 and XPath 2.0 Data Model (XDM)
http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/

The formal semantics spec does talk about integers and
floats in a "formal" manner that leaves me a little fuzzy.

The XDM spec also refers to normalization and canonical
forms.  I don't have the bandwidth just now to digest
them.  I'll look into them in June.

All - Note XPath/2.0 is NOT fully backwards compatible
with XPath/1.0 (which is presumably now referenced by
Netconf RFCs).  But XPath/2.0, by virtue of being
harmonized with XQuery/1.0, is presumably the right
direction for Netconf to take in looking to resolve
matching behaviour for XPath expressions.

Cheers,
- Ira

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

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Monday, May 21, 2007 2:48 PM
To: McDonald, Ira
Cc: Martin Bjorklund; netconf@ops.ietf.org
Subject: Re: subtree filtering: content match nodes


McDonald, Ira wrote:
> Hi,
>=20
> IMHO - Netconf has/had no business attempting to redefine
> canonical XML documents/fragments.  There's a perfectly
> good existing specification "Canonical XML Version 1.0"
> (RFC 3076) that got significant input from W3C experts.
>=20

You mean this document:
http://www.w3.org/TR/xml-c14n

The NETCONF WG is not redefining any aspect of this document.
I don't see any text that describes normalizing numbers.

> Cheers,
> - Ira

Andy

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 =
2:01 PM
=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 May 23 10:56:22 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqsGE-0006lB-4h
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 10:56:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqsGC-0001g6-Iz
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 10:56:22 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hqs6P-000Jr7-Vi
	for netconf-data@psg.com; Wed, 23 May 2007 14:46:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1Hqs6I-000Jqg-Es
	for netconf@ops.ietf.org; Wed, 23 May 2007 14:46:12 +0000
Received: (qmail 76084 invoked from network); 23 May 2007 14:46:03 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 23 May 2007 14:46:03 -0000
Received: (qmail 17642 invoked from network); 23 May 2007 14:46:10 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s24.loopia.se (qmail-ldap-1.03) with SMTP
          for <netconf@ops.ietf.org>; 23 May 2007 14:46:10 -0000
Message-ID: <465453B7.3090205@edgeware.tv>
Date: Wed, 23 May 2007 16:46:15 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: Attrinbute namespace
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: 30ac594df0e66ffa5a93eb4c48bcb014

What namespace does attributes such as "message-id" and "type" belong
to?  As I understand it, per default attribute belong to the anonymous
namespace.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 23 11:18:54 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hqsc2-0006rC-2Q
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:18:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hqsc0-0001G7-On
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:18:54 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqsVX-000LlX-Dv
	for netconf-data@psg.com; Wed, 23 May 2007 15:12:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1HqsVR-000LkN-1w
	for netconf@ops.ietf.org; Wed, 23 May 2007 15:12:07 +0000
Received: (qmail 95155 invoked from network); 23 May 2007 15:12:01 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 23 May 2007 15:12:01 -0000
Received: (qmail 99407 invoked from network); 23 May 2007 15:12:08 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s42.loopia.se (qmail-ldap-1.03) with SMTP
          for <netconf@ops.ietf.org>; 23 May 2007 15:12:08 -0000
Message-ID: <465459CE.6040709@edgeware.tv>
Date: Wed, 23 May 2007 17:12:14 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: Difference between get and get-config
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: 7aefe408d50e9c7c47615841cb314bed

What is the difference between get and get-config(running) with the
exception of <get/> returning device state information as well?

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 23 11:31:31 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqsoF-0007JP-0s
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:31:31 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqsoB-0003wP-Ig
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:31:31 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hqshf-000MeM-Vq
	for netconf-data@psg.com; Wed, 23 May 2007 15:24:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HqshW-000Md4-Hx
	for netconf@ops.ietf.org; Wed, 23 May 2007 15:24:35 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id DD2451B80C4;
	Wed, 23 May 2007 17:24:32 +0200 (CEST)
Date: Wed, 23 May 2007 17:24:21 +0200 (CEST)
Message-Id: <20070523.172421.93599265.mbj@tail-f.com>
To: johan.rydberg@edgeware.tv
Cc: netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <465459CE.6040709@edgeware.tv>
References: <465459CE.6040709@edgeware.tv>
X-Mailer: Mew version 5.1.51 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad

Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> What is the difference between get and get-config(running) with the
> exception of <get/> returning device state information as well?

That is the difference.


/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 May 23 11:36:22 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hqssw-0001Rn-Qi
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:36:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hqssv-0004ul-H0
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:36:22 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hqsn6-000N4I-Rk
	for netconf-data@psg.com; Wed, 23 May 2007 15:30:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1Hqsn4-000N3t-3f
	for netconf@ops.ietf.org; Wed, 23 May 2007 15:30:19 +0000
Received: (qmail 8921 invoked from network); 23 May 2007 15:30:14 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 23 May 2007 15:30:14 -0000
Received: (qmail 28886 invoked from network); 23 May 2007 15:30:21 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s42.loopia.se (qmail-ldap-1.03) with SMTP
          for <mbj@tail-f.com>; 23 May 2007 15:30:21 -0000
Message-ID: <46545E13.7090307@edgeware.tv>
Date: Wed, 23 May 2007 17:30:27 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv> <20070523.172421.93599265.mbj@tail-f.com>
In-Reply-To: <20070523.172421.93599265.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: cf4fa59384e76e63313391b70cd0dd25

Martin Bjorklund skrev:
> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>> What is the difference between get and get-config(running) with the
>> exception of <get/> returning device state information as well?
> 
> That is the difference.

Is this device state information read-only per defintion?  Or is it
possible edit it (via <edit-config/>) if the agent supports the writable
running capability?


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 23 11:40:21 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hqswn-0002pA-3l
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:40:21 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hqswj-0005iC-Q3
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:40:21 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqsqT-000NM2-Ug
	for netconf-data@psg.com; Wed, 23 May 2007 15:33:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HqsqR-000NKi-3k
	for netconf@ops.ietf.org; Wed, 23 May 2007 15:33:48 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 3E2071B80C3;
	Wed, 23 May 2007 17:33:46 +0200 (CEST)
Date: Wed, 23 May 2007 17:33:35 +0200 (CEST)
Message-Id: <20070523.173335.57925438.mbj@tail-f.com>
To: johan.rydberg@edgeware.tv
Cc: netconf@ops.ietf.org
Subject: Re: Attrinbute namespace
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <465453B7.3090205@edgeware.tv>
References: <465453B7.3090205@edgeware.tv>
X-Mailer: Mew version 5.1.51 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: 79899194edc4f33a41f49410777972f8

Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> What namespace does attributes such as "message-id" and "type" belong
> to?  As I understand it, per default attribute belong to the anonymous
> namespace.

These attributes are local attributes (local to the rpc resp. filter
element).  They should not be prefixed, since the attributeFormDefault
is unqualified.

See e.g. http://www.rpbourret.com/xml/NamespacesFAQ.htm for an
in-depth discussion on XML namespaces.


/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 May 23 11:42:13 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hqsyb-00039A-Ru
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:42:13 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hqsya-00060s-IE
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 11:42:13 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hqssf-000NZT-C7
	for netconf-data@psg.com; Wed, 23 May 2007 15:36:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HqssZ-000NYi-6S
	for netconf@ops.ietf.org; Wed, 23 May 2007 15:36:04 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 610FF1B80C3;
	Wed, 23 May 2007 17:35:58 +0200 (CEST)
Date: Wed, 23 May 2007 17:35:47 +0200 (CEST)
Message-Id: <20070523.173547.119236763.mbj@tail-f.com>
To: johan.rydberg@edgeware.tv
Cc: netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <46545E13.7090307@edgeware.tv>
References: <465459CE.6040709@edgeware.tv>
	<20070523.172421.93599265.mbj@tail-f.com>
	<46545E13.7090307@edgeware.tv>
X-Mailer: Mew version 5.1.51 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: 93238566e09e6e262849b4f805833007

Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> Martin Bjorklund skrev:
> > Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> >> What is the difference between get and get-config(running) with the
> >> exception of <get/> returning device state information as well?
> > 
> > That is the difference.
> 
> Is this device state information read-only per defintion?  Or is it
> possible edit it (via <edit-config/>) if the agent supports the writable
> running capability?

<edit-config> modifies the configuration data only, not the state
data.  So from a <edit-config> perspective, the state data is
read-only.


/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 May 23 12:49:18 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hqu1W-0001Eh-5a
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 12:49:18 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hqu1U-00046p-Pm
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 12:49:18 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hqtqz-0002C2-U5
	for netconf-data@psg.com; Wed, 23 May 2007 16:38:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Hqtqx-0002Bd-5v
	for netconf@ops.ietf.org; Wed, 23 May 2007 16:38:24 +0000
Received: (qmail 13407 invoked from network); 23 May 2007 16:38:22 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp103.sbc.mail.mud.yahoo.com with SMTP; 23 May 2007 16:38:21 -0000
X-YMail-OSG: 8m6L25QVM1meTXdqB14AeQCJMv4wH9GDR7GaV9aclQhVDiX.
Message-ID: <46546DD0.607@andybierman.com>
Date: Wed, 23 May 2007 09:37:36 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  johan.rydberg@edgeware.tv,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<46545E13.7090307@edgeware.tv> <20070523.173547.119236763.mbj@tail-f.com>
In-Reply-To: <20070523.173547.119236763.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.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Martin Bjorklund wrote:
> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>> Martin Bjorklund skrev:
>>> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>>>> What is the difference between get and get-config(running) with the
>>>> exception of <get/> returning device state information as well?
>>> That is the difference.
>> Is this device state information read-only per defintion?  Or is it
>> possible edit it (via <edit-config/>) if the agent supports the writable
>> running capability?
> 
> <edit-config> modifies the configuration data only, not the state
> data.  So from a <edit-config> perspective, the state data is
> read-only.
> 
> 

Also, if the non-volatile <startup> config is supported,
then an explicit <copy-config> (from <running> to <startup>) is
needed to update the NV storage contents.  The agent will copy
only the config data (like <get-config>) with this operation.

It may not be clear in the RFC that <copy-config> works the
same way as <get-config>.

If there are read-only 'state' data objects mixed in with
configuration data (in the agent), they are simply skipped
when generating the XML output.  The agent must know somehow
(outside the standard) what to filter out.


> /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 Wed May 23 14:28:03 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqvZ5-0006jC-PK
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 14:28:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqvZ4-0001x7-FV
	for netconf-archive@lists.ietf.org; Wed, 23 May 2007 14:28:03 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HqvSw-0009B4-3O
	for netconf-data@psg.com; Wed, 23 May 2007 18:21:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.212] (helo=smtp113.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HqvSr-0009Ah-3q
	for netconf@ops.ietf.org; Wed, 23 May 2007 18:21:40 +0000
Received: (qmail 64663 invoked from network); 23 May 2007 18:21:36 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp113.sbc.mail.mud.yahoo.com with SMTP; 23 May 2007 18:21:35 -0000
X-YMail-OSG: w19PQi0VM1mZj1Su9jQjuIzhuk3Gis6UFzb247pU8UtrH6Qo
Message-ID: <46548604.4010608@andybierman.com>
Date: Wed, 23 May 2007 11:20:52 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: NETCONF WG meeting at IETF #69
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

Hi,

The NETCONF WG is currently scheduled for a 1 hour meeting
on Tuesday, July 24th.  We will only discuss the NETCONF Notifications
draft this time.  Any NETCONF data modeling issues will need to be
discussed at BoFs from now on.

Please send your review comments to the mailing list ASAP
so an issues list can be created, and hopefully addressed
on the mailing list before the meeting.

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 May 24 07:46:47 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrBmI-0004RE-OC
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 07:46:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrBmG-0000Xj-8H
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 07:46:46 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrBeq-000LfE-PT
	for netconf-data@psg.com; Thu, 24 May 2007 11:39:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1HrBen-000Lep-TT
	for netconf@ops.ietf.org; Thu, 24 May 2007 11:39:03 +0000
Received: (qmail 37541 invoked from network); 24 May 2007 11:38:46 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 24 May 2007 11:38:46 -0000
Received: (qmail 95113 invoked from network); 24 May 2007 11:38:46 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s57.loopia.se (qmail-ldap-1.03) with SMTP
          for <mbj@tail-f.com>; 24 May 2007 11:38:46 -0000
Message-ID: <46557950.9050806@edgeware.tv>
Date: Thu, 24 May 2007 13:38:56 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<46545E13.7090307@edgeware.tv> <20070523.173547.119236763.mbj@tail-f.com>
In-Reply-To: <20070523.173547.119236763.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: ea4ac80f790299f943f0a53be7e1a21a

Martin Bjorklund skrev:

>> Is this device state information read-only per defintion?  Or is it
>> possible edit it (via <edit-config/>) if the agent supports the writable
>> running capability?
> 
> <edit-config> modifies the configuration data only, not the state
> data.  So from a <edit-config> perspective, the state data is
> read-only.

Is the state data said to be part of the data model?

I'm trying to figure out what happen if the user pipes the data
unmodifed from <get/> to <edit-config(replace)> and stores it in
a configuration store.  As I see it there are three possible
outcomes;

  1. the state data is filtered out.
  2. the config and non-config data is stored in the store.
  3. yields an error.

Also, should it be possible to <validate/> a document with state data?


~j

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 24 08:26:17 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrCOX-00060g-0Q
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 08:26:17 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrCOV-0003z9-Ln
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 08:26:16 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrCHg-000NtM-Dl
	for netconf-data@psg.com; Thu, 24 May 2007 12:19:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HrCHa-000Nt8-Lf
	for netconf@ops.ietf.org; Thu, 24 May 2007 12:19:11 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 5F58B1B80C3;
	Thu, 24 May 2007 14:19:05 +0200 (CEST)
Date: Thu, 24 May 2007 14:18:47 +0200 (CEST)
Message-Id: <20070524.141847.90567218.mbj@tail-f.com>
To: johan.rydberg@edgeware.tv
Cc: netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <46557950.9050806@edgeware.tv>
References: <46545E13.7090307@edgeware.tv>
	<20070523.173547.119236763.mbj@tail-f.com>
	<46557950.9050806@edgeware.tv>
X-Mailer: Mew version 5.1.51 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: 4adaf050708fb13be3316a9eee889caa

Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> Martin Bjorklund skrev:
> 
> >> Is this device state information read-only per defintion?  Or is it
> >> possible edit it (via <edit-config/>) if the agent supports the writable
> >> running capability?
> > 
> > <edit-config> modifies the configuration data only, not the state
> > data.  So from a <edit-config> perspective, the state data is
> > read-only.
> 
> Is the state data said to be part of the data model?

Yes.


> I'm trying to figure out what happen if the user pipes the data
> unmodifed from <get/> to <edit-config(replace)> and stores it in
> a configuration store.  As I see it there are three possible
> outcomes;
> 
>   1. the state data is filtered out.
>   2. the config and non-config data is stored in the store.
>   3. yields an error.

It is an error.  You will probably get an 'unknown-element' or
'unknown-attribute' error if you try to pass state data in an
<edit-config>.

> Also, should it be possible to <validate/> a document with state data?

No.  (Follows from the above).  Also note that the <validate> command
isn't very useful for validating documents, since you can't specify
the target db in <validate>.  So <validate> of a document can not do
much more than simple syntax checks.  There's an non-standard
extension that has been discussed on the list, which adds a
'test-only' <test-option> to <edit-config> that is useful for this
kind of validation.


/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 May 24 13:59:44 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrHbE-0000tt-2u
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 13:59:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrHbC-0007Sm-1Y
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 13:59:44 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrHTG-000JVp-MH
	for netconf-data@psg.com; Thu, 24 May 2007 17:51:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.201] (helo=smtp102.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HrHTD-000JVV-Jn
	for netconf@ops.ietf.org; Thu, 24 May 2007 17:51:29 +0000
Received: (qmail 64647 invoked from network); 24 May 2007 17:51:26 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp102.sbc.mail.mud.yahoo.com with SMTP; 24 May 2007 17:51:26 -0000
X-YMail-OSG: Lo3f8SQVM1nYlx.hO23Kea6z2ND1jLCQnzu3MQVvuvZQHmI6
Message-ID: <4655D06F.8000109@andybierman.com>
Date: Thu, 24 May 2007 10:50:39 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Johan Rydberg <johan.rydberg@edgeware.tv>
CC: Martin Bjorklund <mbj@tail-f.com>,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<46545E13.7090307@edgeware.tv> <20070523.173547.119236763.mbj@tail-f.com> <46557950.9050806@edgeware.tv>
In-Reply-To: <46557950.9050806@edgeware.tv>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Johan Rydberg wrote:
> Martin Bjorklund skrev:
> 
>>> Is this device state information read-only per defintion?  Or is it
>>> possible edit it (via <edit-config/>) if the agent supports the writable
>>> running capability?
>>
>> <edit-config> modifies the configuration data only, not the state
>> data.  So from a <edit-config> perspective, the state data is
>> read-only.
> 
> Is the state data said to be part of the data model?
> 
> I'm trying to figure out what happen if the user pipes the data
> unmodifed from <get/> to <edit-config(replace)> and stores it in
> a configuration store.  As I see it there are three possible
> outcomes;
> 
>  1. the state data is filtered out.

This is what <get-config> and <copy-config> does

>  2. the config and non-config data is stored in the store.
>  3. yields an error.
> 

Yes -- an access-failed error because you are attempting
to write to read-only data

> Also, should it be possible to <validate/> a document with state data?
> 
> 
> ~j

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 May 24 21:28:22 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrObO-00084I-I5
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 21:28:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrObO-0003De-4p
	for netconf-archive@lists.ietf.org; Thu, 24 May 2007 21:28:22 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrOUN-000Js1-2J
	for netconf-data@psg.com; Fri, 25 May 2007 01:21:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1HrOUK-000JrX-F5
	for netconf@ops.ietf.org; Fri, 25 May 2007 01:21:05 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail2.sharplabs.com (Postfix) with ESMTP id 913AB1E1353;
	Thu, 24 May 2007 18:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at sharplabs.com
Received: from mail2.sharplabs.com ([127.0.0.1])
	by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id yb3QmeyewlZO; Thu, 24 May 2007 18:20:58 -0700 (PDT)
Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8])
	by mail2.sharplabs.com (Postfix) with ESMTP id 3B3E71E133B;
	Thu, 24 May 2007 18:20:58 -0700 (PDT)
Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 24 May 2007 18:20:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Difference between get and get-config
Date: Thu, 24 May 2007 18:20:57 -0700
Message-ID: <FCC7D7D1DB94054EB491EED9D274727D030F3B@wabex2.sharpamericas.com>
In-Reply-To: <4655D06F.8000109@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Difference between get and get-config
Thread-Index: AceeLbnoE89vterZTY+SMDZEf/TcZwARTYIw
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Johan Rydberg" <johan.rydberg@edgeware.tv>
Cc: "Martin Bjorklund" <mbj@tail-f.com>,
	<netconf@ops.ietf.org>
X-OriginalArrivalTime: 25 May 2007 01:20:58.0129 (UTC) FILETIME=[F2D7A810:01C79E6A]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6

Hi,

I find it disturbing (but not surprising) that Andy
and Martin suggested two different errors (and two
different underlying reasons). =20

The underspecified behavior of Netconf for various=20
error conditions will probably be a source of very
widely divergent behavior on the part of Netconf
clients - who apparently should expect just about
anything in responses and somehow always gracefully=20
cope with it.

Cheers,
- Ira

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

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Thursday, May 24, 2007 12:51 PM
To: Johan Rydberg
Cc: Martin Bjorklund; netconf@ops.ietf.org
Subject: Re: Difference between get and get-config


Johan Rydberg wrote:
> Martin Bjorklund skrev:
>=20
>>> Is this device state information read-only per defintion?  Or is it
>>> possible edit it (via <edit-config/>) if the agent supports the =
writable
>>> running capability?
>>
>> <edit-config> modifies the configuration data only, not the state
>> data.  So from a <edit-config> perspective, the state data is
>> read-only.
>=20
> Is the state data said to be part of the data model?
>=20
> I'm trying to figure out what happen if the user pipes the data
> unmodifed from <get/> to <edit-config(replace)> and stores it in
> a configuration store.  As I see it there are three possible
> outcomes;
>=20
>  1. the state data is filtered out.

This is what <get-config> and <copy-config> does

>  2. the config and non-config data is stored in the store.
>  3. yields an error.
>=20

Yes -- an access-failed error because you are attempting
to write to read-only data

> Also, should it be possible to <validate/> a document with state data?
>=20
>=20
> ~j

Andy

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

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.467 / Virus Database: 269.8.0/817 - Release Date: 5/24/2007 =
4:01 PM
=20

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



From owner-netconf@ops.ietf.org Fri May 25 02:44:10 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrTX0-00044A-Mz
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 02:44:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrTWz-0007xe-1T
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 02:44:10 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrTNi-0009SS-GX
	for netconf-data@psg.com; Fri, 25 May 2007 06:34:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HrTNe-0009Rt-It
	for netconf@ops.ietf.org; Fri, 25 May 2007 06:34:32 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 752461B80C3;
	Fri, 25 May 2007 08:34:27 +0200 (CEST)
Date: Fri, 25 May 2007 08:34:09 +0200 (CEST)
Message-Id: <20070525.083409.106703677.mbj@tail-f.com>
To: imcdonald@sharplabs.com
Cc: ietf@andybierman.com, johan.rydberg@edgeware.tv,
	netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <FCC7D7D1DB94054EB491EED9D274727D030F3B@wabex2.sharpamericas.com>
References: <4655D06F.8000109@andybierman.com>
	<FCC7D7D1DB94054EB491EED9D274727D030F3B@wabex2.sharpamericas.com>
X-Mailer: Mew version 5.1.51 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: a7d6aff76b15f3f56fcb94490e1052e4

"McDonald, Ira" <imcdonald@sharplabs.com> wrote:
> Hi,
> 
> I find it disturbing (but not surprising) that Andy
> and Martin suggested two different errors (and two
> different underlying reasons).  
> 
> The underspecified behavior of Netconf for various 
> error conditions will probably be a source of very
> widely divergent behavior on the part of Netconf
> clients - who apparently should expect just about
> anything in responses and somehow always gracefully 
> cope with it.

I agree with this.  In my generic NETCONF test suites I have comments
like this:

            # no std error message exists; accept any error


In this particular case, internally I use an error-code
'not-writable', which is then translated into the 'unknown-element',
with an <error-app-tag> of "not-writable".

'access-denied' is described as:
           Access to the requested RPC, protocol operation,
           or data model is denied because authorization failed.

  IMO, authorization didn't fail in this case.

'unknown-element' is described as:
           An unexpected element is present.

  The read-only element is unexpected (but not unknown...)


/martin

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



From owner-netconf@ops.ietf.org Fri May 25 03:37:37 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrUMj-0007Az-Eu
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 03:37:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrUMg-0000PC-Lk
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 03:37:37 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrUFn-000CMz-Nq
	for netconf-data@psg.com; Fri, 25 May 2007 07:30:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [212.201.44.23] (helo=hermes.jacobs-university.de)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <j.schoenwaelder@jacobs-university.de>)
	id 1HrTPI-0009Zg-6l
	for netconf@ops.ietf.org; Fri, 25 May 2007 06:36:13 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.jacobs-university.de (Postfix) with ESMTP id F373482A91;
	Fri, 25 May 2007 08:36:08 +0200 (CEST)
Received: from hermes.jacobs-university.de ([212.201.44.23])
 by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 27230-04; Fri, 25 May 2007 08:36:05 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 6EF8E82AC3;
	Fri, 25 May 2007 08:36:02 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
	id 418C2267135; Fri, 25 May 2007 08:36:01 +0200 (CEST)
Date: Fri, 25 May 2007 08:36:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Cc: Andy Bierman <ietf@andybierman.com>,
	Johan Rydberg <johan.rydberg@edgeware.tv>,
	Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
Message-ID: <20070525063601.GA22346@elstar.local>
Reply-To: j.schoenwaelder@jacobs-university.de
Mail-Followup-To: "McDonald, Ira" <imcdonald@sharplabs.com>,
	Andy Bierman <ietf@andybierman.com>,
	Johan Rydberg <johan.rydberg@edgeware.tv>,
	Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
References: <4655D06F.8000109@andybierman.com> <FCC7D7D1DB94054EB491EED9D274727D030F3B@wabex2.sharpamericas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FCC7D7D1DB94054EB491EED9D274727D030F3B@wabex2.sharpamericas.com>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

On Thu, May 24, 2007 at 06:20:57PM -0700, McDonald, Ira wrote:
 
> I find it disturbing (but not surprising) that Andy
> and Martin suggested two different errors (and two
> different underlying reasons).  

Ira,

it usually takes implementation experience to work out all the corner
cases attached to a protocol design. NETCONF is a Proposed Standard
and if we take our standards process as it was conceived, then finding
these sorts of inconsistencies is exactly what is expected to happen
at this stage of the protocol lifecycle. So I do not at all find this
disturbing - for me, these are encouraging signs that people are
building up decent implementation experience.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 25 08:22:15 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrYoB-0001nq-2M
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:22:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrYo9-00030x-K0
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:22:15 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrYfl-0002R5-Ew
	for netconf-data@psg.com; Fri, 25 May 2007 12:13:33 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1HrYfi-0002Qo-Fc
	for netconf@ops.ietf.org; Fri, 25 May 2007 12:13:32 +0000
Received: (qmail 58257 invoked from network); 25 May 2007 12:13:27 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 25 May 2007 12:13:27 -0000
Received: (qmail 33947 invoked from network); 25 May 2007 12:13:32 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s24.loopia.se (qmail-ldap-1.03) with SMTP
          for <mbj@tail-f.com>; 25 May 2007 12:13:32 -0000
Message-ID: <4656D2EE.4050905@edgeware.tv>
Date: Fri, 25 May 2007 14:13:34 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv> <20070523.172421.93599265.mbj@tail-f.com>
In-Reply-To: <20070523.172421.93599265.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: 8abaac9e10c826e8252866cbe6766464

Martin Bjorklund skrev:
> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>> What is the difference between get and get-config(running) with the
>> exception of <get/> returning device state information as well?
> 
> That is the difference.

Related question;

Reading the RFC I got the impression that the stores can only store a
single configuration (ie, a XML tree with data).  But extensions such
as notification and monitor introduces data parallel to the
configuration data (the 'top' node).

Also, on the NGO list Andy states the following:

   I don't use a real node called 'top'.  The <config> or <data>
   node is the conceptual 'top'.

Does this mean that the configuration data can be split in several
XML documents?  Or should the <config> and <data> nodes be treated
as part of the document [1] ?

~j

[1] http://en.wikipedia.org/wiki/Root_element


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



From owner-netconf@ops.ietf.org Fri May 25 08:53:36 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrZIW-0003Jj-4L
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:53:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrZIT-0007b1-Pr
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:53:36 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrZDv-0004ND-Qu
	for netconf-data@psg.com; Fri, 25 May 2007 12:48:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1HrZDt-0004Mv-6I
	for netconf@ops.ietf.org; Fri, 25 May 2007 12:48:50 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id AD98C1B80C3;
	Fri, 25 May 2007 14:48:47 +0200 (CEST)
Date: Fri, 25 May 2007 14:48:29 +0200 (CEST)
Message-Id: <20070525.144829.15269587.mbj@tail-f.com>
To: johan.rydberg@edgeware.tv
Cc: netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4656D2EE.4050905@edgeware.tv>
References: <465459CE.6040709@edgeware.tv>
	<20070523.172421.93599265.mbj@tail-f.com>
	<4656D2EE.4050905@edgeware.tv>
X-Mailer: Mew version 5.1.51 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: c1c65599517f9ac32519d043c37c5336

Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> Martin Bjorklund skrev:
> > Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
> >> What is the difference between get and get-config(running) with the
> >> exception of <get/> returning device state information as well?
> > 
> > That is the difference.
> 
> Related question;
> 
> Reading the RFC I got the impression that the stores can only store a
> single configuration (ie, a XML tree with data).  But extensions such
> as notification and monitor introduces data parallel to the
> configuration data (the 'top' node).
> 
> Also, on the NGO list Andy states the following:
> 
>    I don't use a real node called 'top'.  The <config> or <data>
>    node is the conceptual 'top'.
> 
> Does this mean that the configuration data can be split in several
> XML documents? 

Yes, in the sense that you can get e.g.

  <data>
    <interface xmlns="http://example.com/ns/interface">
       ...
    </interface>
    <system xmlns="http://example.com/ns/system">
       ...
    </system>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
       ...
    </eventStreams>
  </data>
    
Each of these can be viewed as a separate XML document if you wish.



/martin

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



From owner-netconf@ops.ietf.org Fri May 25 08:56:14 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrZL4-0006Mc-2s
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:56:14 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrZL1-00086E-O1
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 08:56:14 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrZGw-0004bU-H6
	for netconf-data@psg.com; Fri, 25 May 2007 12:51:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1HrZGt-0004aZ-9R
	for netconf@ops.ietf.org; Fri, 25 May 2007 12:51:56 +0000
Received: (qmail 90283 invoked from network); 25 May 2007 12:51:48 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 25 May 2007 12:51:48 -0000
Received: (qmail 86985 invoked from network); 25 May 2007 12:51:53 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s29.loopia.se (qmail-ldap-1.03) with SMTP
          for <johan.rydberg@edgeware.tv>; 25 May 2007 12:51:53 -0000
Message-ID: <4656DBEC.8020609@edgeware.tv>
Date: Fri, 25 May 2007 14:51:56 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Johan Rydberg <johan.rydberg@edgeware.tv>
CC: Martin Bjorklund <mbj@tail-f.com>,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv> <20070523.172421.93599265.mbj@tail-f.com> <4656D2EE.4050905@edgeware.tv>
In-Reply-To: <4656D2EE.4050905@edgeware.tv>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Johan Rydberg skrev:

> Reading the RFC I got the impression that the stores can only store a
> single configuration (ie, a XML tree with data).  But extensions such
> as notification and monitor introduces data parallel to the
> configuration data (the 'top' node).

For reference, was scanning through the NETCONF RFC and found the
following statements:

   In 7.3, in regards to the source parameter to copy-config;

      Name of the configuration datastore to use as the source
      of the copy operation or the <config> element containing
      the configuration subtree to copy.

   My interpretation is that subtree means a single XML node.

   In 7.2, in regards to the config parameters to edit-config;

      A hierarchy of configuration data as defined by one of the
      device's data models. [...]

   My interpretation is that hierarchy mandates a single XML node.

In the netconf-model I-D [2], section 5.7 there is an example of a
<get/> that returns both configuration and non-configuration data.
In the example, the configuration data is contained in a <xc:config>
node.  My feeling is that is probably an error in the I-D.

~j

[2] http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-06.txt

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 25 09:03:04 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrZRg-0000Iy-JK
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 09:03:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrZRe-0001Ss-8E
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 09:03:04 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrZNW-00052o-Ms
	for netconf-data@psg.com; Fri, 25 May 2007 12:58:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.7
Received: from [194.9.94.112] (helo=s87.loopia.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <johan.rydberg@edgeware.tv>)
	id 1HrZNU-00052D-2Q
	for netconf@ops.ietf.org; Fri, 25 May 2007 12:58:45 +0000
Received: (qmail 94745 invoked from network); 25 May 2007 12:58:41 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <netconf@ops.ietf.org>; 25 May 2007 12:58:41 -0000
Received: (qmail 86982 invoked from network); 25 May 2007 12:58:41 -0000
Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46])
          (envelope-sender <johan.rydberg@edgeware.tv>)
          by s57.loopia.se (qmail-ldap-1.03) with SMTP
          for <mbj@tail-f.com>; 25 May 2007 12:58:41 -0000
Message-ID: <4656DD88.7020501@edgeware.tv>
Date: Fri, 25 May 2007 14:58:48 +0200
From: Johan Rydberg <johan.rydberg@edgeware.tv>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<4656D2EE.4050905@edgeware.tv> <20070525.144829.15269587.mbj@tail-f.com>
In-Reply-To: <20070525.144829.15269587.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: 68c8cc8a64a9d0402e43b8eee9fc4199

Martin Bjorklund skrev:

> Each of these can be viewed as a separate XML document if you wish.

In other words, a configuration datastore can store several documents?

~j

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the 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 May 25 09:56:46 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HraHe-0000nF-Jk
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 09:56:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HraHd-0002aT-5e
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 09:56:46 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HraAZ-00086C-7P
	for netconf-data@psg.com; Fri, 25 May 2007 13:49:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HraAW-00085h-LD
	for netconf@ops.ietf.org; Fri, 25 May 2007 13:49:26 +0000
Received: (qmail 98703 invoked from network); 25 May 2007 13:49:23 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp107.sbc.mail.mud.yahoo.com with SMTP; 25 May 2007 13:49:23 -0000
X-YMail-OSG: 8GAaaMgVM1lOG55kN4rjKa.rkZkBp6vbayEAofFY.NCD8Hok
Message-ID: <4656E933.9050501@andybierman.com>
Date: Fri, 25 May 2007 06:48:35 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Johan Rydberg <johan.rydberg@edgeware.tv>
CC: Martin Bjorklund <mbj@tail-f.com>,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<4656D2EE.4050905@edgeware.tv> <20070525.144829.15269587.mbj@tail-f.com> <4656DD88.7020501@edgeware.tv>
In-Reply-To: <4656DD88.7020501@edgeware.tv>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Johan Rydberg wrote:
> Martin Bjorklund skrev:
> 
>> Each of these can be viewed as a separate XML document if you wish.
> 
> In other words, a configuration datastore can store several documents?
> 

A NETCONF configuration database is not an XML instance document.
Only the NETCONF PDUs on the wire are XML instance documents.

The data root is the <config> element or the <filter> element,
which does not actually exist as part of the agent data model(s).
That is why I called it a conceptual root.

It is quite possible that different child nodes of <config> or <filter>
could be defined in different XSDs.  (The <netconf> node will be
defined in NETCONF Notifications, and proprietary nodes will be
defined elsewhere.)

When the agent does a 'copy-config', a top-level element has to
be created to hold the arbitrary number of data nodes (I call
this element <config> in my code.)  Otherwise the file written
will not be well-formed XML.  Otherwise you could not take
the output of a <get-config> or <copy-config> and use it directly
as the input to an <edit-config> operation.

Network configuration is not a document editing problem.
Use WEBDAV for that problem, not NETCONF.

> ~j

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 May 25 10:50:46 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hrb7u-000057-As
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 10:50:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hrb7s-0007uE-Hz
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 10:50:46 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrazF-000BWo-KY
	for netconf-data@psg.com; Fri, 25 May 2007 14:41:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1HrazC-000BVT-Fk
	for netconf@ops.ietf.org; Fri, 25 May 2007 14:41:48 +0000
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4446A201BA;
	Fri, 25 May 2007 16:15:52 +0200 (CEST)
X-AuditID: c1b4fb3e-b1a1dbb0000061ca-c0-4656ef98b67d 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 274362007B;
	Fri, 25 May 2007 16:15:52 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 25 May 2007 16:15:52 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 25 May 2007 16:15:51 +0200
Message-ID: <4656EF97.7040701@ericsson.com>
Date: Fri, 25 May 2007 16:15:51 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  johan.rydberg@edgeware.tv,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<4656D2EE.4050905@edgeware.tv> <20070525.144829.15269587.mbj@tail-f.com>
In-Reply-To: <20070525.144829.15269587.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2007 14:15:51.0853 (UTC) FILETIME=[3342EDD0:01C79ED7]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Hello,
Until now I interpreted this as:
The configuration will have many top nodes, one for every namespace. Or do we allow it that 
even for one namespace there will be multiple top level nodes?

Balazs

Martin Bjorklund wrote:
> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>> Martin Bjorklund skrev:
>>> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>>>> What is the difference between get and get-config(running) with the
>>>> exception of <get/> returning device state information as well?
>>> That is the difference.
>> Related question;
>>
>> Reading the RFC I got the impression that the stores can only store a
>> single configuration (ie, a XML tree with data).  But extensions such
>> as notification and monitor introduces data parallel to the
>> configuration data (the 'top' node).
>>
>> Also, on the NGO list Andy states the following:
>>
>>    I don't use a real node called 'top'.  The <config> or <data>
>>    node is the conceptual 'top'.
>>
>> Does this mean that the configuration data can be split in several
>> XML documents? 
> 
> Yes, in the sense that you can get e.g.
> 
>   <data>
>     <interface xmlns="http://example.com/ns/interface">
>        ...
>     </interface>
>     <system xmlns="http://example.com/ns/system">
>        ...
>     </system>
>     <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
>        ...
>     </eventStreams>
>   </data>
>     
> Each of these can be viewed as a separate XML document if you wish.
> 
> 
> 
> /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/>

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

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



From owner-netconf@ops.ietf.org Fri May 25 11:09:34 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrbQ6-0005aJ-Sj
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 11:09:34 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrbQ5-0003wV-Gz
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 11:09:34 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrbJw-000Cpz-H8
	for netconf-data@psg.com; Fri, 25 May 2007 15:03:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.207] (helo=smtp108.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HrbJp-000Cpi-LY
	for netconf@ops.ietf.org; Fri, 25 May 2007 15:03:07 +0000
Received: (qmail 38907 invoked from network); 25 May 2007 15:03:04 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp108.sbc.mail.mud.yahoo.com with SMTP; 25 May 2007 15:03:04 -0000
X-YMail-OSG: hyBb118VM1kj1.k8dMyQU3mpj_uOUpfGpc29jKCKlU3pe9rjtTnccDStKbt7IZXF4WEl0h9kWbwvs0fQJmmxjzK6XQ--
Message-ID: <4656FA78.6050101@andybierman.com>
Date: Fri, 25 May 2007 08:02:16 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: Martin Bjorklund <mbj@tail-f.com>,  johan.rydberg@edgeware.tv, 
 netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<4656D2EE.4050905@edgeware.tv> <20070525.144829.15269587.mbj@tail-f.com> <4656EF97.7040701@ericsson.com>
In-Reply-To: <4656EF97.7040701@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.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Balazs Lengyel wrote:
> Hello,
> Until now I interpreted this as:
> The configuration will have many top nodes, one for every namespace. Or 
> do we allow it that even for one namespace there will be multiple top 
> level nodes?

XSD does not support this.
There can only be one top-level element in a given namespace.

> 
> Balazs

Andy



> 
> Martin Bjorklund wrote:
>> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>>> Martin Bjorklund skrev:
>>>> Johan Rydberg <johan.rydberg@edgeware.tv> wrote:
>>>>> What is the difference between get and get-config(running) with the
>>>>> exception of <get/> returning device state information as well?
>>>> That is the difference.
>>> Related question;
>>>
>>> Reading the RFC I got the impression that the stores can only store a
>>> single configuration (ie, a XML tree with data).  But extensions such
>>> as notification and monitor introduces data parallel to the
>>> configuration data (the 'top' node).
>>>
>>> Also, on the NGO list Andy states the following:
>>>
>>>    I don't use a real node called 'top'.  The <config> or <data>
>>>    node is the conceptual 'top'.
>>>
>>> Does this mean that the configuration data can be split in several
>>> XML documents? 
>>
>> Yes, in the sense that you can get e.g.
>>
>>   <data>
>>     <interface xmlns="http://example.com/ns/interface">
>>        ...
>>     </interface>
>>     <system xmlns="http://example.com/ns/system">
>>        ...
>>     </system>
>>     <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
>>        ...
>>     </eventStreams>
>>   </data>
>>     Each of these can be viewed as a separate XML document if you wish.
>>
>>
>>
>> /martin
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
> 


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



From owner-netconf@ops.ietf.org Fri May 25 11:10:20 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrbQq-00065y-CU
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 11:10:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HrbQp-00043n-1c
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 11:10:20 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrbMv-000D2j-1E
	for netconf-data@psg.com; Fri, 25 May 2007 15:06:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.205] (helo=smtp106.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HrbMp-000D2J-5Q
	for netconf@ops.ietf.org; Fri, 25 May 2007 15:06:15 +0000
Received: (qmail 68037 invoked from network); 25 May 2007 15:06:10 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp106.sbc.mail.mud.yahoo.com with SMTP; 25 May 2007 15:06:09 -0000
X-YMail-OSG: bHLEWygVM1nDfcI0yRZZmHhK1mSBsR31keKrbZQc3QwCfWg8
Message-ID: <4656FB31.9060106@andybierman.com>
Date: Fri, 25 May 2007 08:05:21 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>, 
 Martin Bjorklund <mbj@tail-f.com>,
  johan.rydberg@edgeware.tv,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <465459CE.6040709@edgeware.tv>	<20070523.172421.93599265.mbj@tail-f.com>	<4656D2EE.4050905@edgeware.tv> <20070525.144829.15269587.mbj@tail-f.com> <4656EF97.7040701@ericsson.com> <4656FA78.6050101@andybierman.com>
In-Reply-To: <4656FA78.6050101@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Hello,
>> Until now I interpreted this as:
>> The configuration will have many top nodes, one for every namespace. 
>> Or do we allow it that even for one namespace there will be multiple 
>> top level nodes?
> 
> XSD does not support this.
> There can only be one top-level element in a given namespace.
> 

oops -- XSD does support this, but I still think each top-level
data node should have a different namespace, as you suggest.

>>
>> Balazs
> 
> Andy


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 May 25 12:55:44 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hrd4q-0006TM-N2
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 12:55:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hrd4p-00025m-Av
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 12:55:44 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrcwC-000KLD-PX
	for netconf-data@psg.com; Fri, 25 May 2007 16:46:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [213.180.94.162] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Hrcw9-000KJw-Ix
	for netconf@ops.ietf.org; Fri, 25 May 2007 16:46:47 +0000
Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193])
	by mail.tail-f.com (Postfix) with ESMTP id 850541B80C3;
	Fri, 25 May 2007 18:46:18 +0200 (CEST)
Date: Fri, 25 May 2007 18:46:12 +0200 (CEST)
Message-Id: <20070525.184612.124050666.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: johan.rydberg@edgeware.tv, netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4656E933.9050501@andybierman.com>
References: <20070525.144829.15269587.mbj@tail-f.com>
	<4656DD88.7020501@edgeware.tv>
	<4656E933.9050501@andybierman.com>
X-Mailer: Mew version 5.1.51 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: 36c793b20164cfe75332aa66ddb21196

Andy Bierman <ietf@andybierman.com> wrote:
> Johan Rydberg wrote:
> > Martin Bjorklund skrev:
> > 
> >> Each of these can be viewed as a separate XML document if you wish.
> > 
> > In other words, a configuration datastore can store several documents?
> > 
> 
> A NETCONF configuration database is not an XML instance document.
> Only the NETCONF PDUs on the wire are XML instance documents.
> 
> The data root is the <config> element or the <filter> element,
> which does not actually exist as part of the agent data model(s).
> That is why I called it a conceptual root.
> 
> It is quite possible that different child nodes of <config> or <filter>
> could be defined in different XSDs.  (The <netconf> node will be
> defined in NETCONF Notifications, and proprietary nodes will be
> defined elsewhere.)
> 
> When the agent does a 'copy-config', a top-level element has to
> be created to hold the arbitrary number of data nodes (I call
> this element <config> in my code.)  Otherwise the file written
> will not be well-formed XML.

I do that as well, but does the rfc mandate that the file has to be
valid XML?


> Otherwise you could not take
> the output of a <get-config> or <copy-config> and use it directly
> as the input to an <edit-config> operation.

So when you do a <copy-config> to a file you get something like:

  <config xmlns="andys-namespace">
    <interface xmlns="http://example.com/ns/interface">
       ...
    </interface>
    <system xmlns="http://example.com/ns/system">
       ...
    </system>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
       ...
    </eventStreams>
  </config xmlns="andys-namespace">

Correct?  We do the same.  But with out own namespace uri :(


And then you can pipe this into a <edit-config>:

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <running/>
      </target>
      <source>
        <config>
          <config xmlns="andys-namespace">
            <interface xmlns="http://example.com/ns/interface">
              ...
            </interface>
            <system xmlns="http://example.com/ns/system">
              ...
            </system>
            <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
              ...
            </eventStreams>
          </config>
        </config>
      </source>
    </edit-config>
  
Is this correct?

We don't do that.  You'd have to remove the top-level <config> tag
from the file and do:

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <running/>
      </target>
      <source>
        <config>
          <interface xmlns="http://example.com/ns/interface">
            ...
          </interface>
          <system xmlns="http://example.com/ns/system">
            ...
          </system>
          <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
            ...
          </eventStreams>
        </config>
      </source>
    </edit-config>

IMO, it would have been nice if this top-level <config> element was in
the netconf namespace, and documented in the rfc, so that the file
content of a <copy-config> was well defined.



/martin


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



From owner-netconf@ops.ietf.org Fri May 25 13:33:04 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hrdey-0002Ph-Kq
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 13:33:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hrdex-0004G9-5E
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 13:33:04 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrdXA-000MZH-DP
	for netconf-data@psg.com; Fri, 25 May 2007 17:25:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HrdX7-000MZ3-HX
	for netconf@ops.ietf.org; Fri, 25 May 2007 17:24:58 +0000
Received: (qmail 39683 invoked from network); 25 May 2007 17:24:56 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp114.sbc.mail.mud.yahoo.com with SMTP; 25 May 2007 17:24:56 -0000
X-YMail-OSG: mXNh5.YVM1mfxg9LaIeH9NqBPIhZNpaVZeW9Ew3CwCFQLpGZMmdD3dbZ1DQncLYGxLxJyJIhutJ_rAQqoWtgFUEJzg--
Message-ID: <46571BB8.6010501@andybierman.com>
Date: Fri, 25 May 2007 10:24:08 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC:  johan.rydberg@edgeware.tv,  netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <20070525.144829.15269587.mbj@tail-f.com>	<4656DD88.7020501@edgeware.tv>	<4656E933.9050501@andybierman.com> <20070525.184612.124050666.mbj@tail-f.com>
In-Reply-To: <20070525.184612.124050666.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.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Johan Rydberg wrote:
>>> Martin Bjorklund skrev:
>>>
>>>> Each of these can be viewed as a separate XML document if you wish.
>>> In other words, a configuration datastore can store several documents?
>>>
>> A NETCONF configuration database is not an XML instance document.
>> Only the NETCONF PDUs on the wire are XML instance documents.
>>
>> The data root is the <config> element or the <filter> element,
>> which does not actually exist as part of the agent data model(s).
>> That is why I called it a conceptual root.
>>
>> It is quite possible that different child nodes of <config> or <filter>
>> could be defined in different XSDs.  (The <netconf> node will be
>> defined in NETCONF Notifications, and proprietary nodes will be
>> defined elsewhere.)
>>
>> When the agent does a 'copy-config', a top-level element has to
>> be created to hold the arbitrary number of data nodes (I call
>> this element <config> in my code.)  Otherwise the file written
>> will not be well-formed XML.
> 
> I do that as well, but does the rfc mandate that the file has to be
> valid XML?

no -- some vendors wanted text, some wanted XML, so it is
left unspecified.

> 
> 
>> Otherwise you could not take
>> the output of a <get-config> or <copy-config> and use it directly
>> as the input to an <edit-config> operation.
> 
> So when you do a <copy-config> to a file you get something like:
> 
>   <config xmlns="andys-namespace">
>     <interface xmlns="http://example.com/ns/interface">
>        ...
>     </interface>

I would put <interface> in a container <interfaces> (or maybe <IF-MIB>)

>     <system xmlns="http://example.com/ns/system">
>        ...
>     </system>
>     <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
>        ...
>     </eventStreams>

The latest draft has a <netconf> container defined.


>   </config xmlns="andys-namespace">
> 
> Correct?  We do the same.  But with out own namespace uri :(

Actually, I put the <config> element in the netconf namespace,
and each top-level container (e.g., <system>)
is an 'application node' in its own namespace.
Thus, 'netconf', 'interfaces', and 'system' can all be defined
in separate XSDs.

> 
> 
> And then you can pipe this into a <edit-config>:
> 
>   <rpc message-id="101"
>        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>     <edit-config>
>       <target>
>         <running/>
>       </target>
>       <source>
>         <config>
>           <config xmlns="andys-namespace">
>             <interface xmlns="http://example.com/ns/interface">
>               ...
>             </interface>
>             <system xmlns="http://example.com/ns/system">
>               ...
>             </system>
>             <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
>               ...
>             </eventStreams>
>           </config>
>         </config>
>       </source>
>     </edit-config>
>   
> Is this correct?


no

> 
> We don't do that.  You'd have to remove the top-level <config> tag
> from the file and do:
> 
>   <rpc message-id="101"
>        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>     <edit-config>
>       <target>
>         <running/>
>       </target>
>       <source>
>         <config>
>           <interface xmlns="http://example.com/ns/interface">
>             ...
>           </interface>
>           <system xmlns="http://example.com/ns/system">
>             ...
>           </system>
>           <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
>             ...
>           </eventStreams>
>         </config>
>       </source>
>     </edit-config>

yes -- this is what I do.
That is why I call the <config> node a conceptual root.
You have to be able to copy/translate from the conceptual internal root
to the real root (e.g., <config>) in a PDU.

> 
> IMO, it would have been nice if this top-level <config> element was in
> the netconf namespace, and documented in the rfc, so that the file
> content of a <copy-config> was well defined.
> 

Yes, well, thankfully, the IETF lets us change and correct documents.
As Juergen pointed out, the standards process does not actually
expect documents to be perfect at the time of Proposed Standard.

We are allowed to do any of 4 things (I think) wrt/ IETF Process,
subject to IETF Approval:

  1) Advance RFC 4741 to Draft Standard as-is
  2) Create a clarification-only update to RFC 4741 and advance to DS
  3) Create any update to RFC 4741 and cycle at Proposed Standard
  4) Reclassify RFC 4741 as Historic (yeah, right ;-)

Gather all the clarifications for later...

> 
> 
> /martin

Andy

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



From owner-netconf@ops.ietf.org Fri May 25 15:08:30 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hrf9K-0002vO-Dc
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 15:08:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hrf9J-00025F-1V
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 15:08:30 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hrf25-0001zE-6Z
	for netconf-data@psg.com; Fri, 25 May 2007 19:01:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1Hrf22-0001xl-JR
	for netconf@ops.ietf.org; Fri, 25 May 2007 19:00:59 +0000
Received: from 12.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12])
  by nj300815-nj-outbound.avaya.com with ESMTP; 25 May 2007 15:00:31 -0400
X-IronPort-AV: i="4.14,580,1170651600"; 
   d="scan'208"; a="20434226:sNHT54770610"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: FW: BOF Request: Netconf Extensions and Evolution
Date: Fri, 25 May 2007 21:00:16 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0406FF81@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BOF Request: Netconf Extensions and Evolution
Thread-Index: AceV/bsTZVZMo4yaSqGjesun0VoQRgHcTTgwADPF+8AAIA01EAAPvS3g
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <ops-area@ietf.org>
Cc: <ngo@ietf.org>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

 The following proposal for a BOF in Chicago was submitted by Sharon
Chisholm. A decision needs to be made in the next few days. I would
welcome comments in the next few days on ops-area@ietf.org.

Thanks and Regards,

Dan





=20

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortel.com]=20
Sent: Friday, May 25, 2007 2:44 PM
To: Romascanu, Dan (Dan)
Cc: agenda@ietf.org
Subject: BOF Request: Netconf Extensions and Evolution

Hi

Netconf Extensions and Evolution (Nee)

Mailing List: https://www1.ietf.org/mailman/listinfo/ngo

Description:=20

The NETCONF working group has successfully defined an effective and
functional protocol, but there still remain some gaps in required
functionality. This BOF will look at necessary extensions to the NETCONF
protocol with the aim to charter a working group to address them.
Extensions will focus on generally agreed to functionality that has just
not yet been defined such as fine grain locking, advertising XML Schema
(content) support, access control, etc. It will also include an XML
Schema (content) definition to enable monitoring of the Netconf
protocol. Note that the charter does not wish to dictate which Netconf
layer problems should be solved at (content, operations, etc).

Agenda:
      - Agenda Bashing and Administrivia
	- Go through proposed NETCONF updates
	    - Partial Locks
(http://www.ietf.org/internet-drafts/draft-lengyel-ngo-partial-lock-00.t
xt)
          - Advertising XML Schema availability (pending)
          - Netconf Monitoring
(http://www.ietf.org/internet-drafts/draft-chisholm-netconf-monitoring-0
0.txt)
          - Other relevant work
	- Agree on a proposed charter
      - See if there is consensus to try to form a working group


Sharon=20

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



From owner-netconf@ops.ietf.org Fri May 25 18:12:45 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hri1d-0007fl-Pf
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 18:12:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hri1c-0005G7-D8
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 18:12:45 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HrhuX-000BaV-2E
	for netconf-data@psg.com; Fri, 25 May 2007 22:05:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7
Received: from [216.65.151.51] (helo=mail2.sharplabs.com)
	by psg.com with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <imcdonald@sharplabs.com>)
	id 1HrhuU-000BZc-Cs
	for netconf@ops.ietf.org; Fri, 25 May 2007 22:05:23 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail2.sharplabs.com (Postfix) with ESMTP id 999B91E12FA;
	Fri, 25 May 2007 15:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at sharplabs.com
Received: from mail2.sharplabs.com ([127.0.0.1])
	by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id unRRAK6jVNrO; Fri, 25 May 2007 15:05:20 -0700 (PDT)
Received: from wabex1.enet.sharplabs.com (wabex1.enet.sharplabs.com [172.29.224.8])
	by mail2.sharplabs.com (Postfix) with ESMTP id 7E5E71E12F9;
	Fri, 25 May 2007 15:05:20 -0700 (PDT)
Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 25 May 2007 15:05:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Difference between get and get-config
Date: Fri, 25 May 2007 15:05:20 -0700
Message-ID: <FCC7D7D1DB94054EB491EED9D274727D030F42@wabex2.sharpamericas.com>
In-Reply-To: <46571BB8.6010501@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Difference between get and get-config
Thread-Index: Acee8xlGG776fo2DRl2LSZhmFPXaTwAK6YXg
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Martin Bjorklund" <mbj@tail-f.com>
Cc: <johan.rydberg@edgeware.tv>,
	<netconf@ops.ietf.org>
X-OriginalArrivalTime: 25 May 2007 22:05:20.0285 (UTC) FILETIME=[C8F48CD0:01C79F18]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Hi,

Andy Bierman wrote:
>
> Yes, well, thankfully, the IETF lets us change and correct documents.
> As Juergen pointed out, the standards process does not actually
> expect documents to be perfect at the time of Proposed Standard.
>
> We are allowed to do any of 4 things (I think) wrt/ IETF Process,
> subject to IETF Approval:
>
>  1) Advance RFC 4741 to Draft Standard as-is
>  2) Create a clarification-only update to RFC 4741 and advance to DS
>  3) Create any update to RFC 4741 and cycle at Proposed Standard
>  4) Reclassify RFC 4741 as Historic (yeah, right ;-)
>
> Gather all the clarifications for later...
>


About your options (1) or (2):

Well, not quite.  Once an IETF Draft Standard is approved,
that Draft Standard MUST NEVER be revised in a way that=20
breaks backward compatibility.  Also, two independent=20
implementations of a client as well as two independent=20
implementations of a server that implement EVERY operation=20
and element are necessary to advance to Draft Standard.=20
These flaky Netconf error conditions would effectively=20
preclude such advancement, even if the rest of the Netconf
protocol were bullet-proof (which it isn't).

Your option (3) would be appropriate, but cleaning up the
error conditions and all the other ambiguities should be
done before forwarding it to the IESG for last call.

Your option (4) isn't really such a joke - a clean page
might be the better approach.

IMHO - a management protocol without a data model and
complete object/attribute/element semantics is of very=20
dubious value.

Cheers,
- Ira

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

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.472 / Virus Database: 269.8.0/818 - Release Date: 5/25/2007 =
12:32 PM
=20

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



From owner-netconf@ops.ietf.org Fri May 25 18:33:22 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HriLa-0002H9-GQ
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 18:33:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HriLS-00038B-PN
	for netconf-archive@lists.ietf.org; Fri, 25 May 2007 18:33:22 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HriH3-000CtJ-6s
	for netconf-data@psg.com; Fri, 25 May 2007 22:28:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.7
Received: from [68.142.198.205] (helo=smtp106.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.63 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HriH0-000Csx-H0
	for netconf@ops.ietf.org; Fri, 25 May 2007 22:28:39 +0000
Received: (qmail 86007 invoked from network); 25 May 2007 22:28:34 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp106.sbc.mail.mud.yahoo.com with SMTP; 25 May 2007 22:28:33 -0000
X-YMail-OSG: xa7RUvgVM1lFOUTSq_MBfDCmLGismamOzwqS5cS_NuVM0ZEA
Message-ID: <465762E1.2000700@andybierman.com>
Date: Fri, 25 May 2007 15:27:45 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: Martin Bjorklund <mbj@tail-f.com>,  johan.rydberg@edgeware.tv, 
 netconf@ops.ietf.org
Subject: Re: Difference between get and get-config
References: <FCC7D7D1DB94054EB491EED9D274727D030F42@wabex2.sharpamericas.com>
In-Reply-To: <FCC7D7D1DB94054EB491EED9D274727D030F42@wabex2.sharpamericas.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

McDonald, Ira wrote:
> Hi,
> 
> Andy Bierman wrote:
>> Yes, well, thankfully, the IETF lets us change and correct documents.
>> As Juergen pointed out, the standards process does not actually
>> expect documents to be perfect at the time of Proposed Standard.
>>
>> We are allowed to do any of 4 things (I think) wrt/ IETF Process,
>> subject to IETF Approval:
>>
>>  1) Advance RFC 4741 to Draft Standard as-is
>>  2) Create a clarification-only update to RFC 4741 and advance to DS
>>  3) Create any update to RFC 4741 and cycle at Proposed Standard
>>  4) Reclassify RFC 4741 as Historic (yeah, right ;-)
>>
>> Gather all the clarifications for later...
>>
> 
> 
> About your options (1) or (2):
> 

NETCONF is at Proposed Standard status now, not Draft Standard.
I was not stating any opinion on which choice (1 - 3) is most
appropriate.  Option (3) is the easiest and most likely.
If and when the protocol reaches DS status, different options
would be available.

> Well, not quite.  Once an IETF Draft Standard is approved,
> that Draft Standard MUST NEVER be revised in a way that 
> breaks backward compatibility.  Also, two independent 
> implementations of a client as well as two independent 
> implementations of a server that implement EVERY operation 
> and element are necessary to advance to Draft Standard. 
> These flaky Netconf error conditions would effectively 
> preclude such advancement, even if the rest of the Netconf
> protocol were bullet-proof (which it isn't).
> 
> Your option (3) would be appropriate, but cleaning up the
> error conditions and all the other ambiguities should be
> done before forwarding it to the IESG for last call.
> 

The error ambiguities are due to the separation of protocol
and content layers.

> Your option (4) isn't really such a joke - a clean page
> might be the better approach.
> 

NETCONF isn't starting over because some corner-case error codes
are not spelled out for every conceivable data model that could
ever be used with the protocol.

> IMHO - a management protocol without a data model and
> complete object/attribute/element semantics is of very 
> dubious value.
> 

And yet some people are still bothering to implement the
protocol anyway, believing good proprietary solutions
will lead to good standards someday.

Data models (like those in the Notifications draft) will
get defined one or two at a time, and get fully documented
as well as possible by the WG volunteers doing the work (as usual).

There are plenty of NETCONF data modeling proposals out there already,
and all it takes to make them standards is lots of hard work.

> Cheers,
> - Ira

Andy

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



From owner-netconf@ops.ietf.org Wed May 30 10:13:31 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HtOvb-0007aI-DH
	for netconf-archive@lists.ietf.org; Wed, 30 May 2007 10:13:31 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HtOva-00027W-1c
	for netconf-archive@lists.ietf.org; Wed, 30 May 2007 10:13:31 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HtOic-000C76-8W
	for netconf-data@psg.com; Wed, 30 May 2007 14:00:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.1.8
Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com)
	by psg.com with smtp (Exim 4.67 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1HtOiQ-000C4v-Tv
	for netconf@ops.ietf.org; Wed, 30 May 2007 14:00:00 +0000
Received: (qmail 26067 invoked from network); 30 May 2007 13:59:54 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain)
  by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 May 2007 13:59:53 -0000
X-YMail-OSG: HMzFzxkVM1m4sQcmN1nh2MyI6dweQYk9cFp9arWIQT8.cqqI
Message-ID: <465D8327.5040604@andybierman.com>
Date: Wed, 30 May 2007 06:59:03 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
CC:  netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH
References: <007601c7a2a7$140ad1c0$a021320a@telxsi.com>
In-Reply-To: <007601c7a2a7$140ad1c0$a021320a@telxsi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Shilpa Jayantilal Bharkhada wrote:
> Hi Andy,
> Thnks for your input on this.We are able to write the client part of the
> implementation where a ssh client is connecting to port 22 (through a
> session and channel) and an agent side process (process a) is starting and
> waiting at port 830 to accept connections.We did the necessary configuration
> changes in /etc/ssh/sshd_config file.
> We are not able to figure out so far how to align this agent socket (process
> a) to SSH tuunnel once SSH creates this new subsystem at port 830.
> Will it be possible for you to help us how to achieve this ?

no -- this sounds like an implementation detail in the client code,
usually passed in the command line parameters to the client


> Thanking you in advance.
> With Regards,
> Shilpa
> 

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 May 30 15:49:57 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HtUBB-0001GT-VR
	for netconf-archive@lists.ietf.org; Wed, 30 May 2007 15:49:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HtUB7-0005fH-P5
	for netconf-archive@lists.ietf.org; Wed, 30 May 2007 15:49:57 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HtU3c-000GSI-H7
	for netconf-data@psg.com; Wed, 30 May 2007 19:42:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.1.8
Received: from [203.200.1.48] (helo=mail.tataelxsi.co.in)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.67 (FreeBSD))
	(envelope-from <shilpab@tataelxsi.co.in>)
	id 1HtLb3-000Lf8-Sm
	for netconf@ops.ietf.org; Wed, 30 May 2007 10:40:11 +0000
Received: from shilpab (59.160.207.226.ill-bgl.static.vsnl.net.in [59.160.207.226] (may be forged))
	by mail.tataelxsi.co.in (MOS 3.8.3-GA)
	with ESMTP id CKX56771 (AUTH shilpab);
	Wed, 30 May 2007 16:09:53 +0530 (IST)
Reply-To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
From: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
To: "'Andy Bierman'" <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
Subject: RE: Plz help regarding implemetation of NETCONF over SSH
Date: Wed, 30 May 2007 16:11:27 +0530
Message-ID: <007601c7a2a7$140ad1c0$a021320a@telxsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <464DF62D.5040906@andybierman.com>
X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in
X-Junkmail-SD-Raw: score=unknown,
	refid=str=0001.0A09020A.465D547B.00C3,ss=1,fgs=0,
	ip=59.160.207.226,
	so=2006-12-09 10:45:40,
	dmn=5.3.10/2007-02-21
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Hi Andy,
Thnks for your input on this.We are able to write the client part of the
implementation where a ssh client is connecting to port 22 (through a
session and channel) and an agent side process (process a) is starting and
waiting at port 830 to accept connections.We did the necessary configuration
changes in /etc/ssh/sshd_config file.
We are not able to figure out so far how to align this agent socket (process
a) to SSH tuunnel once SSH creates this new subsystem at port 830.
Will it be possible for you to help us how to achieve this ?
Thanking you in advance.
With Regards,
Shilpa


-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Saturday, May 19, 2007 12:24 AM
To: Shilpa Jayantilal Bharkhada
Cc: netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH


Shilpa Jayantilal Bharkhada wrote:
> Hi,
> we r implementing netconf protocol.netconf over soap is over.
> now we want to implement netconf over ssh.for that we have downloaded
> openssh & mindterm client,but we r not getting actually how to start.plz
can
> u guide me.
> plz tell me if there is any good site from which i can get some help.

I don't know of any WEB site to help you, but I can tell you
some of my implementation experience.

On the agent side, you can run a thin client as your openssh 'netconf'
subsystem, and connect to your agent process somehow to
establish the session.

On the client side, I found libssh2 much easier to use than
openssh.  Following the sftp code examples, it was pretty easy
to figure out how to connect to the netconf subsystem.

> bye & take care.
> Thanks & Regards,
>
> Shilpa
> Senior Engineer -D & -D
> Tata Elxsi,Bangalore-48
>

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 May 31 02:30:55 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HteBT-0001WT-0s
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 02:30:55 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HteBS-0002U2-Dg
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 02:30:55 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Hte3V-000L2C-VD
	for netconf-data@psg.com; Thu, 31 May 2007 06:22:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.1.8
Received: from [203.200.1.48] (helo=mail.tataelxsi.co.in)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.67 (FreeBSD))
	(envelope-from <shilpab@tataelxsi.co.in>)
	id 1HtLb3-000Lf8-Sm
	for netconf@ops.ietf.org; Wed, 30 May 2007 10:40:11 +0000
Received: from shilpab (59.160.207.226.ill-bgl.static.vsnl.net.in [59.160.207.226] (may be forged))
	by mail.tataelxsi.co.in (MOS 3.8.3-GA)
	with ESMTP id CKX56771 (AUTH shilpab);
	Wed, 30 May 2007 16:09:53 +0530 (IST)
Reply-To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
From: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
To: "'Andy Bierman'" <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
Subject: RE: Plz help regarding implemetation of NETCONF over SSH
Date: Wed, 30 May 2007 16:11:27 +0530
Message-ID: <007601c7a2a7$140ad1c0$a021320a@telxsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <464DF62D.5040906@andybierman.com>
X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in
X-Junkmail-SD-Raw: score=unknown,
	refid=str=0001.0A09020A.465D547B.00C3,ss=1,fgs=0,
	ip=59.160.207.226,
	so=2006-12-09 10:45:40,
	dmn=5.3.10/2007-02-21
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Hi Andy,
Thnks for your input on this.We are able to write the client part of the
implementation where a ssh client is connecting to port 22 (through a
session and channel) and an agent side process (process a) is starting and
waiting at port 830 to accept connections.We did the necessary configuration
changes in /etc/ssh/sshd_config file.
We are not able to figure out so far how to align this agent socket (process
a) to SSH tuunnel once SSH creates this new subsystem at port 830.
Will it be possible for you to help us how to achieve this ?
Thanking you in advance.
With Regards,
Shilpa


-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Saturday, May 19, 2007 12:24 AM
To: Shilpa Jayantilal Bharkhada
Cc: netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH


Shilpa Jayantilal Bharkhada wrote:
> Hi,
> we r implementing netconf protocol.netconf over soap is over.
> now we want to implement netconf over ssh.for that we have downloaded
> openssh & mindterm client,but we r not getting actually how to start.plz
can
> u guide me.
> plz tell me if there is any good site from which i can get some help.

I don't know of any WEB site to help you, but I can tell you
some of my implementation experience.

On the agent side, you can run a thin client as your openssh 'netconf'
subsystem, and connect to your agent process somehow to
establish the session.

On the client side, I found libssh2 much easier to use than
openssh.  Following the sftp code examples, it was pretty easy
to figure out how to connect to the netconf subsystem.

> bye & take care.
> Thanks & Regards,
>
> Shilpa
> Senior Engineer -D & -D
> Tata Elxsi,Bangalore-48
>

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 May 31 14:46:35 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HtpfP-0007U1-P6
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 14:46:35 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HtpfO-00080S-5S
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 14:46:35 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HtpW2-000ANN-MZ
	for netconf-data@psg.com; Thu, 31 May 2007 18:36:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.1.8
Received: from [203.200.1.48] (helo=mail.tataelxsi.co.in)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.67 (FreeBSD))
	(envelope-from <shilpab@tataelxsi.co.in>)
	id 1Htinu-000M3z-50
	for netconf@ops.ietf.org; Thu, 31 May 2007 11:27:00 +0000
Received: from shilpab (59.160.207.226.ill-bgl.static.vsnl.net.in [59.160.207.226] (may be forged))
	by mail.tataelxsi.co.in (MOS 3.8.3-GA)
	with ESMTP id CKY29340 (AUTH shilpab);
	Thu, 31 May 2007 16:56:42 +0530 (IST)
Reply-To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
From: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
To: "'Andy Bierman'" <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
Subject: RE: Plz help regarding implemetation of NETCONF over SSH
Date: Thu, 31 May 2007 16:58:16 +0530
Message-ID: <005b01c7a376$c90bca50$a021320a@telxsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <465D8327.5040604@andybierman.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in
X-Junkmail-SD-Raw: score=unknown,
	refid=str=0001.0A090204.465EB0F6.000D,ss=1,fgs=0,
	ip=59.160.207.226,
	so=2006-12-09 10:45:40,
	dmn=5.3.10/2007-02-21
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

Hi Andy,
Sorry to bother you again on this.

Just wanted one more clarification for this if you could help.
When ssh client is being used to create the subsystem as in "ssh -s
ourserver.com -p 830 netconf" , I understand that the ssh client is directly
connecting to the netconf subsystem agent which is starting at port 830.

Is this the correct way for the client to connect to the netconf agent or
client should always connect to port 22 i.e to sshd server (and not directly
to 830) and ssh will take care of tunnelling the communication to the agent
app at 830 ?

Kindly help to understand section 3 of the RFC 4742 from your previous
implementation experience.I will highly appreciate this.
Any help in this regards from others will also be appreciated.
Regards,
Shilpa

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Wednesday, May 30, 2007 7:29 PM
To: Shilpa Jayantilal Bharkhada
Cc: netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH


Shilpa Jayantilal Bharkhada wrote:
> Hi Andy,
> Thnks for your input on this.We are able to write the client part of the
> implementation where a ssh client is connecting to port 22 (through a
> session and channel) and an agent side process (process a) is starting and
> waiting at port 830 to accept connections.We did the necessary
configuration
> changes in /etc/ssh/sshd_config file.
> We are not able to figure out so far how to align this agent socket
(process
> a) to SSH tuunnel once SSH creates this new subsystem at port 830.
> Will it be possible for you to help us how to achieve this ?

no -- this sounds like an implementation detail in the client code,
usually passed in the command line parameters to the client


> Thanking you in advance.
> With Regards,
> Shilpa
>

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 May 31 15:25:20 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HtqGu-00080a-Pi
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 15:25:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HtqGt-000761-Ct
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 15:25:20 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Htq9f-000ERL-NT
	for netconf-data@psg.com; Thu, 31 May 2007 19:17:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.1.8
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.67 (FreeBSD))
	(envelope-from <simon.leinen@switch.ch>)
	id 1Htq9T-000EQK-F1
	for netconf@ops.ietf.org; Thu, 31 May 2007 19:17:46 +0000
Received: (from leinen@localhost)
	by diotima.switch.ch (8.14.0+Sun/8.14.0) id l4VJHUrN014706;
	Thu, 31 May 2007 21:17:30 +0200 (CEST)
X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f
From: Simon Leinen <simon.leinen@switch.ch>
To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
Cc: "'Andy Bierman'" <ietf@andybierman.com>, <netconf@ops.ietf.org>
Subject: Re: Plz help regarding implemetation of NETCONF over SSH
In-Reply-To: <005b01c7a376$c90bca50$a021320a@telxsi.com> (Shilpa Jayantilal
	Bharkhada's message of "Thu, 31 May 2007 16:58:16 +0530")
References: <005b01c7a376$c90bca50$a021320a@telxsi.com>
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`
Date: Thu, 31 May 2007 21:17:29 +0200
Message-ID: <aaabvkdcqe.fsf@switch.ch>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Shilpa Jayantilal Bharkhada writes:
> Sorry to bother you again on this.

> Just wanted one more clarification for this if you could help.  When
> ssh client is being used to create the subsystem as in "ssh -s
> ourserver.com -p 830 netconf" , I understand that the ssh client is
> directly connecting to the netconf subsystem agent which is starting
> at port 830.

> Is this the correct way for the client to connect to the netconf
> agent

Yes.

> or client should always connect to port 22 i.e to sshd server (and
> not directly to 830) and ssh will take care of tunnelling the
> communication to the agent app at 830 ?

No.  IF you have an SSH client (or client library) that can only
connect to port 22, then tunneling might be a workaround for
connecting to a NETCONF server listening on the standard port 830.
But perhaps it would be easier to just use a better SSH client/library
instead.
-- 
Simon.

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



From owner-netconf@ops.ietf.org Thu May 31 19:50:19 2007
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HtuPL-0000eD-JS
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 19:50:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HtuPJ-0002ZV-51
	for netconf-archive@lists.ietf.org; Thu, 31 May 2007 19:50:19 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1HtuFK-000CBD-DX
	for netconf-data@psg.com; Thu, 31 May 2007 23:39:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO
	autolearn=ham version=3.1.8
Received: from [212.201.44.23] (helo=hermes.jacobs-university.de)
	by psg.com with esmtp (Exim 4.67 (FreeBSD))
	(envelope-from <j.schoenwaelder@jacobs-university.de>)
	id 1HtppS-000CMD-Ch
	for netconf@ops.ietf.org; Thu, 31 May 2007 18:57:04 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 1454982DEE;
	Thu, 31 May 2007 20:56:57 +0200 (CEST)
Received: from hermes.jacobs-university.de ([212.201.44.23])
 by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 06527-07; Thu, 31 May 2007 20:56:53 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 5B3BC82AC3;
	Thu, 31 May 2007 20:56:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
	id 4D1AE270C7D; Thu, 31 May 2007 20:56:52 +0200 (CEST)
Date: Thu, 31 May 2007 20:56:52 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>
Cc: 'Andy Bierman' <ietf@andybierman.com>, netconf@ops.ietf.org
Subject: Re: Plz help regarding implemetation of NETCONF over SSH
Message-ID: <20070531185652.GB5219@elstar.local>
Reply-To: j.schoenwaelder@jacobs-university.de
Mail-Followup-To: Shilpa Jayantilal Bharkhada <shilpab@tataelxsi.co.in>,
	'Andy Bierman' <ietf@andybierman.com>, netconf@ops.ietf.org
References: <465D8327.5040604@andybierman.com> <005b01c7a376$c90bca50$a021320a@telxsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005b01c7a376$c90bca50$a021320a@telxsi.com>
User-Agent: Mutt/1.5.15 (2007-04-06)
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

On Thu, May 31, 2007 at 04:58:16PM +0530, Shilpa Jayantilal Bharkhada wrote:
 
> Just wanted one more clarification for this if you could help.
> When ssh client is being used to create the subsystem as in "ssh -s
> ourserver.com -p 830 netconf" , I understand that the ssh client is directly
> connecting to the netconf subsystem agent which is starting at port 830.

An SSH server supporting NETCONF is expected to listen on port
830. You SSH to this transport endpoint and then you invoke the
NETCONF subsystem.
 
> Is this the correct way for the client to connect to the netconf
> agent or client should always connect to port 22 i.e to sshd server
> (and not directly to 830) and ssh will take care of tunnelling the
> communication to the agent app at 830?

There is no tunneling - the client connects to port 830. I am not
sure which text in section 3 makes you believe there is some magic
tunneling involved.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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