From mbj@tail-f.com  Thu Apr  1 00:06:08 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325AA3A693A for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 00:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=0.317,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1rkJB-xIwC9 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 00:06:07 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1B61F3A6881 for <netconf@ietf.org>; Thu,  1 Apr 2010 00:06:06 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9365261600F; Thu,  1 Apr 2010 09:06:37 +0200 (CEST)
Date: Thu, 01 Apr 2010 09:06:37 +0200 (CEST)
Message-Id: <20100401.090637.88199787.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100331214017.GC3420@elstar.local>
References: <20100331205838.GB3420@elstar.local> <20100331.231158.48188998.mbj@tail-f.com> <20100331214017.GC3420@elstar.local>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 07:06:08 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, Mar 31, 2010 at 11:11:58PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > On Wed, Mar 31, 2010 at 10:45:59PM +0200, Martin Bjorklund wrote:
> > >  
> > > > This was actually what I tried to propose above.  My suggestion was
> > > > that a 4741bis server must advertise
> > > > 
> > > >   <capability>urn:ietf:params:netconf:base:1.1</capability>
> > > > 
> > > > It seems we agree so far.
> > > > 
> > > > I also proposed that the server should not advertise
> > > > 
> > > >   <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx&features=candidate,confirmed-commit,xpath,validate</capability>
> > > > 
> > > > (since it is not needed, and sort of confusing...)
> > > 
> > > Why is the later confusing? Isn't this how YANG works?
> > 
> > One thing is that the uri "urn:ietf:params:xml:ns:netconf:base:1.0"
> > actually means that the server speaks base:1.1 (the uri says 1.0, but
> > it means 1.1)
> 
> So why is the YANG namespace URI then 1.0 and not 1.1?

Because the YANG namespace statement specifies the XML namespace for
all operations.  So if we change this from the current urn:...:1.0,
a new client would have to send e.g. 

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
      ...
    </edit-config>
  </rpc>

This was proposed by Lada, in another thread.
  

> > Also, why do we need the capability uris for candidate etc if we have
> > them as features?
> 
> We need them for backward compatibility to the 1.0 capabilities.
> 
> My point is that if YANG works, we should use it. If it does not work,
> we should be concerned. My preference would be to be "as YANGish as
> possible", not "as old style NETCONFish as possible".

If we were to do a completely new version, without any concerns for
backwards compatibility, we surely would use the normal YANG
features.  The namespace would not have the version number at all,
instead we'd use the revision value; we'd have no capabilities, just
features etc.


/martin

From lhotka@cesnet.cz  Thu Apr  1 00:59:27 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7BA3A699C for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 00:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.924
X-Spam-Level: *
X-Spam-Status: No, score=1.924 tagged_above=-999 required=5 tests=[AWL=0.555,  BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLbNu3vqNTWX for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 00:59:27 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E93B23A6A0E for <netconf@ietf.org>; Thu,  1 Apr 2010 00:59:26 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 07D412CDE05B for <netconf@ietf.org>; Thu,  1 Apr 2010 09:59:58 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: netconf@ietf.org
In-Reply-To: <20100401.090637.88199787.mbj@tail-f.com>
References: <20100331205838.GB3420@elstar.local> <20100331.231158.48188998.mbj@tail-f.com> <20100331214017.GC3420@elstar.local> <20100401.090637.88199787.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Thu, 01 Apr 2010 09:59:56 +0200
Message-ID: <1270108796.18865.39.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 07:59:27 -0000

Martin Bjorklund píše v Čt 01. 04. 2010 v 09:06 +0200:
> > > One thing is that the uri "urn:ietf:params:xml:ns:netconf:base:1.0"
> > > actually means that the server speaks base:1.1 (the uri says 1.0, but
> > > it means 1.1)
> > 
> > So why is the YANG namespace URI then 1.0 and not 1.1?
> 
> Because the YANG namespace statement specifies the XML namespace for
> all operations.  So if we change this from the current urn:...:1.0,
> a new client would have to send e.g. 
> 
>   <rpc message-id="101"
>        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>     <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
>       ...
>     </edit-config>
>   </rpc>
> 
> This was proposed by Lada, in another thread.

I actually proposed to change the namespace to 1.1 for rpc layer
elements as well, which seems more straightforward. Only the hello
elements have to keep the old namespace for compatibility.

Whether or not namespace URI is the right place for encoding the
protocol version is a controversial question that has been discussed in
XML circles before. The main argument against ever changing the
namespace is that old implementations won't recognize the new URI. I
think it doesn't really apply for NETCONF because of the hello messages
- each party can only get the namespace(s) it asked for.

Given that hello was not designed with an option for sending version
info - and version number *is* already present in the namespace URI - I
think it's better to eat our own dog food. It will work the same way for
any future versions as well, even if the vocabulary really changes.

Lada


>   
> 
> > > Also, why do we need the capability uris for candidate etc if we have
> > > them as features?
> > 
> > We need them for backward compatibility to the 1.0 capabilities.
> > 
> > My point is that if YANG works, we should use it. If it does not work,
> > we should be concerned. My preference would be to be "as YANGish as
> > possible", not "as old style NETCONFish as possible".
> 
> If we were to do a completely new version, without any concerns for
> backwards compatibility, we surely would use the normal YANG
> features.  The namespace would not have the version number at all,
> instead we'd use the revision value; we'd have no capabilities, just
> features etc.
> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From andyb@iwl.com  Thu Apr  1 03:01:55 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E077A3A69E2 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 03:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.582
X-Spam-Level: 
X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=0.553,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC-Jy+TNVwbR for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 03:01:55 -0700 (PDT)
Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id EE4EF3A6A92 for <netconf@ietf.org>; Thu,  1 Apr 2010 03:01:35 -0700 (PDT)
Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B6D3BE214A0;  Thu,  1 Apr 2010 06:02:07 -0400 (EDT)
Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 79BEAE21273;  Thu,  1 Apr 2010 06:02:07 -0400 (EDT)
Message-ID: <4BB46F04.4050201@iwl.com>
Date: Thu, 01 Apr 2010 03:01:40 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "andyb@iwl.com" <andyb@iwl.com>,  "netconf@ietf.org" <netconf@ietf.org>
References: <4BB3A7CD.7030905@iwl.com> <20100331.224559.256498557.mbj@tail-f.com> <20100331205838.GB3420@elstar.local> <20100331.231158.48188998.mbj@tail-f.com> <20100331214017.GC3420@elstar.local>
In-Reply-To: <20100331214017.GC3420@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 10:01:56 -0000

Juergen Schoenwaelder wrote:
> On Wed, Mar 31, 2010 at 11:11:58PM +0200, Martin Bjorklund wrote:
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>> On Wed, Mar 31, 2010 at 10:45:59PM +0200, Martin Bjorklund wrote:
>>>  
>>>> This was actually what I tried to propose above.  My suggestion was
>>>> that a 4741bis server must advertise
>>>>
>>>>   <capability>urn:ietf:params:netconf:base:1.1</capability>
>>>>
>>>> It seems we agree so far.
>>>>
>>>> I also proposed that the server should not advertise
>>>>
>>>>   <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx&features=candidate,confirmed-commit,xpath,validate</capability>
>>>>
>>>> (since it is not needed, and sort of confusing...)
>>> Why is the later confusing? Isn't this how YANG works?
>> One thing is that the uri "urn:ietf:params:xml:ns:netconf:base:1.0"
>> actually means that the server speaks base:1.1 (the uri says 1.0, but
>> it means 1.1)
> 
> So why is the YANG namespace URI then 1.0 and not 1.1?
>  
>> Also, why do we need the capability uris for candidate etc if we have
>> them as features?
> 
> We need them for backward compatibility to the 1.0 capabilities.
> 
> My point is that if YANG works, we should use it. If it does not work,
> we should be concerned. My preference would be to be "as YANGish as
> possible", not "as old style NETCONFish as possible".
> 

My concern is that the YANG module capability MUST be predictable.
It MUST mean the same thing every time it is used.  If I have to
find the YANG module and parse it to make sure I am using the
correct module, then it is not predictable at all.

The current formula, approved by the WG and sent to the IESG,
is predictable.

IMO, the YANG formula is fine and not confusing at all.
So what if the XML namespace URI has a '1.0' in it.  That is just
legacy cruft.

The YANG features for NETCONF capabilities does not work.
The features with parameters can never be replaced.
Replacing some of the '1.0' capabilities with features
but not all of them is pointless.  Advertising ietf-netconf.yang
is pointless.  The 'base:1.1' capability already covers it.



> /js
> 

Andy

From andyb@iwl.com  Thu Apr  1 10:14:30 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49063A6AEE for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 10:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.591
X-Spam-Level: 
X-Spam-Status: No, score=0.591 tagged_above=-999 required=5 tests=[AWL=-0.688,  BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqzU6Kd7c9G8 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 10:14:29 -0700 (PDT)
Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 276A93A6A71 for <netconf@ietf.org>; Thu,  1 Apr 2010 10:13:32 -0700 (PDT)
Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9C79C2C7255D for <netconf@ietf.org>; Thu,  1 Apr 2010 13:14:04 -0400 (EDT)
Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 627A12C70E86 for <netconf@ietf.org>; Thu,  1 Apr 2010 13:14:04 -0400 (EDT)
Message-ID: <4BB4D45B.8090304@iwl.com>
Date: Thu, 01 Apr 2010 10:14:03 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 17:14:31 -0000

Hi,

Here's a capability issue list roundup.
Let's try to finish this ASAP.
Sorry if not all possible solutions are enumerated.


1) identifying the I-D or RFC
   Can we get rid of all version identifiers in capability URIs
   and use revision=yyyy-mm-dd instead?  That means we should drop
   all the stuff about :DRAFT-XX and :RFCXXXX from every YANG module
   draft, and the YANG usage guidelines draft.

   a) leave version in XML namespace and therefore change the
      YANG module XML namespace every time a new I-D or RFC
      is published.  (YANG draft says this field MUST NOT change.)
   b) remove version from XML namespace and follow
      the rule already in the YANG spec.  The module XML
      namespace will not change from release.  The revision date
      will be updated instead.

2) Base part of the URI

   A standard NETCONF protocol capability has this base part:

       urn:ietf:params:netconf:capability

   A version identifier is appropriate because there is revision parameter.

   Examples:
       urn:ietf:params:netconf:capability:candidate:1.0
       urn:ietf:params:netconf:capability:base:1.0
       urn:ietf:params:netconf:capability:base:1.1

   A standard YANG module capability has this base part:

       urn:ietf:params:xml:ns:yang

   Examples:
       urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
       urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring

   Is there any confusion or disagreement about these standard
   capability URI base parts?
   a) yes
   b) no

3) capability for ietf-netconf.yang
   Since this is YANG module, it MUST follow the YANG module
   formula, which is <namespace>?module=modname&revision=revdate

  
urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2019-02-04

   An alternative is to define a YANG extension statement
   that allows YANG authors to override the YANG module
   capability and insert a different string as the base
   part, instead of the XML namespace.

   Should the standard YANG module capability URI encoding be
   used, or should the 'capability' extension be added to
   replace the base part of the YANG module capability URI?
   a) use standard encoding
   b) add new capability extension

4) advertising features for ietf-netconf.yang
   This is a special case no matter what, because the
   protocol capabilities (like candidate:1.0) will still
   be advertised to support 1.0 clients. The :url and
   :with-defaults URIs have parameters, and can never be
   replaced by YANG features in the <hello> encoding.

   Clients still need to deal with the capability URIs
   and switching to features is not realistic.  Duplication
   is not helpful.  What if the feature set does not match
   the capability set from the same server? (Server bug I guess
   but it still complicates the client -- all pain and no gain.)

   Should a 4741bis server advertise the ietf-netconf module?
   a) yes
   b) no

5) What will 4741bis clients and servers advertise in their <hello>
   capabilities?

   a) base 1.0 + base 1.1
   b) base 1.0 + ietf-netconf YANG module URI
   c) base 1.0 + base 1.1 + ietf-netconf YANG module URI

6)  Should the new capability-changed error be controlled within
    the initial capability exchange?

   Parameter:  capability-change='true'|'false'
   default: false
   If 'true' then the server will return capability-changed errors
   to this session after a capability change.  The client must request
   a new <hello> (encoded in an <rpc-reply> of course), to clear this
condition.

   Which URI should have this parameter added?
     a) base 1.1
     b) ietf-netconf

7) Splitting with-defaults capability into 2 capabilities

   It seems to me that the with-default 'basic-mode' and 'also-supported'
   parameters are related to the protocol, not the YANG module.
   The 'module' and 'revision' parameters really apply only to
   the typedef and augment statements (because that is the scope of YANG).

   Should the YANG module capability be kept separate from
   NETCONF protocol capabilities?
     a) yes
     b) no

   If yes, should the with-defaults capability be split into 2 capabilities,
   one for the protocol behavior and 1 for the YANG module?
    a) yes
    b) no

  If yes, should a server be allowed to advertise the protocol capability
  but not support the YANG module capability?  This would allow a server
  to simply announce its basic behavior, and not support the retrieval
  of 'report-all'.
    a) yes
    b) no


Andy


From kwatsen@juniper.net  Thu Apr  1 11:53:15 2010
Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178F53A6862 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 11:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.186
X-Spam-Level: 
X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tft7Z38fMP1n for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 11:53:14 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3660F3A6816 for <netconf@ietf.org>; Thu,  1 Apr 2010 11:53:14 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKS7Trt6eLRtA2BF3avIfhi4D1mGP2RDby@postini.com; Thu, 01 Apr 2010 11:53:47 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 1 Apr 2010 11:51:50 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Date: Thu, 1 Apr 2010 11:51:49 -0700
Thread-Topic: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
Thread-Index: AcrQWfp2bxJAp4EuTZW27Qe+k9fa5gBakgdQ
Message-ID: <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local>
In-Reply-To: <20100330224012.GB1601@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 18:53:15 -0000

> If someone inserts proprietary XML attributes that cause data nodes to
> be ignored in a standard NETCONF operations, I think the semantics of
> the operation have changed.
>=20
> If our goal is interoperable standards for configuration, then we
> can't expect different implementations to do the same thing if the
> interpretation of an operation depends on proprietary XML attributes.

Agreed, but I'd assumed that the client would opt into using the attributes=
 via passing some sort of capability-defined flag into the standard operati=
ons.  Isn't that what the extensibility model is for?

Thanks,
Kent



From andyb@iwl.com  Thu Apr  1 14:34:47 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367A63A6888 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 14:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.576
X-Spam-Level: 
X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=0.559,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrnVRVMmNd2y for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 14:34:43 -0700 (PDT)
Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id C3BEC3A6819 for <netconf@ietf.org>; Thu,  1 Apr 2010 14:34:43 -0700 (PDT)
Received: from relay22.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id A4B6CC0959D; Thu,  1 Apr 2010 17:35:16 -0400 (EDT)
Received: by relay22.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E59ACC09593;  Thu,  1 Apr 2010 17:35:15 -0400 (EDT)
Message-ID: <4BB51192.2010406@iwl.com>
Date: Thu, 01 Apr 2010 14:35:14 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 21:34:47 -0000

Kent Watsen wrote:
>> If someone inserts proprietary XML attributes that cause data nodes to be ignored in a
>> standard NETCONF operations, I think the semantics of the operation have changed.
>> 
>> If our goal is interoperable standards for configuration, then we can't expect different
>> implementations to do the same thing if the interpretation of an operation depends on
>> proprietary XML attributes.
> 
> Agreed, but I'd assumed that the client would opt into using the attributes via passing some
> sort of capability-defined flag into the standard operations.  Isn't that what the extensibility
> model is for?
> 

no.

New capabilities (protocol, vendor, or YANG module) must not
contradict each other.  They are additive.

Technically, you could pepper your data models
with meta-data because the NETCONF operations are
required to work for any XML content.  Just don't use YANG.

For YANG modules advertised by the server,
(except for the anyxml data node type) there cannot
be any XML attributes returned in the NETCONF content.

There can also only be specific standard XML attributes
in the content, within an <edit-config> inline <config> element.
(Also applies to  <url> file input as well, for edit-config).


> Thanks, Kent
> 
> 
> 

Andy

From kwatsen@juniper.net  Thu Apr  1 18:23:53 2010
Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E7F3A6895 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 18:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.908
X-Spam-Level: 
X-Spam-Status: No, score=-4.908 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTI155EhOqBV for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 18:23:52 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 0B5373A6807 for <netconf@ietf.org>; Thu,  1 Apr 2010 18:23:51 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS7VHRWAaGlI4Pg23A8ebumphQe6pt1WG@postini.com; Thu, 01 Apr 2010 18:24:25 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 1 Apr 2010 18:23:32 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: "'andyb@iwl.com'" <andyb@iwl.com>
Date: Thu, 1 Apr 2010 18:23:31 -0700
Thread-Topic: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
Thread-Index: AcrR4zleZ2NVg5VpQNyVy3k5r5o3eQAA2OMA
Message-ID: <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com>
In-Reply-To: <4BB51192.2010406@iwl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 01:23:53 -0000

> New capabilities (protocol, vendor, or YANG module) must not
> contradict each other.  They are additive.

I think we're saying the same thing.  In this case, the module adds new syn=
tax that MUST be used in order to trigger the new behavior.



> Technically, you could pepper your data models
> with meta-data because the NETCONF operations are
> required to work for any XML content.  Just don't use YANG.

To alleviate any confusion, we're not hoping to use attributes for data; we=
'd only use them for metadata and processing directives.  As mentioned in A=
naheim, I'll be submitting I-Ds for these things soon enough, so the WG can=
 discuss details then



> For YANG modules advertised by the server,
> (except for the anyxml data node type) there cannot
> be any XML attributes returned in the NETCONF content.

It's understood that the YANG syntax can't model attributes.  I guess YANG =
modules have to use prose to describe these things.  I don't know, what wou=
ld you do if you wanted to add something like yang:insert? (assuming it did=
n't already exist)



But, going back to with-defaults, I still don't see an issue with allowing =
an explicit-server to annotate its report-all output - it just adds more va=
lue.  I know it's said that attributes are not supported, but I'm still hop=
ing to understand why, when only used for metadata and processing-directive=
s (not user config)...

As for the round-tripping concern, we could either:

1. disallow these annotations in <edit-config>
  - i.e. clients MUST cull those nodes out prior to edit-config
    or else expect rpc-error

2. allow the annotations in <edit-config>, but specify that servers MUST ig=
nore the attributes
  - i.e. clients SHOULD cull those nodes out prior to edit-config
    or else server will create explicit values for those defaults)

3. allow the annotations in <edit-config> and let servers treat them like a=
 processing-directive to skip creating explicit nodes for them.=20
  - i.e. clients MAY cull those nodes prior to edit-config



Thanks,
Kent



From andyb@iwl.com  Thu Apr  1 18:52:57 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79B13A6895 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 18:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.307
X-Spam-Level: 
X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.228,  BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoa0p6PGlXC6 for <netconf@core3.amsl.com>; Thu,  1 Apr 2010 18:52:56 -0700 (PDT)
Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 5BD5B3A6A0B for <netconf@ietf.org>; Thu,  1 Apr 2010 18:52:40 -0700 (PDT)
Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 4CEB92C72561; Thu,  1 Apr 2010 21:53:13 -0400 (EDT)
Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AB3462C723F5;  Thu,  1 Apr 2010 21:53:12 -0400 (EDT)
Message-ID: <4BB54E06.8070302@iwl.com>
Date: Thu, 01 Apr 2010 18:53:10 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com> <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 01:52:57 -0000

Kent Watsen wrote:
> 
>> New capabilities (protocol, vendor, or YANG module) must not
>> contradict each other.  They are additive.
> 
> I think we're saying the same thing.  In this case, the module adds new syntax that MUST be used in order to trigger the new behavior.
> 
> 
> 
>> Technically, you could pepper your data models
>> with meta-data because the NETCONF operations are
>> required to work for any XML content.  Just don't use YANG.
> 
> To alleviate any confusion, we're not hoping to use attributes for data; we'd only use them for metadata and processing directives.  As mentioned in Anaheim, I'll be submitting I-Ds for these things soon enough, so the WG can discuss details then
> 
> 
> 
>> For YANG modules advertised by the server,
>> (except for the anyxml data node type) there cannot
>> be any XML attributes returned in the NETCONF content.
> 
> It's understood that the YANG syntax can't model attributes.  I guess YANG modules have to use prose to describe these things.  I don't know, what would you do if you wanted to add something like yang:insert? (assuming it didn't already exist)
> 
> 
> 
> But, going back to with-defaults, I still don't see an issue with allowing an explicit-server to annotate its report-all output - it just adds more value.  I know it's said that attributes are not supported, but I'm still hoping to understand why, when only used for metadata and processing-directives (not user config)...
> 
> As for the round-tripping concern, we could either:
> 
> 1. disallow these annotations in <edit-config>
>   - i.e. clients MUST cull those nodes out prior to edit-config
>     or else expect rpc-error
> 
> 2. allow the annotations in <edit-config>, but specify that servers MUST ignore the attributes
>   - i.e. clients SHOULD cull those nodes out prior to edit-config
>     or else server will create explicit values for those defaults)
> 
> 3. allow the annotations in <edit-config> and let servers treat them like a processing-directive to skip creating explicit nodes for them. 
>   - i.e. clients MAY cull those nodes prior to edit-config
> 
> 


I am not interested in adding any annotations to NETCONF PDUs.
I think the YANG modules sufficiently describe the content
and no additional standards are needed.

I do not think the NETCONF standard needs to add any support
for 'thin' clients.  That was never the intent of the with-defaults
draft.



> 
> Thanks,
> Kent
> 
> 
> 

Andy

From kwatsen@juniper.net  Mon Apr  5 09:53:52 2010
Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE933A68F8 for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 09:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEmUAVJQ03vJ for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 09:53:52 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E9A6A3A686C for <netconf@ietf.org>; Mon,  5 Apr 2010 09:53:51 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS7oVkOXeOVWJ9RQ1epsoQqPBQ02e9PVG@postini.com; Mon, 05 Apr 2010 09:53:50 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 5 Apr 2010 09:51:41 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: "'andyb@iwl.com'" <andyb@iwl.com>
Date: Mon, 5 Apr 2010 09:51:41 -0700
Thread-Topic: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
Thread-Index: AcrSB0JnjMjHfFEfS+qfhy5/cxTRlwCyhsbg
Message-ID: <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com> <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net> <4BB54E06.8070302@iwl.com>
In-Reply-To: <4BB54E06.8070302@iwl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2010 16:53:52 -0000

=20
> I am not interested in adding any annotations to NETCONF PDUs.

That's evident, but it remains to be explained is *why* using attributes fo=
r metadata is an issue for the WG.  My guess is that this sentiment is a ho=
ldover from discussions regarding data (not metadata).   Anyone?

As another example, JUNOS allows nodes to be deactivated.  They're still in=
 the configuration, but are effectively "grayed out".  When doing a <get-co=
nfig>, we get back these nodes with an attribute inactive=3D"true".  Junipe=
r has defined a proprietary capability describing this modification to <get=
-config> as well as extensions to <edit-config> providing processing-direct=
ives to activate/deactivate configuration nodes.  We're been doing this for=
 a long time - works great!



> I think the YANG modules sufficiently describe the content
> and no additional standards are needed.

This is not always the case, sometimes the state is dynamic and thus can no=
t captured in a spec (see above active/inactive example)


=20
> I do not think the NETCONF standard needs to add any support
> for 'thin' clients.  That was never the intent of the with-defaults
> draft.

No problem.  I'm fine with only supporting schema-aware clients.  Then can =
you please remove bullet-points 3 and 4 from your Introduction as well as t=
he requirement for servers to implement report-all? =20


Thanks,
Kent


From andyb@iwl.com  Mon Apr  5 10:39:35 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415B53A67C2 for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 10:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.776
X-Spam-Level: 
X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq9RnjKxHDYZ for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 10:39:34 -0700 (PDT)
Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 3D28E3A679C for <netconf@ietf.org>; Mon,  5 Apr 2010 10:39:34 -0700 (PDT)
Received: from relay21.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 763622E401B7; Mon,  5 Apr 2010 13:39:32 -0400 (EDT)
Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 366A22E401A8;  Mon,  5 Apr 2010 13:39:32 -0400 (EDT)
Message-ID: <4BBA2069.9060605@iwl.com>
Date: Mon, 05 Apr 2010 10:39:53 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com> <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net> <4BB54E06.8070302@iwl.com> <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2010 17:39:35 -0000

Kent Watsen wrote:
> 
>> I am not interested in adding any annotations to NETCONF PDUs.
> 
> That's evident, but it remains to be explained is *why* using attributes for metadata is an
> issue for the WG.  My guess is that this sentiment is a holdover from discussions regarding data
> (not metadata).   Anyone?
> 
> As another example, JUNOS allows nodes to be deactivated.  They're still in the configuration,
> but are effectively "grayed out".  When doing a <get-config>, we get back these nodes with an
> attribute inactive="true".  Juniper has defined a proprietary capability describing this
> modification to <get-config> as well as extensions to <edit-config> providing
> processing-directives to activate/deactivate configuration nodes.  We're been doing this for a
> long time - works great!
> 
> 

The NETCONF standard does not support inactive configuration.
It does not support pre-provisioning either.  I think you
should propose a standard solution.   You should work with
Juergen (IMO) to define operational data and inactive data.

If tagging the nodes with meta-data is the preferred solution,
after the WG agrees on the problem, then that is fine with me.

I would like a last-changed-time meta-data property, to support
a <time-filter> extension to <get> and <get-config>, since
we are piling on the wish-list.  :-)


> 
>> I think the YANG modules sufficiently describe the content and no additional standards are
>> needed.
> 
> This is not always the case, sometimes the state is dynamic and thus can not captured in a spec
> (see above active/inactive example)
> 
> 
> 
>> I do not think the NETCONF standard needs to add any support for 'thin' clients.  That was
>> never the intent of the with-defaults draft.
> 
> No problem.  I'm fine with only supporting schema-aware clients.  Then can you please remove
> bullet-points 3 and 4 from your Introduction as well as the requirement for servers to implement
> report-all?
> 

I do not see why.

The WG decided that if the client really cared which nodes were
explicitly set, it should just use with-defaults=explicit.

There is an expectation that a client can retrieve a config
with <get-config> and hand it back to the server in <edit-config>
or <copy-config> without making any changes to it.

As long as that remains true, you can add any XML attributes
to your own data models that you want.  Standard YANG data models
cannot have any proprietary XML attributes in them though.


> 
> Thanks, Kent
> 
> 

Andy

From kwatsen@juniper.net  Mon Apr  5 17:30:53 2010
Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24633A67C1 for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 17:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level: 
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcAO441xyzB0 for <netconf@core3.amsl.com>; Mon,  5 Apr 2010 17:30:52 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id D4FEE3A69FB for <netconf@ietf.org>; Mon,  5 Apr 2010 17:30:50 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS7qAtPY2nwuOl6CUrFCi2X6ch3eoNePN@postini.com; Mon, 05 Apr 2010 17:30:49 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 5 Apr 2010 17:26:29 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: "'andyb@iwl.com'" <andyb@iwl.com>
Date: Mon, 5 Apr 2010 17:26:29 -0700
Thread-Topic: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
Thread-Index: AcrU5vY3dBFh2z5NTwCFGBqRyPI2vgACYVAg
Message-ID: <84600D05C20FF943918238042D7670FD368B467E07@EMBX01-HQ.jnpr.net>
References: <20100328001507.87FB43A6A0E@core3.amsl.com> <84600D05C20FF943918238042D7670FD368B467DC5@EMBX01-HQ.jnpr.net> <4BB12AEE.7060201@iwl.com> <84600D05C20FF943918238042D7670FD368B467DC8@EMBX01-HQ.jnpr.net> <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com> <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net> <4BB54E06.8070302@iwl.com> <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net> <4BBA2069.9060605@iwl.com>
In-Reply-To: <4BBA2069.9060605@iwl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 00:30:53 -0000

Andy,

I greatly appreciate your input on this



> The NETCONF standard does not support inactive configuration.
> It does not support pre-provisioning either.  I think you
> should propose a standard solution.   You should work with
> Juergen (IMO) to define operational data and inactive data.
>
> If tagging the nodes with meta-data is the preferred solution,
> after the WG agrees on the problem, then that is fine with me.
>
> I would like a last-changed-time meta-data property, to support
> a <time-filter> extension to <get> and <get-config>, since
> we are piling on the wish-list.  :-)

Yup, we have this one too ;)

I don't intend to submit an I-D for inactive-configuration just now (maybe =
later this year) - I was just trying to show by example how using attribute=
s for metadata is good

Sounds like you're OK with using attributes for metadata in principle, whic=
h is all I was after.   Since no one else is chiming in here, I'll conclude=
 that the concern for attributes was/is limited to data and that a concern =
for using attributes for metadata has never been defined.

=20

> The WG decided that if the client really cared which nodes were
> explicitly set, it should just use with-defaults=3Dexplicit.

Well, that is going to be the basic-mode for any explicit server, so really=
 the question is when would a schema-aware client ever NOT ask for report-a=
ll?  - I'm thinking never.  Perhaps it could be use to verify the accuracy =
of the vendor's schema, but that is really an activity the vendor must do p=
rior to publishing their schema.  Vendors MUST validate the accuracy of the=
ir schema.



> There is an expectation that a client can retrieve a config
> with <get-config> and hand it back to the server in <edit-config>
> or <copy-config> without making any changes to it.

I completely agree with this goal, and want to ratchet it up a little by ad=
ding that, when handed back, the server's final state is the same as it was=
 when <get-config> was called.  Reasonable, isn't it?

But this is not the case when an explicit server is given the report-all co=
nfig.  I know you said that clients should know better than to do that, but=
 there are pathological cases that *will arise* and the negative impact on =
an explicit server is significant.  As a vendor that implements explicit co=
nfig (how many others are there?), the downside risks seem to outweigh any =
value report-all (w/o tagging) adds



> As long as that remains true, you can add any XML attributes
> to your own data models that you want.  Standard YANG data models
> cannot have any proprietary XML attributes in them though.
=20
One thing I'm not clear on is the extent that a YANG module definition must=
 itself use YANG - specifically for protocol modifications.  For instance, =
the with-defaults I-D has YANG statements like:

    augment /nc:get-config/nc:input {
        uses with-defaults-parameters;
    }

Are these *required* because YANG compilers MUST be 100% data-driven?  - or=
 could this I-D have alternatively left it developer to read the RFC cited =
by the module's "reference" statement? =20


Thanks,
Kent



From mbj@tail-f.com  Tue Apr  6 01:39:59 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6AD3A6835 for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 01:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level: 
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNAC50KhXcUE for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 01:39:58 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2F7873A685A for <netconf@ietf.org>; Tue,  6 Apr 2010 01:39:56 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 73F4D76C225; Tue,  6 Apr 2010 10:39:53 +0200 (CEST)
Date: Tue, 06 Apr 2010 10:39:53 +0200 (CEST)
Message-Id: <20100406.103953.119200856.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BB4D45B.8090304@iwl.com>
References: <4BB4D45B.8090304@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 08:40:00 -0000

Hi,

Andy Bierman <andyb@iwl.com> wrote:
> Hi,
> 
> Here's a capability issue list roundup.
> Let's try to finish this ASAP.
> Sorry if not all possible solutions are enumerated.
> 
> 
> 1) identifying the I-D or RFC
>    Can we get rid of all version identifiers in capability URIs
>    and use revision=yyyy-mm-dd instead?  That means we should drop
>    all the stuff about :DRAFT-XX and :RFCXXXX from every YANG module
>    draft, and the YANG usage guidelines draft.

Yes!

>    a) leave version in XML namespace and therefore change the
>       YANG module XML namespace every time a new I-D or RFC
>       is published.  (YANG draft says this field MUST NOT change.)
>    b) remove version from XML namespace and follow
>       the rule already in the YANG spec.  The module XML
>       namespace will not change from release.  The revision date
>       will be updated instead.

b

> 2) Base part of the URI
> 
>    A standard NETCONF protocol capability has this base part:
> 
>        urn:ietf:params:netconf:capability
> 
>    A version identifier is appropriate because there is revision parameter.
> 
>    Examples:
>        urn:ietf:params:netconf:capability:candidate:1.0
>        urn:ietf:params:netconf:capability:base:1.0
>        urn:ietf:params:netconf:capability:base:1.1
> 
>    A standard YANG module capability has this base part:
> 
>        urn:ietf:params:xml:ns:yang
> 
>    Examples:
>        urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
>        urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
> 
>    Is there any confusion or disagreement about these standard
>    capability URI base parts?
>    a) yes
>    b) no

b

> 3) capability for ietf-netconf.yang
>    Since this is YANG module, it MUST follow the YANG module
>    formula, which is <namespace>?module=modname&revision=revdate
> 
>   
> urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2019-02-04
> 
>    An alternative is to define a YANG extension statement
>    that allows YANG authors to override the YANG module
>    capability and insert a different string as the base
>    part, instead of the XML namespace.
> 
>    Should the standard YANG module capability URI encoding be
>    used, or should the 'capability' extension be added to
>    replace the base part of the YANG module capability URI?
>    a) use standard encoding
>    b) add new capability extension

b (only for backwards compatibility reasons; if we did a new netconf
v2 we could do without such an extension)

> 4) advertising features for ietf-netconf.yang
>    This is a special case no matter what, because the
>    protocol capabilities (like candidate:1.0) will still
>    be advertised to support 1.0 clients. The :url and
>    :with-defaults URIs have parameters, and can never be
>    replaced by YANG features in the <hello> encoding.
> 
>    Clients still need to deal with the capability URIs
>    and switching to features is not realistic.  Duplication
>    is not helpful.  What if the feature set does not match
>    the capability set from the same server? (Server bug I guess
>    but it still complicates the client -- all pain and no gain.)
> 
>    Should a 4741bis server advertise the ietf-netconf module?
>    a) yes
>    b) no

b

> 5) What will 4741bis clients and servers advertise in their <hello>
>    capabilities?
> 
>    a) base 1.0 + base 1.1
>    b) base 1.0 + ietf-netconf YANG module URI
>    c) base 1.0 + base 1.1 + ietf-netconf YANG module URI

a

but shouldn't base 1.0 be optional?  i.e. isn't it ok for a new server
to advertise 1.1 only?

> 6)  Should the new capability-changed error be controlled within
>     the initial capability exchange?

Yes.

>    Parameter:  capability-change='true'|'false'
>    default: false
>    If 'true' then the server will return capability-changed errors
>    to this session after a capability change.  The client must request
>    a new <hello> (encoded in an <rpc-reply> of course), to clear this
> condition.
> 
>    Which URI should have this parameter added?
>      a) base 1.1
>      b) ietf-netconf

a

> 7) Splitting with-defaults capability into 2 capabilities
> 
>    It seems to me that the with-default 'basic-mode' and 'also-supported'
>    parameters are related to the protocol, not the YANG module.
>    The 'module' and 'revision' parameters really apply only to
>    the typedef and augment statements (because that is the scope of YANG).

I'm not sure it is useful to make this distinction.  I think one
capability is enough.

>    Should the YANG module capability be kept separate from
>    NETCONF protocol capabilities?
>      a) yes
>      b) no

b

>    If yes, should the with-defaults capability be split into 2 capabilities,
>    one for the protocol behavior and 1 for the YANG module?
>     a) yes
>     b) no
> 
>   If yes, should a server be allowed to advertise the protocol capability
>   but not support the YANG module capability?  This would allow a server
>   to simply announce its basic behavior, and not support the retrieval
>   of 'report-all'.
>     a) yes
>     b) no



/martin

From andyb@iwl.com  Tue Apr  6 02:10:31 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD9E3A694F for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 02:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Oxp12BCKmB for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 02:10:30 -0700 (PDT)
Received: from smtp164.iad.emailsrvr.com (smtp164.iad.emailsrvr.com [207.97.245.164]) by core3.amsl.com (Postfix) with ESMTP id 175B93A683C for <netconf@ietf.org>; Tue,  6 Apr 2010 02:10:30 -0700 (PDT)
Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A55A21B4822; Tue,  6 Apr 2010 05:10:27 -0400 (EDT)
Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4EEA41B47E4;  Tue,  6 Apr 2010 05:10:27 -0400 (EDT)
Message-ID: <4BBAFA9D.7090806@iwl.com>
Date: Tue, 06 Apr 2010 02:10:53 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BB4D45B.8090304@iwl.com> <20100406.103953.119200856.mbj@tail-f.com>
In-Reply-To: <20100406.103953.119200856.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 09:10:31 -0000

Martin Bjorklund wrote:
> Hi
...

> 
>> 7) Splitting with-defaults capability into 2 capabilities
>>
>>    It seems to me that the with-default 'basic-mode' and 'also-supported'
>>    parameters are related to the protocol, not the YANG module.
>>    The 'module' and 'revision' parameters really apply only to
>>    the typedef and augment statements (because that is the scope of YANG).
> 
> I'm not sure it is useful to make this distinction.  I think one
> capability is enough.

The problem is that the YANG capability text does not include
arbitrary parameters stuffed in the URI.  It defines 4 specific
parameters in a specific order.

So IMO the YANG spec needs to be revised to account for
arbitrary parameters, or they must not appear in the YANG
module capability URI.



> 
>>    Should the YANG module capability be kept separate from
>>    NETCONF protocol capabilities?
>>      a) yes
>>      b) no
> 
> b
> 
>>    If yes, should the with-defaults capability be split into 2 capabilities,
>>    one for the protocol behavior and 1 for the YANG module?
>>     a) yes
>>     b) no
>>
>>   If yes, should a server be allowed to advertise the protocol capability
>>   but not support the YANG module capability?  This would allow a server
>>   to simply announce its basic behavior, and not support the retrieval
>>   of 'report-all'.
>>     a) yes
>>     b) no
> 
> 
> 
> /martin
> 

Andy


From j.schoenwaelder@jacobs-university.de  Tue Apr  6 02:58:57 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6173A6AB7 for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 02:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id henABK52m6XY for <netconf@core3.amsl.com>; Tue,  6 Apr 2010 02:58:56 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8AF133A6AB5 for <netconf@ietf.org>; Tue,  6 Apr 2010 02:58:56 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40A12C0002; Tue,  6 Apr 2010 11:58:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4fImyfyoRkLi; Tue,  6 Apr 2010 11:58:52 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 760EDC0007; Tue,  6 Apr 2010 11:58:52 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 33ED61137910; Tue,  6 Apr 2010 11:58:52 +0200 (CEST)
Date: Tue, 6 Apr 2010 11:58:52 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Message-ID: <20100406095852.GA1290@elstar.local>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, "'andyb@iwl.com'" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BB14203.1080309@iwl.com> <84600D05C20FF943918238042D7670FD368B467DCD@EMBX01-HQ.jnpr.net> <20100330151707.GA862@elstar.local> <84600D05C20FF943918238042D7670FD368B467DD4@EMBX01-HQ.jnpr.net> <20100330224012.GB1601@elstar.local> <84600D05C20FF943918238042D7670FD368B467DF0@EMBX01-HQ.jnpr.net> <4BB51192.2010406@iwl.com> <84600D05C20FF943918238042D7670FD368B467DF4@EMBX01-HQ.jnpr.net> <4BB54E06.8070302@iwl.com> <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DFD@EMBX01-HQ.jnpr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 09:58:57 -0000

On Mon, Apr 05, 2010 at 06:51:41PM +0200, Kent Watsen wrote:
>  
> > I am not interested in adding any annotations to NETCONF PDUs.
> 
> That's evident, but it remains to be explained is *why* using
> attributes for metadata is an issue for the WG.  My guess is that
> this sentiment is a holdover from discussions regarding data (not
> metadata).  Anyone?

Since you ask for opinions...

I am not much concerned how metadata is encoded (attributes seem to be
a reasonable choice) as long as metadata does not change any semantics
of standard protocol operations. That said, I do see lots of practical
value in having metadata around. But I of course prefer a discussion
in order to figure out whether it is possible to standardize some of
the metadata instead of having to deal with several vendor extensions
for likely similar things.

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

From j.schoenwaelder@jacobs-university.de  Wed Apr  7 03:32:30 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0443A69C9 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level: 
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikDfE6sZmJtc for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:32:29 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B7903A68C7 for <netconf@ietf.org>; Wed,  7 Apr 2010 03:32:29 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAE23C0007; Wed,  7 Apr 2010 12:32:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i6EeLbH-ZfeP; Wed,  7 Apr 2010 12:32:26 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA308C0004; Wed,  7 Apr 2010 12:32:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9CBA8113A60F; Wed,  7 Apr 2010 12:32:24 +0200 (CEST)
Date: Wed, 7 Apr 2010 12:32:24 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100407103224.GC4401@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BB3A7CD.7030905@iwl.com> <20100331.224559.256498557.mbj@tail-f.com> <20100331205838.GB3420@elstar.local> <20100331.231158.48188998.mbj@tail-f.com> <20100331214017.GC3420@elstar.local> <4BB46F04.4050201@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BB46F04.4050201@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 10:32:30 -0000

On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
 
> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
> capability already covers it.

But isn't this an exception to how you normally advertise YANG
modules? If yes, I do not like it.

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

From mbj@tail-f.com  Wed Apr  7 03:36:08 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110643A6A1C for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=0.556,  BAYES_05=-1.11, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdK4u3T6N76t for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:36:07 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4C3D23A68C7 for <netconf@ietf.org>; Wed,  7 Apr 2010 03:36:07 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A198861600D; Wed,  7 Apr 2010 12:36:03 +0200 (CEST)
Date: Wed, 07 Apr 2010 12:36:03 +0200 (CEST)
Message-Id: <20100407.123603.105839668.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100407103224.GC4401@elstar.local>
References: <20100331214017.GC3420@elstar.local> <4BB46F04.4050201@iwl.com> <20100407103224.GC4401@elstar.local>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 10:36:08 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
>  
> > Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
> > capability already covers it.
> 
> But isn't this an exception to how you normally advertise YANG
> modules?

It is an exception.  A normal YANG module is advertised as a
capability with <namespace>?module=<module>&revision=<revision>...

But in this case, for backwards compatibility reasons, the idea is
that it is advertised as base:1.1 instead.


/martin

From j.schoenwaelder@jacobs-university.de  Wed Apr  7 03:50:33 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6219D3A69C5 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.382
X-Spam-Level: 
X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.867,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USNgIi8X4e43 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:50:31 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 78EA33A694F for <netconf@ietf.org>; Wed,  7 Apr 2010 03:50:31 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5A80C0016; Wed,  7 Apr 2010 12:50:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6eMwpklGJ3Vt; Wed,  7 Apr 2010 12:50:28 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F096CC000F; Wed,  7 Apr 2010 12:50:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E0FB0113A6B3; Wed,  7 Apr 2010 12:50:27 +0200 (CEST)
Date: Wed, 7 Apr 2010 12:50:27 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100407105027.GD4401@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, NETCONF <netconf@ietf.org>
References: <4BB4D45B.8090304@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BB4D45B.8090304@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 10:50:33 -0000

On Thu, Apr 01, 2010 at 07:14:03PM +0200, Andy Bierman wrote:
> Hi,
> 
> Here's a capability issue list roundup.
> Let's try to finish this ASAP.
> Sorry if not all possible solutions are enumerated.
> 
> 
> 1) identifying the I-D or RFC
>    Can we get rid of all version identifiers in capability URIs
>    and use revision=yyyy-mm-dd instead?  That means we should drop
>    all the stuff about :DRAFT-XX and :RFCXXXX from every YANG module
>    draft, and the YANG usage guidelines draft.
> 
>    a) leave version in XML namespace and therefore change the
>       YANG module XML namespace every time a new I-D or RFC
>       is published.  (YANG draft says this field MUST NOT change.)
>    b) remove version from XML namespace and follow
>       the rule already in the YANG spec.  The module XML
>       namespace will not change from release.  The revision date
>       will be updated instead.

b)

> 2) Base part of the URI
> 
>    A standard NETCONF protocol capability has this base part:
> 
>        urn:ietf:params:netconf:capability
> 
>    A version identifier is appropriate because there is revision parameter.
> 
>    Examples:
>        urn:ietf:params:netconf:capability:candidate:1.0
>        urn:ietf:params:netconf:capability:base:1.0
>        urn:ietf:params:netconf:capability:base:1.1
> 
>    A standard YANG module capability has this base part:
> 
>        urn:ietf:params:xml:ns:yang
> 
>    Examples:
>        urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
>        urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
> 
>    Is there any confusion or disagreement about these standard
>    capability URI base parts?
>    a) yes
>    b) no

b)

> 3) capability for ietf-netconf.yang
>    Since this is YANG module, it MUST follow the YANG module
>    formula, which is <namespace>?module=modname&revision=revdate
> 
>   
> urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2019-02-04
> 
>    An alternative is to define a YANG extension statement
>    that allows YANG authors to override the YANG module
>    capability and insert a different string as the base
>    part, instead of the XML namespace.
> 
>    Should the standard YANG module capability URI encoding be
>    used, or should the 'capability' extension be added to
>    replace the base part of the YANG module capability URI?
>    a) use standard encoding
>    b) add new capability extension

a) and c ;-) - I think it makes sense to make a distinction between
the rpc layer of the NETCONF protocol and the set of operations (aka
rpcs) now defined in ietf-netconf-yang.

> 4) advertising features for ietf-netconf.yang
>    This is a special case no matter what, because the
>    protocol capabilities (like candidate:1.0) will still
>    be advertised to support 1.0 clients. The :url and
>    :with-defaults URIs have parameters, and can never be
>    replaced by YANG features in the <hello> encoding.
> 
>    Clients still need to deal with the capability URIs
>    and switching to features is not realistic.  Duplication
>    is not helpful.  What if the feature set does not match
>    the capability set from the same server? (Server bug I guess
>    but it still complicates the client -- all pain and no gain.)
> 
>    Should a 4741bis server advertise the ietf-netconf module?
>    a) yes
>    b) no

a) And I tend to argue that we should either rewrite with-defaults so
that it uses proper features (means we need to define a longer list of
features) or we should consider allowing parameterized features in
YANG. It seems to me a warning sign that we do have concrete
operations in place where the YANG feature mechanism might not be used
or appropriate (depending on how you look at it) and we should IMHO
try to resolve this before we cast things into stone.

> 5) What will 4741bis clients and servers advertise in their <hello>
>    capabilities?
> 
>    a) base 1.0 + base 1.1
>    b) base 1.0 + ietf-netconf YANG module URI
>    c) base 1.0 + base 1.1 + ietf-netconf YANG module URI

c) and d), which is c) without base 1.0.

> 6)  Should the new capability-changed error be controlled within
>     the initial capability exchange?
> 
>    Parameter:  capability-change='true'|'false'
>    default: false
>    If 'true' then the server will return capability-changed errors
>    to this session after a capability change.  The client must request
>    a new <hello> (encoded in an <rpc-reply> of course), to clear this
> condition.
> 
>    Which URI should have this parameter added?
>      a) base 1.1
>      b) ietf-netconf

Please no more special cases with capability formats...

> 7) Splitting with-defaults capability into 2 capabilities
> 
>    It seems to me that the with-default 'basic-mode' and 'also-supported'
>    parameters are related to the protocol, not the YANG module.
>    The 'module' and 'revision' parameters really apply only to
>    the typedef and augment statements (because that is the scope of YANG).
> 
>    Should the YANG module capability be kept separate from
>    NETCONF protocol capabilities?
>      a) yes
>      b) no
> 
>    If yes, should the with-defaults capability be split into 2 capabilities,
>    one for the protocol behavior and 1 for the YANG module?
>     a) yes
>     b) no
> 
>   If yes, should a server be allowed to advertise the protocol capability
>   but not support the YANG module capability?  This would allow a server
>   to simply announce its basic behavior, and not support the retrieval
>   of 'report-all'.
>     a) yes
>     b) no

I am undecided. The with-defaults IMHO really belongs into
ietf-netconf.yang since it is about behaviour of get-config etc., we
do it as an extension in a separate document for process and other
reasons. If we could roll with-defaults into base 1.1, things would
be simpler I guess...

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

From j.schoenwaelder@jacobs-university.de  Wed Apr  7 03:52:22 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761363A6A88 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqqAS64rpIkr for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 03:52:20 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8B2993A694F for <netconf@ietf.org>; Wed,  7 Apr 2010 03:52:18 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B241DC0018; Wed,  7 Apr 2010 12:52:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0xV98Cbzc+ZO; Wed,  7 Apr 2010 12:52:15 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 280F1C000F; Wed,  7 Apr 2010 12:52:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1A400113A762; Wed,  7 Apr 2010 12:52:15 +0200 (CEST)
Date: Wed, 7 Apr 2010 12:52:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20100407105215.GA4687@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, "andyb@iwl.com" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <20100331214017.GC3420@elstar.local> <4BB46F04.4050201@iwl.com> <20100407103224.GC4401@elstar.local> <20100407.123603.105839668.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100407.123603.105839668.mbj@tail-f.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 10:52:22 -0000

On Wed, Apr 07, 2010 at 12:36:03PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
> >  
> > > Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
> > > capability already covers it.
> > 
> > But isn't this an exception to how you normally advertise YANG
> > modules?
> 
> It is an exception.  A normal YANG module is advertised as a
> capability with <namespace>?module=<module>&revision=<revision>...
> 
> But in this case, for backwards compatibility reasons, the idea is
> that it is advertised as base:1.1 instead.

I do not like the 'instead' - I would not mind if it is advertised
differently in addition to the normal YANG advertisement for backwards
compatibility.

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

From andyb@iwl.com  Wed Apr  7 07:53:01 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87143A689F for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 07:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.743
X-Spam-Level: 
X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.522,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVlgxNs2Z3jA for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 07:53:00 -0700 (PDT)
Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id C8D1728B797 for <netconf@ietf.org>; Wed,  7 Apr 2010 07:52:55 -0700 (PDT)
Received: from relay12.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5386B2080694; Wed,  7 Apr 2010 10:52:52 -0400 (EDT)
Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E77BD208060F;  Wed,  7 Apr 2010 10:52:51 -0400 (EDT)
Message-ID: <4BBC9C3E.5030501@iwl.com>
Date: Wed, 07 Apr 2010 07:52:46 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <20100331214017.GC3420@elstar.local> <4BB46F04.4050201@iwl.com> <20100407103224.GC4401@elstar.local> <20100407.123603.105839668.mbj@tail-f.com> <20100407105215.GA4687@elstar.local>
In-Reply-To: <20100407105215.GA4687@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 14:53:01 -0000

Juergen Schoenwaelder wrote:
> On Wed, Apr 07, 2010 at 12:36:03PM +0200, Martin Bjorklund wrote:
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>> On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
>>>  
>>>> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
>>>> capability already covers it.
>>> But isn't this an exception to how you normally advertise YANG
>>> modules?
>> It is an exception.  A normal YANG module is advertised as a
>> capability with <namespace>?module=<module>&revision=<revision>...
>>
>> But in this case, for backwards compatibility reasons, the idea is
>> that it is advertised as base:1.1 instead.
> 
> I do not like the 'instead' - I would not mind if it is advertised
> differently in addition to the normal YANG advertisement for backwards
> compatibility.
> 

I may agree with you.
I implement with-defaults, but do not advertise ietf-netconf.yang (yet).
However, that file must be present in the module path because
with-defaults imports ietf-netconf. If ietf-netconf
is not advertised by the server, then it seems broken to advertise
modules that augment it.

No matter what we do, a 4741bis implementor is going to
have to special-case ietf-netconf.yang because of the capability URIs.

In order to achieve a complete framework in which client applications
can rely on the <hello> meta-data to drive the session, then I think we
have to advertise ietf-netconf.yang.

The YANG features are secondary.  Being able to augment the protocol
operations is the primary reason to include ietf-netconf in the
advertised modules.


> /js
> 

Andy

From andyb@iwl.com  Wed Apr  7 09:27:04 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85853A6B01 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 09:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYaq0C5mESkY for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 09:27:03 -0700 (PDT)
Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 7B5363A6B2A for <netconf@ietf.org>; Wed,  7 Apr 2010 09:25:23 -0700 (PDT)
Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8D60D1B417D for <netconf@ietf.org>; Wed,  7 Apr 2010 12:25:20 -0400 (EDT)
Received: by relay21.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4688D1B40F1 for <netconf@ietf.org>; Wed,  7 Apr 2010 12:25:20 -0400 (EDT)
Message-ID: <4BBCB1EA.20804@iwl.com>
Date: Wed, 07 Apr 2010 09:25:14 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
References: <4BB4D45B.8090304@iwl.com> <20100407105027.GD4401@elstar.local>
In-Reply-To: <20100407105027.GD4401@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 16:27:04 -0000

Juergen Schoenwaelder wrote:
> On Thu, Apr 01, 2010 at 07:14:03PM +0200, Andy Bierman wrote:
>> Hi,
>>
>> Here's a capability issue list roundup.
>> Let's try to finish this ASAP.
>> Sorry if not all possible solutions are enumerated.
>>
>>
>> 1) identifying the I-D or RFC
>>    Can we get rid of all version identifiers in capability URIs
>>    and use revision=yyyy-mm-dd instead?  That means we should drop
>>    all the stuff about :DRAFT-XX and :RFCXXXX from every YANG module
>>    draft, and the YANG usage guidelines draft.
>>
>>    a) leave version in XML namespace and therefore change the
>>       YANG module XML namespace every time a new I-D or RFC
>>       is published.  (YANG draft says this field MUST NOT change.)
>>    b) remove version from XML namespace and follow
>>       the rule already in the YANG spec.  The module XML
>>       namespace will not change from release.  The revision date
>>       will be updated instead.
> 
> b)


agreed  (now 3 to 0)


> 
>> 2) Base part of the URI
>>
>>    A standard NETCONF protocol capability has this base part:
>>
>>        urn:ietf:params:netconf:capability
>>
>>    A version identifier is appropriate because there is revision parameter.
>>
>>    Examples:
>>        urn:ietf:params:netconf:capability:candidate:1.0
>>        urn:ietf:params:netconf:capability:base:1.0
>>        urn:ietf:params:netconf:capability:base:1.1
>>
>>    A standard YANG module capability has this base part:
>>
>>        urn:ietf:params:xml:ns:yang
>>
>>    Examples:
>>        urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
>>        urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
>>
>>    Is there any confusion or disagreement about these standard
>>    capability URI base parts?
>>    a) yes
>>    b) no
> 
> b)
> 
>> 3) capability for ietf-netconf.yang
>>    Since this is YANG module, it MUST follow the YANG module
>>    formula, which is <namespace>?module=modname&revision=revdate
>>
>>   
>> urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2019-02-04
>>
>>    An alternative is to define a YANG extension statement
>>    that allows YANG authors to override the YANG module
>>    capability and insert a different string as the base
>>    part, instead of the XML namespace.
>>
>>    Should the standard YANG module capability URI encoding be
>>    used, or should the 'capability' extension be added to
>>    replace the base part of the YANG module capability URI?
>>    a) use standard encoding
>>    b) add new capability extension
> 
> a) and c ;-) - I think it makes sense to make a distinction between
> the rpc layer of the NETCONF protocol and the set of operations (aka
> rpcs) now defined in ietf-netconf-yang.


not sure what C means.
We do make a distinction.
The <create-subscription> and <partial-lock> operations
are in different namespaces already.



> 
>> 4) advertising features for ietf-netconf.yang
>>    This is a special case no matter what, because the
>>    protocol capabilities (like candidate:1.0) will still
>>    be advertised to support 1.0 clients. The :url and
>>    :with-defaults URIs have parameters, and can never be
>>    replaced by YANG features in the <hello> encoding.
>>
>>    Clients still need to deal with the capability URIs
>>    and switching to features is not realistic.  Duplication
>>    is not helpful.  What if the feature set does not match
>>    the capability set from the same server? (Server bug I guess
>>    but it still complicates the client -- all pain and no gain.)
>>
>>    Should a 4741bis server advertise the ietf-netconf module?
>>    a) yes
>>    b) no
> 
> a) And I tend to argue that we should either rewrite with-defaults so
> that it uses proper features (means we need to define a longer list of
> features) or we should consider allowing parameterized features in
> YANG. It seems to me a warning sign that we do have concrete
> operations in place where the YANG feature mechanism might not be used
> or appropriate (depending on how you look at it) and we should IMHO
> try to resolve this before we cast things into stone.


I disagree that we should use YANG features as if they were identityref leafs.
A YANG feature represents a subset of the module contents.  They are additive,
not a choice between feature A, B, or C.  If we start using features
as parameter values, they will be too confusing.

YANG features should be used like SMIv2 GROUPs, except YANG
tags the group members in-line instead of at the end of the module.


> 
>> 5) What will 4741bis clients and servers advertise in their <hello>
>>    capabilities?
>>
>>    a) base 1.0 + base 1.1
>>    b) base 1.0 + ietf-netconf YANG module URI
>>    c) base 1.0 + base 1.1 + ietf-netconf YANG module URI
> 
> c) and d), which is c) without base 1.0.

agreed.

I like your distinction between the protocol messages <rpc>, etc.
and the operations.

Advertising ietf-netconf.yang says what version of the protocol operations
is supported.  We could decide later there is a bug in ietf-netconf.yang
and update the revision date without changing base:1.1.

The set of operations is going to be changing uncomfortably fast.
The days of peek and poke are over, and that means the operation set
will be constantly growing.  We should establish a framework now
for dealing with that (and option c & d works).


> 
>> 6)  Should the new capability-changed error be controlled within
>>     the initial capability exchange?
>>
>>    Parameter:  capability-change='true'|'false'
>>    default: false
>>    If 'true' then the server will return capability-changed errors
>>    to this session after a capability change.  The client must request
>>    a new <hello> (encoded in an <rpc-reply> of course), to clear this
>> condition.
>>
>>    Which URI should have this parameter added?
>>      a) base 1.1
>>      b) ietf-netconf
> 
> Please no more special cases with capability formats...
> 

right -- but IMO it is clearly 'a' because this is a protocol capability,
since it involves new error-tag values.


>> 7) Splitting with-defaults capability into 2 capabilities
>>
>>    It seems to me that the with-default 'basic-mode' and 'also-supported'
>>    parameters are related to the protocol, not the YANG module.
>>    The 'module' and 'revision' parameters really apply only to
>>    the typedef and augment statements (because that is the scope of YANG).
>>
>>    Should the YANG module capability be kept separate from
>>    NETCONF protocol capabilities?
>>      a) yes
>>      b) no
>>
>>    If yes, should the with-defaults capability be split into 2 capabilities,
>>    one for the protocol behavior and 1 for the YANG module?
>>     a) yes
>>     b) no
>>
>>   If yes, should a server be allowed to advertise the protocol capability
>>   but not support the YANG module capability?  This would allow a server
>>   to simply announce its basic behavior, and not support the retrieval
>>   of 'report-all'.
>>     a) yes
>>     b) no
> 
> I am undecided. The with-defaults IMHO really belongs into
> ietf-netconf.yang since it is about behaviour of get-config etc., we
> do it as an extension in a separate document for process and other
> reasons. If we could roll with-defaults into base 1.1, things would
> be simpler I guess...
> 


The extra capability URI parameters (e.g., basic-mode and also-supported)
need to be dealt with somehow.

The YANG spec (sec. 5.6.4) can be changed to account for extra parameters.
Currently it does not allow for servers to add extra parameters.
It would just be a hack anyway -- it is not standards-worthy without semantics.

IMO, it is better not to mix protocol and module capabilities.
YANG does not support NETCONF protocol capabilities.
I tried to get a capability-stmt added but the WG decided
that the YANG feature-stmt was good enough and nothing else was needed.

Since NETCONF protocol capabilities cannot be documented with YANG at all,
there is no point pretending that they are somehow part of the YANG content.
Adding undocumented parameters to YANG module capabilities is not very robust.
IMO, it is better to keep the whole undocumented mess outside of YANG,
and use 2 capability URIs in this case.



> /js
> 

Andy

From mbj@tail-f.com  Wed Apr  7 23:34:43 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259623A67E3 for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 23:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.187
X-Spam-Level: 
X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBpSZjDxwMol for <netconf@core3.amsl.com>; Wed,  7 Apr 2010 23:34:42 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4D82E3A69B3 for <netconf@ietf.org>; Wed,  7 Apr 2010 23:34:39 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D09CC616002; Thu,  8 Apr 2010 08:34:34 +0200 (CEST)
Date: Thu, 08 Apr 2010 08:34:34 +0200 (CEST)
Message-Id: <20100408.083434.188386942.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BBC9C3E.5030501@iwl.com>
References: <20100407.123603.105839668.mbj@tail-f.com> <20100407105215.GA4687@elstar.local> <4BBC9C3E.5030501@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 06:34:43 -0000

Andy Bierman <andyb@iwl.com> wrote:
> Juergen Schoenwaelder wrote:
> > On Wed, Apr 07, 2010 at 12:36:03PM +0200, Martin Bjorklund wrote:
> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> >>> On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
> >>>  
> >>>> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
> >>>> capability already covers it.
> >>> But isn't this an exception to how you normally advertise YANG
> >>> modules?
> >> It is an exception.  A normal YANG module is advertised as a
> >> capability with <namespace>?module=<module>&revision=<revision>...
> >>
> >> But in this case, for backwards compatibility reasons, the idea is
> >> that it is advertised as base:1.1 instead.
> > 
> > I do not like the 'instead' - I would not mind if it is advertised
> > differently in addition to the normal YANG advertisement for backwards
> > compatibility.
> > 
> 
> I may agree with you.
> I implement with-defaults, but do not advertise ietf-netconf.yang (yet).
> However, that file must be present in the module path because
> with-defaults imports ietf-netconf. If ietf-netconf
> is not advertised by the server, then it seems broken to advertise
> modules that augment it.

So if we advertise both, how do we treat inconsistencies?  Any MUSTs?

> No matter what we do, a 4741bis implementor is going to
> have to special-case ietf-netconf.yang because of the capability URIs.

No, there is an option which does not make any special cases for the
implementor, and that is to not have any special capabilities at all
in 4741bis, just do them as features.  A pure 1.1 server would
advertise the YANG capability including features.  A 1.0 + 1.1 server
would advertise the YANG capability + all the 1.0 capabilities.

So here are the alternatives:

  1.  capability-based
      advertise base:1.1 capability + other capabilities as in 4741
      do not advertise the YANG-defined capability.

      Pro: requires less changes to code and doc
      Con: not yangy

  2.  pure YANG
      just follow YANG rules, and advertise the namespace + features.
      there is no base:1.1 capability to advertise.
  
  3.  mix
      advertise both base:1.1 + other capabilities,
      and advertise the namespace + features

      Con: Confusing that redundant info is advertised, and how do we
           handle mismatches?



/martin

From andyb@iwl.com  Thu Apr  8 00:52:42 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C770C3A6876 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 00:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkluIIr88j67 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 00:52:42 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id ED6353A697B for <netconf@ietf.org>; Thu,  8 Apr 2010 00:52:41 -0700 (PDT)
Received: from relay16.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id F0AE0104BC;  Thu,  8 Apr 2010 03:52:38 -0400 (EDT)
Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id C2F07103AA;  Thu,  8 Apr 2010 03:52:38 -0400 (EDT)
Message-ID: <4BBD8B3B.4000802@iwl.com>
Date: Thu, 08 Apr 2010 00:52:27 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20100407.123603.105839668.mbj@tail-f.com>	<20100407105215.GA4687@elstar.local>	<4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com>
In-Reply-To: <20100408.083434.188386942.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 07:52:42 -0000

Martin Bjorklund wrote:
> Andy Bierman <andyb@iwl.com> wrote:
>> Juergen Schoenwaelder wrote:
>>> On Wed, Apr 07, 2010 at 12:36:03PM +0200, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>>> On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
>>>>>  
>>>>>> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
>>>>>> capability already covers it.
>>>>> But isn't this an exception to how you normally advertise YANG
>>>>> modules?
>>>> It is an exception.  A normal YANG module is advertised as a
>>>> capability with <namespace>?module=<module>&revision=<revision>...
>>>>
>>>> But in this case, for backwards compatibility reasons, the idea is
>>>> that it is advertised as base:1.1 instead.
>>> I do not like the 'instead' - I would not mind if it is advertised
>>> differently in addition to the normal YANG advertisement for backwards
>>> compatibility.
>>>
>> I may agree with you.
>> I implement with-defaults, but do not advertise ietf-netconf.yang (yet).
>> However, that file must be present in the module path because
>> with-defaults imports ietf-netconf. If ietf-netconf
>> is not advertised by the server, then it seems broken to advertise
>> modules that augment it.
> 
> So if we advertise both, how do we treat inconsistencies?  Any MUSTs?
> 
>> No matter what we do, a 4741bis implementor is going to
>> have to special-case ietf-netconf.yang because of the capability URIs.
> 
> No, there is an option which does not make any special cases for the
> implementor, and that is to not have any special capabilities at all
> in 4741bis, just do them as features.  A pure 1.1 server would
> advertise the YANG capability including features.  A 1.0 + 1.1 server
> would advertise the YANG capability + all the 1.0 capabilities.
> 
> So here are the alternatives:
> 
>   1.  capability-based
>       advertise base:1.1 capability + other capabilities as in 4741
>       do not advertise the YANG-defined capability.
> 
>       Pro: requires less changes to code and doc
>       Con: not yangy
> 
>   2.  pure YANG
>       just follow YANG rules, and advertise the namespace + features.
>       there is no base:1.1 capability to advertise.
>   
>   3.  mix
>       advertise both base:1.1 + other capabilities,
>       and advertise the namespace + features
> 
>       Con: Confusing that redundant info is advertised, and how do we
>            handle mismatches?
> 
> 

I see your point on (2).
Before I said ietf-netconf was redundant because we had base:1.1.
In reality, base:1.1 is redundant because we have ietf-netconf.

We need ietf-netconf because other modules (like with-defaults)
will augment it.  We don't really need base:1.1, since a new client
can look for ietf-netconf just as easily as it could look for base:1.1.



> 
> /martin
> 


Andy

From andyb@iwl.com  Thu Apr  8 01:10:42 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7070A3A69BC for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 01:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J5mdACy5o61 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 01:10:41 -0700 (PDT)
Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 60D553A69B3 for <netconf@ietf.org>; Thu,  8 Apr 2010 01:10:21 -0700 (PDT)
Received: from relay18.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 046CA1B4098; Thu,  8 Apr 2010 04:10:18 -0400 (EDT)
Received: by relay18.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7F8BE1B4029;  Thu,  8 Apr 2010 04:10:17 -0400 (EDT)
Message-ID: <4BBD8F5E.5080901@iwl.com>
Date: Thu, 08 Apr 2010 01:10:06 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: andyb@iwl.com
References: <20100407.123603.105839668.mbj@tail-f.com>	<20100407105215.GA4687@elstar.local>	<4BBC9C3E.5030501@iwl.com>	<20100408.083434.188386942.mbj@tail-f.com> <4BBD8B3B.4000802@iwl.com>
In-Reply-To: <4BBD8B3B.4000802@iwl.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 08:10:42 -0000

Andy Bierman wrote:
> Martin Bjorklund wrote:
>> Andy Bierman <andyb@iwl.com> wrote:
>>> Juergen Schoenwaelder wrote:
>>>> On Wed, Apr 07, 2010 at 12:36:03PM +0200, Martin Bjorklund wrote:
>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>>>> On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
>>>>>>  
>>>>>>> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
>>>>>>> capability already covers it.
>>>>>> But isn't this an exception to how you normally advertise YANG
>>>>>> modules?
>>>>> It is an exception.  A normal YANG module is advertised as a
>>>>> capability with <namespace>?module=<module>&revision=<revision>...
>>>>>
>>>>> But in this case, for backwards compatibility reasons, the idea is
>>>>> that it is advertised as base:1.1 instead.
>>>> I do not like the 'instead' - I would not mind if it is advertised
>>>> differently in addition to the normal YANG advertisement for backwards
>>>> compatibility.
>>>>
>>> I may agree with you.
>>> I implement with-defaults, but do not advertise ietf-netconf.yang (yet).
>>> However, that file must be present in the module path because
>>> with-defaults imports ietf-netconf. If ietf-netconf
>>> is not advertised by the server, then it seems broken to advertise
>>> modules that augment it.
>> So if we advertise both, how do we treat inconsistencies?  Any MUSTs?
>>
>>> No matter what we do, a 4741bis implementor is going to
>>> have to special-case ietf-netconf.yang because of the capability URIs.
>> No, there is an option which does not make any special cases for the
>> implementor, and that is to not have any special capabilities at all
>> in 4741bis, just do them as features.  A pure 1.1 server would
>> advertise the YANG capability including features.  A 1.0 + 1.1 server
>> would advertise the YANG capability + all the 1.0 capabilities.
>>
>> So here are the alternatives:
>>
>>   1.  capability-based
>>       advertise base:1.1 capability + other capabilities as in 4741
>>       do not advertise the YANG-defined capability.
>>
>>       Pro: requires less changes to code and doc
>>       Con: not yangy
>>
>>   2.  pure YANG
>>       just follow YANG rules, and advertise the namespace + features.
>>       there is no base:1.1 capability to advertise.
>>   
>>   3.  mix
>>       advertise both base:1.1 + other capabilities,
>>       and advertise the namespace + features
>>
>>       Con: Confusing that redundant info is advertised, and how do we
>>            handle mismatches?
>>
>>
> 
> I see your point on (2).
> Before I said ietf-netconf was redundant because we had base:1.1.
> In reality, base:1.1 is redundant because we have ietf-netconf.
> 
> We need ietf-netconf because other modules (like with-defaults)
> will augment it.  We don't really need base:1.1, since a new client
> can look for ietf-netconf just as easily as it could look for base:1.1.
> 
> 

oops -- this is not entirely correct.
We need a new client to somehow advertise in its <hello>
that it is a new client, and wants a 4741bis session,
not a 4741 session.  The base:1.1 capability serves that
purpose.  The alternative is to have the client advertise
ietf-netconf but that seems more broken than the rest of the options.

The easiest solution for this aspect of the problem is
to extend the exact-match for a base capability
instead of creating a partial-match for namespace-part. (option c.)

Client sends     Server sends       Protocol version in use:
 1.0, 1.1          1.0, 1.1         1.1
 1.0, 1.1          1.0              1.0
 1.0, 1.1          1.1              1.1
 1.0               1.0, 1.1         1.0
 1.0               1.0              1.0
 1.0               1.1              none -- drop session
 1.1               1.0, 1.1         1.1
 1.1               1.1              1.1
 1.1               1.0              none -- drop session


ietf-netconf SHOULD be advertised because it can be augmented.
A server MUST make its protocol capabilities and ietf-netconf features match.


> 
>> /martin
>>
> 
> 
> Andy

Andy


From lhotka@cesnet.cz  Thu Apr  8 02:07:35 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FF13A69EA for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 02:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBQzKYxgQTcc for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 02:07:35 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 194F53A6901 for <netconf@ietf.org>; Thu,  8 Apr 2010 02:07:29 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9177E2CDE058; Thu,  8 Apr 2010 11:07:25 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100408.083434.188386942.mbj@tail-f.com>
References: <20100407.123603.105839668.mbj@tail-f.com> <20100407105215.GA4687@elstar.local> <4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Thu, 08 Apr 2010 11:07:24 +0200
Message-ID: <1270717644.2788.25.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 09:07:35 -0000

Martin Bjorklund píše v Čt 08. 04. 2010 v 08:34 +0200:

> So here are the alternatives:
> 
>   1.  capability-based
>       advertise base:1.1 capability + other capabilities as in 4741
>       do not advertise the YANG-defined capability.
> 
>       Pro: requires less changes to code and doc
>       Con: not yangy
> 
>   2.  pure YANG
>       just follow YANG rules, and advertise the namespace + features.
>       there is no base:1.1 capability to advertise.

Strictly speaking, this option is not "pure YANG" but rather "misused
YANG". The spec positions YANG quite clearly as "a language used to
model data for the NETCONF protocol". In this case, YANG is used for
(re)defining the NETCONF protocol itself, which is IMO clearly outside
the scope of YANG and therefore incorrect. In fact, by doing so, YANG is
made into yet another XML schema language.

Lada

>   
>   3.  mix
>       advertise both base:1.1 + other capabilities,
>       and advertise the namespace + features
> 
>       Con: Confusing that redundant info is advertised, and how do we
>            handle mismatches?
> 
> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From mbj@tail-f.com  Thu Apr  8 02:13:03 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF0A3A69EA for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 02:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.091
X-Spam-Level: 
X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.277,  BAYES_40=-0.185, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vDDT-8n6eDF for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 02:13:01 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EEF4B3A6901 for <netconf@ietf.org>; Thu,  8 Apr 2010 02:13:00 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D1015616002; Thu,  8 Apr 2010 11:12:56 +0200 (CEST)
Date: Thu, 08 Apr 2010 11:12:56 +0200 (CEST)
Message-Id: <20100408.111256.234694443.mbj@tail-f.com>
To: lhotka@cesnet.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1270717644.2788.25.camel@missotis>
References: <4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com> <1270717644.2788.25.camel@missotis>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 09:13:03 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr
bHVuZCBww63FoWUgdiDEjHQgMDguIDA0LiAyMDEwIHYgMDg6MzQgKzAyMDA6DQo+IA0KPiA+IFNv
IGhlcmUgYXJlIHRoZSBhbHRlcm5hdGl2ZXM6DQo+ID4gDQo+ID4gICAxLiAgY2FwYWJpbGl0eS1i
YXNlZA0KPiA+ICAgICAgIGFkdmVydGlzZSBiYXNlOjEuMSBjYXBhYmlsaXR5ICsgb3RoZXIgY2Fw
YWJpbGl0aWVzIGFzIGluIDQ3NDENCj4gPiAgICAgICBkbyBub3QgYWR2ZXJ0aXNlIHRoZSBZQU5H
LWRlZmluZWQgY2FwYWJpbGl0eS4NCj4gPiANCj4gPiAgICAgICBQcm86IHJlcXVpcmVzIGxlc3Mg
Y2hhbmdlcyB0byBjb2RlIGFuZCBkb2MNCj4gPiAgICAgICBDb246IG5vdCB5YW5neQ0KPiA+IA0K
PiA+ICAgMi4gIHB1cmUgWUFORw0KPiA+ICAgICAgIGp1c3QgZm9sbG93IFlBTkcgcnVsZXMsIGFu
ZCBhZHZlcnRpc2UgdGhlIG5hbWVzcGFjZSArIGZlYXR1cmVzLg0KPiA+ICAgICAgIHRoZXJlIGlz
IG5vIGJhc2U6MS4xIGNhcGFiaWxpdHkgdG8gYWR2ZXJ0aXNlLg0KPiANCj4gU3RyaWN0bHkgc3Bl
YWtpbmcsIHRoaXMgb3B0aW9uIGlzIG5vdCAicHVyZSBZQU5HIiBidXQgcmF0aGVyICJtaXN1c2Vk
DQo+IFlBTkciLiBUaGUgc3BlYyBwb3NpdGlvbnMgWUFORyBxdWl0ZSBjbGVhcmx5IGFzICJhIGxh
bmd1YWdlIHVzZWQgdG8NCj4gbW9kZWwgZGF0YSBmb3IgdGhlIE5FVENPTkYgcHJvdG9jb2wiLiBJ
biB0aGlzIGNhc2UsIFlBTkcgaXMgdXNlZCBmb3INCj4gKHJlKWRlZmluaW5nIHRoZSBORVRDT05G
IHByb3RvY29sIGl0c2VsZiwgd2hpY2ggaXMgSU1PIGNsZWFybHkgb3V0c2lkZQ0KPiB0aGUgc2Nv
cGUgb2YgWUFORyBhbmQgdGhlcmVmb3JlIGluY29ycmVjdC4gSW4gZmFjdCwgYnkgZG9pbmcgc28s
IFlBTkcgaXMNCj4gbWFkZSBpbnRvIHlldCBhbm90aGVyIFhNTCBzY2hlbWEgbGFuZ3VhZ2UuDQoN
CkkgZGlzYWdyZWUuICBUaGUgWUFORyBzcGVjIHNheXM6DQoNCiAgWUFORyBpcyB1c2VkIHRvIG1v
ZGVsIHRoZSBvcGVyYXRpb25zIGFuZCBjb250ZW50IGxheWVycyBvZiBORVRDT05GDQoNCldoYXQg
d2UncmUgZG9pbmcgaW4gaWV0Zi1uZXRjb25mLnlhbmcgaXMgbW9kZWxsaW5nIHRoZSBjb3JlIE5F
VENPTkYNCm9wZXJhdGlvbnMuDQoNCldlJ3JlIG5vdCBkb2luZyBhbnl0aGluZyB3aXRoIHRoZSBN
ZXNzYWdlcyBsYXllciAoKnRoYXQqIHdvdWxkIGJlDQptaXN1c2luZyBZQU5HKS4NCg0KDQovbWFy
dGluDQo=

From lhotka@cesnet.cz  Thu Apr  8 04:01:46 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025DD3A69A3 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRHDcPrLNVbI for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:01:45 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 733683A688B for <netconf@ietf.org>; Thu,  8 Apr 2010 04:01:44 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2DCCE2CDE058 for <netconf@ietf.org>; Thu,  8 Apr 2010 13:01:38 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: NETCONF WG <netconf@ietf.org>
In-Reply-To: <20100408.111256.234694443.mbj@tail-f.com>
References: <4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com> <1270717644.2788.25.camel@missotis> <20100408.111256.234694443.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Thu, 08 Apr 2010 13:01:37 +0200
Message-ID: <1270724497.2788.41.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 11:01:46 -0000

Martin Bjorklund píše v Čt 08. 04. 2010 v 11:12 +0200:
> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
> > Martin Bjorklund píše v Čt 08. 04. 2010 v 08:34 +0200:
> > 
> > > So here are the alternatives:
> > > 
> > >   1.  capability-based
> > >       advertise base:1.1 capability + other capabilities as in 4741
> > >       do not advertise the YANG-defined capability.
> > > 
> > >       Pro: requires less changes to code and doc
> > >       Con: not yangy
> > > 
> > >   2.  pure YANG
> > >       just follow YANG rules, and advertise the namespace + features.
> > >       there is no base:1.1 capability to advertise.
> > 
> > Strictly speaking, this option is not "pure YANG" but rather "misused
> > YANG". The spec positions YANG quite clearly as "a language used to
> > model data for the NETCONF protocol". In this case, YANG is used for
> > (re)defining the NETCONF protocol itself, which is IMO clearly outside
> > the scope of YANG and therefore incorrect. In fact, by doing so, YANG is
> > made into yet another XML schema language.
> 
> I disagree.  The YANG spec says:
> 
>   YANG is used to model the operations and content layers of NETCONF
> 
> What we're doing in ietf-netconf.yang is modelling the core NETCONF
> operations.

Beside the technical issue of XML attributes in core NETCONF operations
that cannot be represented in YANG (by design), YANG spec also defines
XML mapping rules in terms of the core NETCONF operations. So I'd assume
these core operations are given to YANG from outside.

IMO the core NETCONF operations as defined in RFC 4741 or 4741bis should
be fully determined by the base capability URI, independently of any
YANG idiosyncrasies.

Lada

> 
> We're not doing anything with the Messages layer (*that* would be
> misusing YANG).
> 
> 
> /martin


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C



From j.schoenwaelder@jacobs-university.de  Thu Apr  8 04:17:16 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CA23A6A2D for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Level: 
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1laFdZgvqvG for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:17:11 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 58A143A68B9 for <netconf@ietf.org>; Thu,  8 Apr 2010 04:17:06 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0286FC0006; Thu,  8 Apr 2010 13:17:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AMggos2EpNGs; Thu,  8 Apr 2010 13:17:01 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E900C0004; Thu,  8 Apr 2010 13:17:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 117AB11771C0; Thu,  8 Apr 2010 13:17:01 +0200 (CEST)
Date: Thu, 8 Apr 2010 13:17:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20100408111700.GA2780@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, "lhotka@cesnet.cz" <lhotka@cesnet.cz>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com> <1270717644.2788.25.camel@missotis> <20100408.111256.234694443.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100408.111256.234694443.mbj@tail-f.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 11:17:16 -0000

On Thu, Apr 08, 2010 at 11:12:56AM +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
> > Martin Bjorklund p????e v ??t 08. 04. 2010 v 08:34 +0200:
> > 
> > > So here are the alternatives:
> > > 
> > >   1.  capability-based
> > >       advertise base:1.1 capability + other capabilities as in 4741
> > >       do not advertise the YANG-defined capability.
> > > 
> > >       Pro: requires less changes to code and doc
> > >       Con: not yangy
> > > 
> > >   2.  pure YANG
> > >       just follow YANG rules, and advertise the namespace + features.
> > >       there is no base:1.1 capability to advertise.
> > 
> > Strictly speaking, this option is not "pure YANG" but rather "misused
> > YANG". The spec positions YANG quite clearly as "a language used to
> > model data for the NETCONF protocol". In this case, YANG is used for
> > (re)defining the NETCONF protocol itself, which is IMO clearly outside
> > the scope of YANG and therefore incorrect. In fact, by doing so, YANG is
> > made into yet another XML schema language.
> 
> I disagree.  The YANG spec says:
> 
>   YANG is used to model the operations and content layers of NETCONF
> 
> What we're doing in ietf-netconf.yang is modelling the core NETCONF
> operations.
> 
> We're not doing anything with the Messages layer (*that* would be
> misusing YANG).

+1

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

From j.schoenwaelder@jacobs-university.de  Thu Apr  8 04:20:53 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43803A6A2F for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level: 
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.244,  BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1Z7MQ7UVmVF for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:20:49 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6B2B23A6A47 for <netconf@ietf.org>; Thu,  8 Apr 2010 04:20:38 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 210EFC0006; Thu,  8 Apr 2010 13:20:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ytskJO57+9CQ; Thu,  8 Apr 2010 13:20:33 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A068DC0004; Thu,  8 Apr 2010 13:20:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 626301177207; Thu,  8 Apr 2010 13:20:32 +0200 (CEST)
Date: Thu, 8 Apr 2010 13:20:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100408112032.GB2780@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <20100407.123603.105839668.mbj@tail-f.com> <20100407105215.GA4687@elstar.local> <4BBC9C3E.5030501@iwl.com> <20100408.083434.188386942.mbj@tail-f.com> <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BBD8F5E.5080901@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 11:20:53 -0000

On Thu, Apr 08, 2010 at 10:10:06AM +0200, Andy Bierman wrote:
 
> > I see your point on (2).
> > Before I said ietf-netconf was redundant because we had base:1.1.
> > In reality, base:1.1 is redundant because we have ietf-netconf.
> > 
> > We need ietf-netconf because other modules (like with-defaults)
> > will augment it.  We don't really need base:1.1, since a new client
> > can look for ietf-netconf just as easily as it could look for base:1.1.
> 
> oops -- this is not entirely correct.
> We need a new client to somehow advertise in its <hello>
> that it is a new client, and wants a 4741bis session,
> not a 4741 session.  The base:1.1 capability serves that
> purpose.  The alternative is to have the client advertise
> ietf-netconf but that seems more broken than the rest of the options.
> 
> The easiest solution for this aspect of the problem is
> to extend the exact-match for a base capability
> instead of creating a partial-match for namespace-part. (option c.)
> 
> Client sends     Server sends       Protocol version in use:
>  1.0, 1.1          1.0, 1.1         1.1
>  1.0, 1.1          1.0              1.0
>  1.0, 1.1          1.1              1.1
>  1.0               1.0, 1.1         1.0
>  1.0               1.0              1.0
>  1.0               1.1              none -- drop session
>  1.1               1.0, 1.1         1.1
>  1.1               1.1              1.1
>  1.1               1.0              none -- drop session
> 
> 
> ietf-netconf SHOULD be advertised because it can be augmented.
> A server MUST make its protocol capabilities and ietf-netconf features match.

If this is a problem, we need to solve if for _all_ YANG modules and
not just for this one. If I have two versions of foo.yang defining
bar(), how is the server going to know whether the client likes to
invoke bar() of the first or second version?

Things really should fall out naturally if we got YANG right and if
things don't fall out naturally, I am concerned we did not do our
homework well enough.

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

From j.schoenwaelder@jacobs-university.de  Thu Apr  8 04:21:12 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570EF3A6882 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Level: 
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.513,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXwcdVKg-7uN for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 04:21:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 973803A6863 for <netconf@ietf.org>; Thu,  8 Apr 2010 04:20:49 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D969C0004; Thu,  8 Apr 2010 13:20:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9aIJ3EfmtHSf; Thu,  8 Apr 2010 13:20:45 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1C69C0007; Thu,  8 Apr 2010 13:20:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B892B1177236; Thu,  8 Apr 2010 13:20:44 +0200 (CEST)
Date: Thu, 8 Apr 2010 13:20:44 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100408112044.GC2780@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, NETCONF <netconf@ietf.org>
References: <4BB4D45B.8090304@iwl.com> <20100407105027.GD4401@elstar.local> <4BBCB1EA.20804@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BBCB1EA.20804@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] capability URI issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 11:21:12 -0000

On Wed, Apr 07, 2010 at 06:25:14PM +0200, Andy Bierman wrote:

> >> 4) advertising features for ietf-netconf.yang
> >>    This is a special case no matter what, because the
> >>    protocol capabilities (like candidate:1.0) will still
> >>    be advertised to support 1.0 clients. The :url and
> >>    :with-defaults URIs have parameters, and can never be
> >>    replaced by YANG features in the <hello> encoding.
> >>
> >>    Clients still need to deal with the capability URIs
> >>    and switching to features is not realistic.  Duplication
> >>    is not helpful.  What if the feature set does not match
> >>    the capability set from the same server? (Server bug I guess
> >>    but it still complicates the client -- all pain and no gain.)
> >>
> >>    Should a 4741bis server advertise the ietf-netconf module?
> >>    a) yes
> >>    b) no
> > 
> > a) And I tend to argue that we should either rewrite with-defaults so
> > that it uses proper features (means we need to define a longer list of
> > features) or we should consider allowing parameterized features in
> > YANG. It seems to me a warning sign that we do have concrete
> > operations in place where the YANG feature mechanism might not be used
> > or appropriate (depending on how you look at it) and we should IMHO
> > try to resolve this before we cast things into stone.
> 
> 
> I disagree that we should use YANG features as if they were identityref leafs.
> A YANG feature represents a subset of the module contents.  They are additive,
> not a choice between feature A, B, or C.  If we start using features
> as parameter values, they will be too confusing.

It was not my intention to suggest any of this...
 
> YANG features should be used like SMIv2 GROUPs, except YANG
> tags the group members in-line instead of at the end of the module.

I was thinking that instead of announcing basic-mode=report-all (which
can't be done with the current version of YANG and thus requires a
hand-crafted capability), we could try to find alternatives:

a) Add multiple feature definitions that can be announced as
   'basic-mode-report-all' and 'also-supported-trim' etc. and thus
   would work with the current version of YANG. 

b) Or we change YANG such that features can have a parameter, e.g.

   feature basic-mode {
     type with-defaults-mode;
   }

   so that we get the "basic-mode=report-all" encoding in the URI.

I believe it is a feature if we manage to describe all NETCONF
operations completely in YANG and make YANG versioning mechanisms to
work from 1.1 onwards for all operations. Being able to describe the
NETCONF operations in YANG is kind of a proof that we got things right
and I am concerned if there are things we can't express or where we
need to introduce special cases.

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

From mbj@tail-f.com  Thu Apr  8 05:33:16 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE5828C11A for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 05:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=0.768,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upgPusn+RSXa for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 05:33:15 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 20B8B3A6A63 for <netconf@ietf.org>; Thu,  8 Apr 2010 05:33:15 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 13F81616002; Thu,  8 Apr 2010 14:33:11 +0200 (CEST)
Date: Thu, 08 Apr 2010 14:33:10 +0200 (CEST)
Message-Id: <20100408.143310.00211428.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100408112032.GB2780@elstar.local>
References: <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com> <20100408112032.GB2780@elstar.local>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 12:33:16 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, Apr 08, 2010 at 10:10:06AM +0200, Andy Bierman wrote:
>  
> > > I see your point on (2).
> > > Before I said ietf-netconf was redundant because we had base:1.1.
> > > In reality, base:1.1 is redundant because we have ietf-netconf.
> > > 
> > > We need ietf-netconf because other modules (like with-defaults)
> > > will augment it.  We don't really need base:1.1, since a new client
> > > can look for ietf-netconf just as easily as it could look for base:1.1.
> > 
> > oops -- this is not entirely correct.
> > We need a new client to somehow advertise in its <hello>
> > that it is a new client, and wants a 4741bis session,
> > not a 4741 session.  The base:1.1 capability serves that
> > purpose.  The alternative is to have the client advertise
> > ietf-netconf but that seems more broken than the rest of the options.
> > 
> > The easiest solution for this aspect of the problem is
> > to extend the exact-match for a base capability
> > instead of creating a partial-match for namespace-part. (option c.)
> > 
> > Client sends     Server sends       Protocol version in use:
> >  1.0, 1.1          1.0, 1.1         1.1
> >  1.0, 1.1          1.0              1.0
> >  1.0, 1.1          1.1              1.1
> >  1.0               1.0, 1.1         1.0
> >  1.0               1.0              1.0
> >  1.0               1.1              none -- drop session
> >  1.1               1.0, 1.1         1.1
> >  1.1               1.1              1.1
> >  1.1               1.0              none -- drop session
> > 
> > 
> > ietf-netconf SHOULD be advertised because it can be augmented.
> > A server MUST make its protocol capabilities and ietf-netconf features match.
> 
> If this is a problem, we need to solve if for _all_ YANG modules and
> not just for this one. If I have two versions of foo.yang defining
> bar(), how is the server going to know whether the client likes to
> invoke bar() of the first or second version?

The problem is not which version of the operation to invoke - the
problem is which version of the protocol (on the message layer) the
client wants.

> Things really should fall out naturally if we got YANG right and if
> things don't fall out naturally, I am concerned we did not do our
> homework well enough.

As we agreed, YANG does not try to do anything with the message layer,
so in order to do any negotiation for the message layer, it needs to
be done outside YANG.

Hmm.  So maybe this is the solution.  The base:1.1 capability is used
by the server and client to indicate support for 4741bis message
layer.  Then the normal YANG capability is used by a 4741bis server to
indicate support for 4741bis operations, and the old capabilities are
used to indicate support for the 4741 operations to old clients.

4741bis-only server advertises:
   base:1.1
   YANG capability (namespace + features)

4741bis + 4741 server advertises:
   base:1.1
   YANG capability (namespace + features)
   base:1.0
   4741-capabilites (:startup etc)

4741bis-only client advertises:
   base:1.1

4741bis + 4741 client advertises:
   base:1.0
   base:1.1


If the effective protocol is base:1.1, then the client checks the
features to see what the server can do.

If the effective protocol is base:1.0, then the client checks the
capabilities to see what the server can do.



/martin

From j.schoenwaelder@jacobs-university.de  Thu Apr  8 05:41:06 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664823A6A55 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 05:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level: 
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.456,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKfKX34hGWOq for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 05:41:05 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5F12A3A63C9 for <netconf@ietf.org>; Thu,  8 Apr 2010 05:41:04 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35920C0007; Thu,  8 Apr 2010 14:41:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 66DGoxk8ueor; Thu,  8 Apr 2010 14:41:00 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC629C0004; Thu,  8 Apr 2010 14:40:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5529811776C8; Thu,  8 Apr 2010 14:40:59 +0200 (CEST)
Date: Thu, 8 Apr 2010 14:40:58 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20100408124057.GA3117@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, "andyb@iwl.com" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com> <20100408112032.GB2780@elstar.local> <20100408.143310.00211428.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100408.143310.00211428.mbj@tail-f.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 12:41:06 -0000

On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:

[...]

> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
> by the server and client to indicate support for 4741bis message
> layer.  Then the normal YANG capability is used by a 4741bis server to
> indicate support for 4741bis operations, and the old capabilities are
> used to indicate support for the 4741 operations to old clients.
> 
> 4741bis-only server advertises:
>    base:1.1
>    YANG capability (namespace + features)
> 
> 4741bis + 4741 server advertises:
>    base:1.1
>    YANG capability (namespace + features)
>    base:1.0
>    4741-capabilites (:startup etc)
> 
> 4741bis-only client advertises:
>    base:1.1
> 
> 4741bis + 4741 client advertises:
>    base:1.0
>    base:1.1
> 
> If the effective protocol is base:1.1, then the client checks the
> features to see what the server can do.
> 
> If the effective protocol is base:1.0, then the client checks the
> capabilities to see what the server can do.

This looks reasonable to me.

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

From andyb@iwl.com  Thu Apr  8 06:01:11 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BC93A6A6B for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 06:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level: 
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrjeIruC-1+a for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 06:01:07 -0700 (PDT)
Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id DD5633A6A69 for <netconf@ietf.org>; Thu,  8 Apr 2010 06:01:07 -0700 (PDT)
Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B244A30B0E9C; Thu,  8 Apr 2010 09:01:04 -0400 (EDT)
Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7D9CF30B07EF;  Thu,  8 Apr 2010 09:01:04 -0400 (EDT)
Message-ID: <4BBDD383.1060900@iwl.com>
Date: Thu, 08 Apr 2010 06:00:51 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com> <20100408112032.GB2780@elstar.local> <20100408.143310.00211428.mbj@tail-f.com> <20100408124057.GA3117@elstar.local>
In-Reply-To: <20100408124057.GA3117@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 13:01:11 -0000

Juergen Schoenwaelder wrote:
> On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
> 
> [...]
> 
>> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
>> by the server and client to indicate support for 4741bis message
>> layer.  Then the normal YANG capability is used by a 4741bis server to
>> indicate support for 4741bis operations, and the old capabilities are
>> used to indicate support for the 4741 operations to old clients.
>>
>> 4741bis-only server advertises:
>>    base:1.1
>>    YANG capability (namespace + features)
>>
>> 4741bis + 4741 server advertises:
>>    base:1.1
>>    YANG capability (namespace + features)
>>    base:1.0
>>    4741-capabilites (:startup etc)
>>
>> 4741bis-only client advertises:
>>    base:1.1
>>
>> 4741bis + 4741 client advertises:
>>    base:1.0
>>    base:1.1
>>
>> If the effective protocol is base:1.1, then the client checks the
>> features to see what the server can do.
>>
>> If the effective protocol is base:1.0, then the client checks the
>> capabilities to see what the server can do.
> 
> This looks reasonable to me.

Except YANG features have no way of passing parameters, so
they will never work for :url or :with-defaults.

A solution which does not even work for our 1.0 legacy
stuff is not very good.


> 
> /js
> 

Andy

From j.schoenwaelder@jacobs-university.de  Thu Apr  8 06:05:41 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDC328C103 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 06:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level: 
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.411,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+YKAuicWXgB for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 06:05:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D6B9B3A6922 for <netconf@ietf.org>; Thu,  8 Apr 2010 06:05:40 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82C05C0006; Thu,  8 Apr 2010 15:05:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5dN1q1FvGILT; Thu,  8 Apr 2010 15:05:35 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94633C0004; Thu,  8 Apr 2010 15:05:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8358411779E5; Thu,  8 Apr 2010 15:05:35 +0200 (CEST)
Date: Thu, 8 Apr 2010 15:05:35 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100408130535.GA3377@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com> <20100408112032.GB2780@elstar.local> <20100408.143310.00211428.mbj@tail-f.com> <20100408124057.GA3117@elstar.local> <4BBDD383.1060900@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BBDD383.1060900@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 13:05:42 -0000

On Thu, Apr 08, 2010 at 03:00:51PM +0200, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
> > 
> > [...]
> > 
> >> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
> >> by the server and client to indicate support for 4741bis message
> >> layer.  Then the normal YANG capability is used by a 4741bis server to
> >> indicate support for 4741bis operations, and the old capabilities are
> >> used to indicate support for the 4741 operations to old clients.
> >>
> >> 4741bis-only server advertises:
> >>    base:1.1
> >>    YANG capability (namespace + features)
> >>
> >> 4741bis + 4741 server advertises:
> >>    base:1.1
> >>    YANG capability (namespace + features)
> >>    base:1.0
> >>    4741-capabilites (:startup etc)
> >>
> >> 4741bis-only client advertises:
> >>    base:1.1
> >>
> >> 4741bis + 4741 client advertises:
> >>    base:1.0
> >>    base:1.1
> >>
> >> If the effective protocol is base:1.1, then the client checks the
> >> features to see what the server can do.
> >>
> >> If the effective protocol is base:1.0, then the client checks the
> >> capabilities to see what the server can do.
> > 
> > This looks reasonable to me.
> 
> Except YANG features have no way of passing parameters, so
> they will never work for :url or :with-defaults.

See my other message - :with-defaults is not cast into stone yet.
 
> A solution which does not even work for our 1.0 legacy
> stuff is not very good.

Or perhaps shows that there is a real-world demand for parameterized
features?

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

From andyb@iwl.com  Thu Apr  8 08:22:54 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3863A67E9 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 08:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.056
X-Spam-Level: 
X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR26C25IsJTv for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 08:22:53 -0700 (PDT)
Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 206963A6A13 for <netconf@ietf.org>; Thu,  8 Apr 2010 08:22:40 -0700 (PDT)
Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D1B6430B0400; Thu,  8 Apr 2010 11:22:36 -0400 (EDT)
Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5481930B0446;  Thu,  8 Apr 2010 11:22:36 -0400 (EDT)
Message-ID: <4BBDF4AE.3050908@iwl.com>
Date: Thu, 08 Apr 2010 08:22:22 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBD8B3B.4000802@iwl.com> <4BBD8F5E.5080901@iwl.com> <20100408112032.GB2780@elstar.local> <20100408.143310.00211428.mbj@tail-f.com> <20100408124057.GA3117@elstar.local> <4BBDD383.1060900@iwl.com> <20100408130535.GA3377@elstar.local>
In-Reply-To: <20100408130535.GA3377@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 15:22:54 -0000

Juergen Schoenwaelder wrote:
> On Thu, Apr 08, 2010 at 03:00:51PM +0200, Andy Bierman wrote:
>> Juergen Schoenwaelder wrote:
>>> On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
>>>
>>> [...]
>>>
>>>> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
>>>> by the server and client to indicate support for 4741bis message
>>>> layer.  Then the normal YANG capability is used by a 4741bis server to
>>>> indicate support for 4741bis operations, and the old capabilities are
>>>> used to indicate support for the 4741 operations to old clients.
>>>>
>>>> 4741bis-only server advertises:
>>>>    base:1.1
>>>>    YANG capability (namespace + features)
>>>>
>>>> 4741bis + 4741 server advertises:
>>>>    base:1.1
>>>>    YANG capability (namespace + features)
>>>>    base:1.0
>>>>    4741-capabilites (:startup etc)
>>>>
>>>> 4741bis-only client advertises:
>>>>    base:1.1
>>>>
>>>> 4741bis + 4741 client advertises:
>>>>    base:1.0
>>>>    base:1.1
>>>>
>>>> If the effective protocol is base:1.1, then the client checks the
>>>> features to see what the server can do.
>>>>
>>>> If the effective protocol is base:1.0, then the client checks the
>>>> capabilities to see what the server can do.
>>> This looks reasonable to me.
>> Except YANG features have no way of passing parameters, so
>> they will never work for :url or :with-defaults.
> 
> See my other message - :with-defaults is not cast into stone yet.
>  

We went through your proposal months ago and the WG
decided to keep using parameter=value instead
of feature=permutation-name.

This conversion plan does not work at all for
the :url 'scheme' parameter (scheme=file,sftp')
because the parameter values are not fixed enums like for :with-defaults.

>> A solution which does not even work for our 1.0 legacy
>> stuff is not very good.
> 
> Or perhaps shows that there is a real-world demand for parameterized
> features?

The :url and :with-defaults capabilities work fine the way
they are now.  They need to remain in place, even if a YANG
feature (a boolean) is also used.

I do not think we need CLRs about what parts of the <hello> a client
is allowed to use.  The whole message MUST be correct, even if it
may have redundant information.  The client can ignore :url and :with-defaults
if it does not care about those capabilities.  The client can ignore
YANG features for ietf-netconf if it implements the protocol based
on the capabilities instead.



> 
> /js
> 


Andy


From mbj@tail-f.com  Thu Apr  8 09:24:11 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC043A695F for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 09:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=0.812,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4uq5vOMrSB5 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 09:24:11 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 918213A69F7 for <netconf@ietf.org>; Thu,  8 Apr 2010 09:23:56 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CAF9E616002; Thu,  8 Apr 2010 18:23:51 +0200 (CEST)
Date: Thu, 08 Apr 2010 18:23:51 +0200 (CEST)
Message-Id: <20100408.182351.75186165.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BBDF4AE.3050908@iwl.com>
References: <4BBDD383.1060900@iwl.com> <20100408130535.GA3377@elstar.local> <4BBDF4AE.3050908@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 16:24:11 -0000

Andy Bierman <andyb@iwl.com> wrote:
> Juergen Schoenwaelder wrote:
> > On Thu, Apr 08, 2010 at 03:00:51PM +0200, Andy Bierman wrote:
> >> Juergen Schoenwaelder wrote:
> >>> On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
> >>>
> >>> [...]
> >>>
> >>>> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
> >>>> by the server and client to indicate support for 4741bis message
> >>>> layer.  Then the normal YANG capability is used by a 4741bis server to
> >>>> indicate support for 4741bis operations, and the old capabilities are
> >>>> used to indicate support for the 4741 operations to old clients.
> >>>>
> >>>> 4741bis-only server advertises:
> >>>>    base:1.1
> >>>>    YANG capability (namespace + features)
> >>>>
> >>>> 4741bis + 4741 server advertises:
> >>>>    base:1.1
> >>>>    YANG capability (namespace + features)
> >>>>    base:1.0
> >>>>    4741-capabilites (:startup etc)
> >>>>
> >>>> 4741bis-only client advertises:
> >>>>    base:1.1
> >>>>
> >>>> 4741bis + 4741 client advertises:
> >>>>    base:1.0
> >>>>    base:1.1
> >>>>
> >>>> If the effective protocol is base:1.1, then the client checks the
> >>>> features to see what the server can do.
> >>>>
> >>>> If the effective protocol is base:1.0, then the client checks the
> >>>> capabilities to see what the server can do.
> >>> This looks reasonable to me.
> >> Except YANG features have no way of passing parameters, so
> >> they will never work for :url or :with-defaults.

I agree that features should not be (mis)used to carry information
about e.g. url schemes.  The YANG spec says about feature:

  feature: A mechanism for marking a portion of the model as optional

Two alternatives have been suggested to cope with this:

1.  This can be solved with Andy's proposal to allow other
    parameters in the capability string in YANG.  Something like:

  capability-string   = namespace-uri [ parameter-list ]
  parameter-list      = "?" parameter *( "&" parameter )
  parameter           = revision-parameter /
                        module-parameter /
                        feature-parameter /
                        deviation-parameter /
                        other-parameter

  Where "other-parameter" is a "<key>=<value>" parameter.


2.  Do not change YANG, and instead use a normal capability to pass
    "protocol information".  In the url case, url would be advertised
    as a feature, and its schemes would be advertised as a capability.
 

In both cases, there are no formal YANG constructs to define this
extra information; it would have to be defined in text.

I did not like alt. 2 when Andy suggested it for with-defaults, but I
have changed my mind.  I think both these alternatives work.


> I do not think we need CLRs about what parts of the <hello> a client
> is allowed to use.

My point was that a pure 4741bis server would not send all the old
capabilities, so a 4741bis client needs to look at the features to
figure out what the server supports.


/martin

From andyb@iwl.com  Thu Apr  8 10:11:01 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D893A69C5 for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 10:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level: 
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WCHscom-kCX for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 10:11:00 -0700 (PDT)
Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 039F03A69A6 for <netconf@ietf.org>; Thu,  8 Apr 2010 10:11:00 -0700 (PDT)
Received: from relay24.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C5C2B34E8459; Thu,  8 Apr 2010 13:10:56 -0400 (EDT)
Received: by relay24.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7E13D34E844B;  Thu,  8 Apr 2010 13:10:56 -0400 (EDT)
Message-ID: <4BBE0E11.4090008@iwl.com>
Date: Thu, 08 Apr 2010 10:10:41 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BBDD383.1060900@iwl.com>	<20100408130535.GA3377@elstar.local>	<4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com>
In-Reply-To: <20100408.182351.75186165.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 17:11:02 -0000

Martin Bjorklund wrote:
> Andy Bierman <andyb@iwl.com> wrote:
>> Juergen Schoenwaelder wrote:
>>> On Thu, Apr 08, 2010 at 03:00:51PM +0200, Andy Bierman wrote:
>>>> Juergen Schoenwaelder wrote:
>>>>> On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
>>>>>> by the server and client to indicate support for 4741bis message
>>>>>> layer.  Then the normal YANG capability is used by a 4741bis server to
>>>>>> indicate support for 4741bis operations, and the old capabilities are
>>>>>> used to indicate support for the 4741 operations to old clients.
>>>>>>
>>>>>> 4741bis-only server advertises:
>>>>>>    base:1.1
>>>>>>    YANG capability (namespace + features)
>>>>>>
>>>>>> 4741bis + 4741 server advertises:
>>>>>>    base:1.1
>>>>>>    YANG capability (namespace + features)
>>>>>>    base:1.0
>>>>>>    4741-capabilites (:startup etc)
>>>>>>
>>>>>> 4741bis-only client advertises:
>>>>>>    base:1.1
>>>>>>
>>>>>> 4741bis + 4741 client advertises:
>>>>>>    base:1.0
>>>>>>    base:1.1
>>>>>>
>>>>>> If the effective protocol is base:1.1, then the client checks the
>>>>>> features to see what the server can do.
>>>>>>
>>>>>> If the effective protocol is base:1.0, then the client checks the
>>>>>> capabilities to see what the server can do.
>>>>> This looks reasonable to me.
>>>> Except YANG features have no way of passing parameters, so
>>>> they will never work for :url or :with-defaults.
> 
> I agree that features should not be (mis)used to carry information
> about e.g. url schemes.  The YANG spec says about feature:
> 
>   feature: A mechanism for marking a portion of the model as optional
> 
> Two alternatives have been suggested to cope with this:
> 
> 1.  This can be solved with Andy's proposal to allow other
>     parameters in the capability string in YANG.  Something like:
> 
>   capability-string   = namespace-uri [ parameter-list ]
>   parameter-list      = "?" parameter *( "&" parameter )
>   parameter           = revision-parameter /
>                         module-parameter /
>                         feature-parameter /
>                         deviation-parameter /
>                         other-parameter
> 
>   Where "other-parameter" is a "<key>=<value>" parameter.
> 
> 
> 2.  Do not change YANG, and instead use a normal capability to pass
>     "protocol information".  In the url case, url would be advertised
>     as a feature, and its schemes would be advertised as a capability.
>  

I prefer this solution, rather than re-opening the YANG spec.

> 
> In both cases, there are no formal YANG constructs to define this
> extra information; it would have to be defined in text.
> 
> I did not like alt. 2 when Andy suggested it for with-defaults, but I
> have changed my mind.  I think both these alternatives work.
> 
> 
>> I do not think we need CLRs about what parts of the <hello> a client
>> is allowed to use.
> 
> My point was that a pure 4741bis server would not send all the old
> capabilities, so a 4741bis client needs to look at the features to
> figure out what the server supports.
> 

The :url and :with-defaults capabilities will need to be advertised,
even in a 1.1-only server.

In addition, the url feature in ietf-netconf.yang needs to be set
to enable/disable the <url> parameter in protocol operations.

I prefer to keep the YANG module capability set complete,
which means if module A imports B, then a capability URI
for B MUST be present in the <hello>.  (Even if B is ietf-netconf.yang)
This is what the YANG spec says now, and we should not change it now.

The YANG capability URIs give a complete picture of the operations and content
supported in a particular session.

For a complete picture of the protocol behavior (not covered by YANG),
the base:1.0 and/or base:1.1 capabilities are used, plus the parameter
values for :url and/or :with-defaults.

(and what about capability-change -- how does the client opt-in or opt-out
of capability-changed errors? An RPC? A capability in the client <hello>?)


> 
> /martin
> 


Andy


From mbj@tail-f.com  Thu Apr  8 11:45:31 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220073A697D for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 11:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.437
X-Spam-Level: 
X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=0.609,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OowsOADMv93J for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 11:45:30 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EA9103A67DB for <netconf@ietf.org>; Thu,  8 Apr 2010 11:45:29 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 97A3D616002; Thu,  8 Apr 2010 20:45:25 +0200 (CEST)
Date: Thu, 08 Apr 2010 20:45:25 +0200 (CEST)
Message-Id: <20100408.204525.17558573.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BBE0E11.4090008@iwl.com>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 18:45:31 -0000

Andy Bierman <andyb@iwl.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <andyb@iwl.com> wrote:
> >> Juergen Schoenwaelder wrote:
> >>> On Thu, Apr 08, 2010 at 03:00:51PM +0200, Andy Bierman wrote:
> >>>> Juergen Schoenwaelder wrote:
> >>>>> On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>> Hmm.  So maybe this is the solution.  The base:1.1 capability is used
> >>>>>> by the server and client to indicate support for 4741bis message
> >>>>>> layer.  Then the normal YANG capability is used by a 4741bis server to
> >>>>>> indicate support for 4741bis operations, and the old capabilities are
> >>>>>> used to indicate support for the 4741 operations to old clients.
> >>>>>>
> >>>>>> 4741bis-only server advertises:
> >>>>>>    base:1.1
> >>>>>>    YANG capability (namespace + features)
> >>>>>>
> >>>>>> 4741bis + 4741 server advertises:
> >>>>>>    base:1.1
> >>>>>>    YANG capability (namespace + features)
> >>>>>>    base:1.0
> >>>>>>    4741-capabilites (:startup etc)
> >>>>>>
> >>>>>> 4741bis-only client advertises:
> >>>>>>    base:1.1
> >>>>>>
> >>>>>> 4741bis + 4741 client advertises:
> >>>>>>    base:1.0
> >>>>>>    base:1.1
> >>>>>>
> >>>>>> If the effective protocol is base:1.1, then the client checks the
> >>>>>> features to see what the server can do.
> >>>>>>
> >>>>>> If the effective protocol is base:1.0, then the client checks the
> >>>>>> capabilities to see what the server can do.
> >>>>> This looks reasonable to me.
> >>>> Except YANG features have no way of passing parameters, so
> >>>> they will never work for :url or :with-defaults.
> > 
> > I agree that features should not be (mis)used to carry information
> > about e.g. url schemes.  The YANG spec says about feature:
> > 
> >   feature: A mechanism for marking a portion of the model as optional
> > 
> > Two alternatives have been suggested to cope with this:
> > 
> > 1.  This can be solved with Andy's proposal to allow other
> >     parameters in the capability string in YANG.  Something like:
> > 
> >   capability-string   = namespace-uri [ parameter-list ]
> >   parameter-list      = "?" parameter *( "&" parameter )
> >   parameter           = revision-parameter /
> >                         module-parameter /
> >                         feature-parameter /
> >                         deviation-parameter /
> >                         other-parameter
> > 
> >   Where "other-parameter" is a "<key>=<value>" parameter.
> > 
> > 
> > 2.  Do not change YANG, and instead use a normal capability to pass
> >     "protocol information".  In the url case, url would be advertised
> >     as a feature, and its schemes would be advertised as a capability.
> >  
> 
> I prefer this solution, rather than re-opening the YANG spec.

Ok.

> > In both cases, there are no formal YANG constructs to define this
> > extra information; it would have to be defined in text.
> > 
> > I did not like alt. 2 when Andy suggested it for with-defaults, but I
> > have changed my mind.  I think both these alternatives work.
> > 
> > 
> >> I do not think we need CLRs about what parts of the <hello> a client
> >> is allowed to use.
> > 
> > My point was that a pure 4741bis server would not send all the old
> > capabilities, so a 4741bis client needs to look at the features to
> > figure out what the server supports.
> > 
> 
> The :url and :with-defaults capabilities will need to be advertised,
> even in a 1.1-only server.

Yes.

> In addition, the url feature in ietf-netconf.yang needs to be set
> to enable/disable the <url> parameter in protocol operations.

Yes.

> I prefer to keep the YANG module capability set complete,
> which means if module A imports B, then a capability URI
> for B MUST be present in the <hello>.  (Even if B is ietf-netconf.yang)
> This is what the YANG spec says now, and we should not change it now.
> 
> The YANG capability URIs give a complete picture of the operations and content
> supported in a particular session.
> 
> For a complete picture of the protocol behavior (not covered by YANG),
> the base:1.0 and/or base:1.1 capabilities are used, plus the parameter
> values for :url and/or :with-defaults.

Yes.

> (and what about capability-change -- how does the client opt-in or opt-out
> of capability-changed errors? An RPC? A capability in the client <hello>?)

As proposed earlier, by sending a parameter in its base:1.1 capability
advertisement.

It seems we have an acceptable solution.  So what do other people
think?

If we do this, it will require quite some work in 4741bis.  We need to
talk about features instead of capabilities.



/martin

From andyb@iwl.com  Thu Apr  8 12:36:44 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338723A6ABE for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 12:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFC9pTjraJwO for <netconf@core3.amsl.com>; Thu,  8 Apr 2010 12:36:43 -0700 (PDT)
Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 3FD0E3A6943 for <netconf@ietf.org>; Thu,  8 Apr 2010 12:36:43 -0700 (PDT)
Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id EFA031B4F0F; Thu,  8 Apr 2010 15:36:38 -0400 (EDT)
Received: by relay21.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DA08E1B4F1B;  Thu,  8 Apr 2010 15:36:30 -0400 (EDT)
Message-ID: <4BBE302F.3040401@iwl.com>
Date: Thu, 08 Apr 2010 12:36:15 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "lhotka@cesnet.cz" <lhotka@cesnet.cz>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBC9C3E.5030501@iwl.com>	<20100408.083434.188386942.mbj@tail-f.com>	<1270717644.2788.25.camel@missotis>	<20100408.111256.234694443.mbj@tail-f.com> <20100408111700.GA2780@elstar.local>
In-Reply-To: <20100408111700.GA2780@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 19:36:44 -0000

Juergen Schoenwaelder wrote:
> On Thu, Apr 08, 2010 at 11:12:56AM +0200, Martin Bjorklund wrote:
>> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
>>> Martin Bjorklund p????e v ??t 08. 04. 2010 v 08:34 +0200:
>>>
>>>> So here are the alternatives:
>>>>
>>>>   1.  capability-based
>>>>       advertise base:1.1 capability + other capabilities as in 4741
>>>>       do not advertise the YANG-defined capability.
>>>>
>>>>       Pro: requires less changes to code and doc
>>>>       Con: not yangy
>>>>
>>>>   2.  pure YANG
>>>>       just follow YANG rules, and advertise the namespace + features.
>>>>       there is no base:1.1 capability to advertise.
>>> Strictly speaking, this option is not "pure YANG" but rather "misused
>>> YANG". The spec positions YANG quite clearly as "a language used to
>>> model data for the NETCONF protocol". In this case, YANG is used for
>>> (re)defining the NETCONF protocol itself, which is IMO clearly outside
>>> the scope of YANG and therefore incorrect. In fact, by doing so, YANG is
>>> made into yet another XML schema language.
>> I disagree.  The YANG spec says:
>>
>>   YANG is used to model the operations and content layers of NETCONF
>>
>> What we're doing in ietf-netconf.yang is modelling the core NETCONF
>> operations.
>>
>> We're not doing anything with the Messages layer (*that* would be
>> misusing YANG).
> 
> +1


I do not think we can put the genie back in the bottle now. ;-)
People are discovering other applications for YANG
besides the approved NETCONF operations, notification events,
and data nodes.

For example, a data-driven implementation may choose to create or validate
<rpc-error> contents with YANG derived data structures.
Perhaps the entire NM stack is data-driven from YANG files,
including the CLI and .conf parameters, the WEBui, the CLI,
and maybe even the SNMP agent.

I understand the YANG spec needs to keep the scope limited to NETCONF,
but it also allows language extensions,
and those do not have to be limited to NETCONF.



> 
> /js
> 

Andy

From lhotka@cesnet.cz  Fri Apr  9 01:27:02 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A263A691B for <netconf@core3.amsl.com>; Fri,  9 Apr 2010 01:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4erYunB-YMdV for <netconf@core3.amsl.com>; Fri,  9 Apr 2010 01:27:01 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 08C043A6A09 for <netconf@ietf.org>; Fri,  9 Apr 2010 01:26:12 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 638CB2CDE059; Fri,  9 Apr 2010 10:26:08 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100408.204525.17558573.mbj@tail-f.com>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Fri, 09 Apr 2010 10:26:07 +0200
Message-ID: <1270801567.6878.1.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 08:27:02 -0000

Martin Bjorklund píše v Čt 08. 04. 2010 v 20:45 +0200:
> It seems we have an acceptable solution.  So what do other people
> think?

Martin, could you please summarize this solution? I must admit I am a
bit lost.

Thanks, Lada

> 
> If we do this, it will require quite some work in 4741bis.  We need to
> talk about features instead of capabilities.
> 
> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From andyb@iwl.com  Fri Apr  9 13:51:08 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BDB3A695F for <netconf@core3.amsl.com>; Fri,  9 Apr 2010 13:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level: 
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-1.230,  BAYES_20=-0.74, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YengH1NFx-7y for <netconf@core3.amsl.com>; Fri,  9 Apr 2010 13:51:07 -0700 (PDT)
Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by core3.amsl.com (Postfix) with ESMTP id 3F4183A63EC for <netconf@ietf.org>; Fri,  9 Apr 2010 13:51:07 -0700 (PDT)
Received: from relay23.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 3F99C1B42DA for <netconf@ietf.org>; Fri,  9 Apr 2010 16:51:03 -0400 (EDT)
Received: by relay23.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0BB541B42D1 for <netconf@ietf.org>; Fri,  9 Apr 2010 16:51:02 -0400 (EDT)
Message-ID: <4BBF931E.4060603@iwl.com>
Date: Fri, 09 Apr 2010 13:50:38 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Netconf] making more 4741bis waves
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 20:51:08 -0000

Hi,

I have some new issues for 4741bis:

1) test-only enum

   I really dislike using a protocol capability for 1 enum value of
   1 parameter of 1 RPC operation.  Is there a way to avoid this?

   We never actually solved the problem of what <validate> means,
   or what 'test-then-set', 'test-only' means, so it's not like the :validate
   capability is something special. (See 2 below).

   We should make it more clear what a server does for validation:
        #1)  test-then-set == test-only == validate, except for a conceptual
             config made from the config source and the target config.
             A validate is done on a conceptually complete database.
             Only the test part of test-then-set is considered here.
        #2) The server MUST detect all schema errors
        #3) The server SHOULD detect all platform-specific constraints
            that are specified in description statements instead of
            machine-readable statements.
        #4) The server MAY detect resource allocation errors.
        #5) The server MAY detect network-wide constraint violations


2) <test-option> present is an error

   Balazs complained before that a client MUST NOT set the <test-option>
   leaf if :validate is not advertised, even though there are
   defaults defined for the server for both modes.  This is a CLR.
   We should just make the <test-option> optional in base:1.1
   and the server MUST use the appropriate default.

3) <test-option> default

   It is very resource-intensive to default the test-option to test-then-set
   on the candidate config.  This also breaks incremental changes to candidate,
   since the test-then-set option means "make sure the entire database is valid".

   IMO, this should be fixed.  It would be simpler if there was just
   an plain optional default with a default:

   OLD:

        leaf test-option {
           if-feature validate;
           type enumeration {
             enum test-then-set;
             enum set;
             enum test-only {
               description
                 "This value can only be used if the 'validate-1.1'
                  feature is supported.";
             }
           }
         }

   NEW:

        leaf test-option {
           type enumeration {
             enum test-then-set {
               description
                 "This value can only be used if the 'validate'
                  feature is supported.";
             enum set;
             enum test-only {
               description
                 "This value can only be used if the 'base-1.1'
                  capability is supported.

                  If the 'validate' feature is also supported,
                  then the server will perform a complete
                  validation procedure.

                  If the 'validate' feature is not supported,
                  then the server will make a best-effort attempt
                  to detect any errors in the <edit-config> request.";
             }
           }
           default set;
        }

4) new 'destroy' operation

   The nc:delete operation is too picky.
   The server MUST return a 'data-missing' error-tag if the data
   instances do not exist as predicted by the client.

   A new operation called 'destroy' would be like an 'rm -f' command.
   The data is deleted if it exists.
   The requested data MUST identify data nodes that the server supports
   but if the requested instances do not exist, then <ok/>  is still returned.



Andy

From j.schoenwaelder@jacobs-university.de  Sat Apr 10 01:28:05 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5639A3A6958 for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 01:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.433
X-Spam-Level: 
X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syQOoSiQrsDR for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 01:28:04 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED26E3A69D9 for <netconf@ietf.org>; Sat, 10 Apr 2010 01:28:03 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03F85C000A; Sat, 10 Apr 2010 10:27:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rkQt6QyTBdQa; Sat, 10 Apr 2010 10:27:56 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED14BC0004; Sat, 10 Apr 2010 10:27:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A774A117B81D; Sat, 10 Apr 2010 10:27:55 +0200 (CEST)
Date: Sat, 10 Apr 2010 10:27:55 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20100410082755.GA7256@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, "andyb@iwl.com" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100408.204525.17558573.mbj@tail-f.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 08:28:05 -0000

On Thu, Apr 08, 2010 at 08:45:25PM +0200, Martin Bjorklund wrote:

[...]
 
> It seems we have an acceptable solution.  So what do other people
> think?

I disagree that we have an acceptable solution. I think there is quite
some evidence that something is wrong if we are faced with two YANG
modules where the YANG feature advertisement mechanism is not good
enough to do the job. I rather like to get this fixed instead of
special casing this for these two modules by resorting to hand crafted
capabilities because I am sure we will hit this again with other data
models.

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

From j.schoenwaelder@jacobs-university.de  Sat Apr 10 01:38:13 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726BC3A698B for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 01:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.47
X-Spam-Level: 
X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.635,  BAYES_40=-0.185, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCvzVD87YmeK for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 01:38:12 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7DD9B3A62C1 for <netconf@ietf.org>; Sat, 10 Apr 2010 01:38:12 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F706C000A for <netconf@ietf.org>; Sat, 10 Apr 2010 10:38:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qUAis2Ah5bMD; Sat, 10 Apr 2010 10:38:07 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 755A9C0004; Sat, 10 Apr 2010 10:38:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6F97B117B88A; Sat, 10 Apr 2010 10:38:07 +0200 (CEST)
Date: Sat, 10 Apr 2010 10:38:07 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netconf@ietf.org
Message-ID: <20100410083807.GB7256@elstar.local>
Mail-Followup-To: netconf@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Netconf] merging with-defaults into 4741bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 08:38:13 -0000

Hi,

I propose to merge with-defaults into 4741bis. Since we do 1.1 and
with-defaults really is a clarification of how differnet 4741
implementations work, merging with-defaults into 4741bis seems
technically the simplest and cleanest solution.

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

From andyb@iwl.com  Sat Apr 10 02:33:13 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31103A68F8 for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 02:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swv9jzAStFoh for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 02:33:12 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id D21483A67A5 for <netconf@ietf.org>; Sat, 10 Apr 2010 02:33:10 -0700 (PDT)
Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 98AD630351;  Sat, 10 Apr 2010 05:33:06 -0400 (EDT)
Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 69576301B5;  Sat, 10 Apr 2010 05:33:06 -0400 (EDT)
Message-ID: <4BC045A9.5090503@iwl.com>
Date: Sat, 10 Apr 2010 02:32:25 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com> <20100410082755.GA7256@elstar.local>
In-Reply-To: <20100410082755.GA7256@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 09:33:13 -0000

Juergen Schoenwaelder wrote:
> On Thu, Apr 08, 2010 at 08:45:25PM +0200, Martin Bjorklund wrote:
> 
> [...]
>  
>> It seems we have an acceptable solution.  So what do other people
>> think?
> 
> I disagree that we have an acceptable solution. I think there is quite
> some evidence that something is wrong if we are faced with two YANG
> modules where the YANG feature advertisement mechanism is not good
> enough to do the job. I rather like to get this fixed instead of
> special casing this for these two modules by resorting to hand crafted
> capabilities because I am sure we will hit this again with other data
> models.

I disagree that YANG features were designed to do the same job
as :url?scheme=ftp,file,sftp or :with-defaults?basic-mode=explicit.

As Martin pointed out, YANG features are designed to be used
with the if-feature statement to partition module contents.

I do not see any reason to change existing protocol capabilities
or not to use new ones in the future, if needed.

There are parts of the NETCONF protocol that YANG does not cover.
This is part of the charter,

YANG feature advertisement is a boolean.
That is unacceptable for some protocol capability parameters.

Using YANG features as a choice is broken:

   feature basic-is-explicit;
   feature basic-is-report-all;
   feature basic-is-trim;
   feature also-supported-is-none;
   feature also-supported-is-trim;
   feature also-supported-is-explicit;
   feature also-supported-is-report-all;
   feature also-supported-is-trim-and-explicit;
   feature also-supported-is-trim-and-report-all;
   feature also-supported-is-explicit-and-report-all;


 1)  There is nothing in YANG that tells the client that only
     2 of these features can possibly be present on a particular server.
 2) There is no meaning or error to generate if other combinations
    of these features are advertised.
 3) this is a cumbersome solution, even for 3 independent variables
 4) the :url scheme has an unbounded list of permutations, so this solution
    is impossible for :url, not just unwieldy
 5) there are no YANG module contents associated with any of these features
    so they represent a misuse of the feature-stmt


> 
> /js
>  

Andy

From andyb@iwl.com  Sat Apr 10 02:38:23 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F0E3A684D for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 02:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhprsIAyWNaG for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 02:38:22 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id B48B83A67A5 for <netconf@ietf.org>; Sat, 10 Apr 2010 02:38:22 -0700 (PDT)
Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C808E301D4 for <netconf@ietf.org>; Sat, 10 Apr 2010 05:38:18 -0400 (EDT)
Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AA320300FE for <netconf@ietf.org>; Sat, 10 Apr 2010 05:38:18 -0400 (EDT)
Message-ID: <4BC046E6.8040305@iwl.com>
Date: Sat, 10 Apr 2010 02:37:42 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: netconf@ietf.org
References: <20100410083807.GB7256@elstar.local>
In-Reply-To: <20100410083807.GB7256@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] merging with-defaults into 4741bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 09:38:23 -0000

Juergen Schoenwaelder wrote:
> Hi,
> 
> I propose to merge with-defaults into 4741bis. Since we do 1.1 and
> with-defaults really is a clarification of how differnet 4741
> implementations work, merging with-defaults into 4741bis seems
> technically the simplest and cleanest solution.
> 

I object to this change.
This will only slow down both documents.
If YANG is incapable of being used to augment a simple operation
with one parameter, then we should toss it out now.

Starting over on with-defaults now is not an option.
This tiny document has taken way too long already.



> /js
> 


Andy


From j.schoenwaelder@jacobs-university.de  Sat Apr 10 03:20:38 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFD43A67A5 for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 03:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Level: 
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.614,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3YUgjTjhuiB for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 03:20:35 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 050873A6782 for <netconf@ietf.org>; Sat, 10 Apr 2010 03:20:14 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B67BC000A; Sat, 10 Apr 2010 12:20:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QYo85ck+xiTb; Sat, 10 Apr 2010 12:20:06 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A3B6C0004; Sat, 10 Apr 2010 12:20:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 84C36117BB52; Sat, 10 Apr 2010 12:20:06 +0200 (CEST)
Date: Sat, 10 Apr 2010 12:20:06 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100410102006.GA7453@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <20100410083807.GB7256@elstar.local> <4BC046E6.8040305@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BC046E6.8040305@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] merging with-defaults into 4741bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 10:20:38 -0000

On Sat, Apr 10, 2010 at 11:37:42AM +0200, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > Hi,
> > 
> > I propose to merge with-defaults into 4741bis. Since we do 1.1 and
> > with-defaults really is a clarification of how differnet 4741
> > implementations work, merging with-defaults into 4741bis seems
> > technically the simplest and cleanest solution.
> > 
> 
> I object to this change.
> This will only slow down both documents.
> If YANG is incapable of being used to augment a simple operation
> with one parameter, then we should toss it out now.
> 
> Starting over on with-defaults now is not an option.
> This tiny document has taken way too long already.

Merging might make it simpler and faster. You got the point. ;-)

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

From j.schoenwaelder@jacobs-university.de  Sat Apr 10 03:24:35 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9563A6832 for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 03:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.673
X-Spam-Level: 
X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.576,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2qk2fCRBYvp for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 03:24:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3EE1B3A6782 for <netconf@ietf.org>; Sat, 10 Apr 2010 03:24:21 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02EFDC000A; Sat, 10 Apr 2010 12:24:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YRoExMdQ5-Q6; Sat, 10 Apr 2010 12:24:15 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A751C0004; Sat, 10 Apr 2010 12:24:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0522B117BBBD; Sat, 10 Apr 2010 12:24:14 +0200 (CEST)
Date: Sat, 10 Apr 2010 12:24:14 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100410102414.GB7453@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com> <20100410082755.GA7256@elstar.local> <4BC045A9.5090503@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BC045A9.5090503@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 10:24:35 -0000

On Sat, Apr 10, 2010 at 11:32:25AM +0200, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > On Thu, Apr 08, 2010 at 08:45:25PM +0200, Martin Bjorklund wrote:
> > 
> > [...]
> >  
> >> It seems we have an acceptable solution.  So what do other people
> >> think?
> > 
> > I disagree that we have an acceptable solution. I think there is quite
> > some evidence that something is wrong if we are faced with two YANG
> > modules where the YANG feature advertisement mechanism is not good
> > enough to do the job. I rather like to get this fixed instead of
> > special casing this for these two modules by resorting to hand crafted
> > capabilities because I am sure we will hit this again with other data
> > models.
> 
> I disagree that YANG features were designed to do the same job
> as :url?scheme=ftp,file,sftp or :with-defaults?basic-mode=explicit.
> 
> As Martin pointed out, YANG features are designed to be used
> with the if-feature statement to partition module contents.
> 
> I do not see any reason to change existing protocol capabilities
> or not to use new ones in the future, if needed.
> 
> There are parts of the NETCONF protocol that YANG does not cover.
> This is part of the charter,
> 
> YANG feature advertisement is a boolean.
> That is unacceptable for some protocol capability parameters.
> 
> Using YANG features as a choice is broken:
> 
>    feature basic-is-explicit;
>    feature basic-is-report-all;
>    feature basic-is-trim;
>    feature also-supported-is-none;
>    feature also-supported-is-trim;
>    feature also-supported-is-explicit;
>    feature also-supported-is-report-all;
>    feature also-supported-is-trim-and-explicit;
>    feature also-supported-is-trim-and-report-all;
>    feature also-supported-is-explicit-and-report-all;
> 
> 
>  1)  There is nothing in YANG that tells the client that only
>      2 of these features can possibly be present on a particular server.
>  2) There is no meaning or error to generate if other combinations
>     of these features are advertised.
>  3) this is a cumbersome solution, even for 3 independent variables
>  4) the :url scheme has an unbounded list of permutations, so this solution
>     is impossible for :url, not just unwieldy
>  5) there are no YANG module contents associated with any of these features
>     so they represent a misuse of the feature-stmt

My point remains - if YANG is not good enough to handle the core of
the NETCONF operations, we likely are not done with YANG. If YANG
features are not used to handle this, then YANG obviously lacks a
mechansims to handle such situations properly.

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

From andyb@iwl.com  Sat Apr 10 10:37:07 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090C33A6935 for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 10:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level: 
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pMyNG0EzPiu for <netconf@core3.amsl.com>; Sat, 10 Apr 2010 10:37:06 -0700 (PDT)
Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id D42D43A692C for <netconf@ietf.org>; Sat, 10 Apr 2010 10:37:05 -0700 (PDT)
Received: from relay22.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id A9CD4C080EB; Sat, 10 Apr 2010 13:37:01 -0400 (EDT)
Received: by relay22.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 46E39C080E5;  Sat, 10 Apr 2010 13:37:01 -0400 (EDT)
Message-ID: <4BC0B71C.3090003@iwl.com>
Date: Sat, 10 Apr 2010 10:36:28 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <4BBDF4AE.3050908@iwl.com> <20100408.182351.75186165.mbj@tail-f.com> <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com> <20100410082755.GA7256@elstar.local> <4BC045A9.5090503@iwl.com> <20100410102414.GB7453@elstar.local>
In-Reply-To: <20100410102414.GB7453@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2010 17:37:07 -0000

Juergen Schoenwaelder wrote:
> On Sat, Apr 10, 2010 at 11:32:25AM +0200, Andy Bierman wrote:
>> Juergen Schoenwaelder wrote:
>>> On Thu, Apr 08, 2010 at 08:45:25PM +0200, Martin Bjorklund wrote:
>>>
>>> [...]
>>>  
>>>> It seems we have an acceptable solution.  So what do other people
>>>> think?
>>> I disagree that we have an acceptable solution. I think there is quite
>>> some evidence that something is wrong if we are faced with two YANG
>>> modules where the YANG feature advertisement mechanism is not good
>>> enough to do the job. I rather like to get this fixed instead of
>>> special casing this for these two modules by resorting to hand crafted
>>> capabilities because I am sure we will hit this again with other data
>>> models.
>> I disagree that YANG features were designed to do the same job
>> as :url?scheme=ftp,file,sftp or :with-defaults?basic-mode=explicit.
>>
>> As Martin pointed out, YANG features are designed to be used
>> with the if-feature statement to partition module contents.
>>
>> I do not see any reason to change existing protocol capabilities
>> or not to use new ones in the future, if needed.
>>
>> There are parts of the NETCONF protocol that YANG does not cover.
>> This is part of the charter,
>>
>> YANG feature advertisement is a boolean.
>> That is unacceptable for some protocol capability parameters.
>>
>> Using YANG features as a choice is broken:
>>
>>    feature basic-is-explicit;
>>    feature basic-is-report-all;
>>    feature basic-is-trim;
>>    feature also-supported-is-none;
>>    feature also-supported-is-trim;
>>    feature also-supported-is-explicit;
>>    feature also-supported-is-report-all;
>>    feature also-supported-is-trim-and-explicit;
>>    feature also-supported-is-trim-and-report-all;
>>    feature also-supported-is-explicit-and-report-all;
>>
>>
>>  1)  There is nothing in YANG that tells the client that only
>>      2 of these features can possibly be present on a particular server.
>>  2) There is no meaning or error to generate if other combinations
>>     of these features are advertised.
>>  3) this is a cumbersome solution, even for 3 independent variables
>>  4) the :url scheme has an unbounded list of permutations, so this solution
>>     is impossible for :url, not just unwieldy
>>  5) there are no YANG module contents associated with any of these features
>>     so they represent a misuse of the feature-stmt
> 
> My point remains - if YANG is not good enough to handle the core of
> the NETCONF operations, we likely are not done with YANG. If YANG
> features are not used to handle this, then YANG obviously lacks a
> mechansims to handle such situations properly.
> 

We had some solution proposals to deal with capabilities
but the WG decided not to support any modeling of NETCONF capabilities.
It is missing from YANG by choice.

At some point we need to finish this
work and publish it.  Rearranging the deliverables and
re-opening the YANG spec to add more stuff to it
will only delay the 1.0 by another year or more.


> /js
> 


Andy


From mbj@tail-f.com  Mon Apr 12 05:41:01 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4781B3A6A35 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 05:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.057
X-Spam-Level: 
X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6iZZ7KzZN05 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 05:41:00 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1EA353A6A33 for <netconf@ietf.org>; Mon, 12 Apr 2010 05:40:59 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DDFC676C528; Mon, 12 Apr 2010 14:40:53 +0200 (CEST)
Date: Mon, 12 Apr 2010 14:40:53 +0200 (CEST)
Message-Id: <20100412.144053.17641150.mbj@tail-f.com>
To: lhotka@cesnet.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1270801567.6878.1.camel@missotis>
References: <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com> <1270801567.6878.1.camel@missotis>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 12:41:01 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr
bHVuZCBww63FoWUgdiDEjHQgMDguIDA0LiAyMDEwIHYgMjA6NDUgKzAyMDA6DQo+ID4gSXQgc2Vl
bXMgd2UgaGF2ZSBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uLiAgU28gd2hhdCBkbyBvdGhlciBwZW9w
bGUNCj4gPiB0aGluaz8NCj4gDQo+IE1hcnRpbiwgY291bGQgeW91IHBsZWFzZSBzdW1tYXJpemUg
dGhpcyBzb2x1dGlvbj8gSSBtdXN0IGFkbWl0IEkgYW0gYQ0KPiBiaXQgbG9zdC4NCg0KMS4gIFRo
ZSBiYXNlOjEuMSBjYXBhYmlsaXR5IGlzIHVzZWQgYnkgdGhlIHNlcnZlciBhbmQgY2xpZW50IHRv
DQogICAgaW5kaWNhdGUgc3VwcG9ydCBmb3IgNDc0MWJpcyBtZXNzYWdlIGxheWVyLg0KDQogICAg
VGhlbiB0aGUgbm9ybWFsIFlBTkcgY2FwYWJpbGl0eSAod2l0aCBmZWF0dXJlcz0gZXRjKSBpcyB1
c2VkIGJ5IGENCiAgICA0NzQxYmlzIHNlcnZlciB0byBpbmRpY2F0ZSBzdXBwb3J0IGZvciA0NzQx
YmlzIG9wZXJhdGlvbnMsIGFuZCB0aGUNCiAgICBvbGQgY2FwYWJpbGl0aWVzIGFyZSB1c2VkIHRv
IGluZGljYXRlIHN1cHBvcnQgZm9yIHRoZSA0NzQxDQogICAgb3BlcmF0aW9ucyB0byBvbGQgY2xp
ZW50cy4NCg0KICAgIChzZWUNCiAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93
ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA1NjAyLmh0bWwNCiAgICBmb3IgbW9yZSBkZXRhaWxzKQ0K
DQoyLiAgQSBjbGllbnQgdGhhdCB3YW50cyB0aGUgc3RyaWN0IGNhcGFiaWxpdHkgY2hhbmdlIGJl
aGF2aW9yDQogICAgYWR2ZXJ0aXNlczoNCg0KICAgICA6YmFzZToxLjE/c3RyaWN0LWNhcGFiaWxp
dGllcw0KDQogICAgKG9yIHNvbWV0aGluZyBsaWtlIHRoYXQpDQoNCiAgICBJZiB0aGUgY2xpZW50
IGRvZXNuJ3QgYWR2ZXJ0aXNlIHRoYXQsIHRoZSBzZXJ2ZXIgd2lsbCBhbGxvdw0KICAgIGNhcGFi
aWxpdGllcyB0byBkeW5hbWljYWxseSBjaGFuZ2Ugdy9vIGdpdmluZyBhbnkNCiAgICAnY2FwYWJp
bGl0aWVzLWNoYW5nZWQnIGVycm9ycy4NCg0KVGhlIHJlbWFpbmluZyBwcm9ibGVtIGlzIGhvdyB0
byBkZWFsIHdpdGggdGhlIDp1cmwgc2NoZW1lIHBhcmFtZXRlcg0KYW5kIHRoZSA6d2l0aC1kZWZh
dWx0cyBiYXNpYy1tb2RlIGFuZCBhbHNvLXN1cHBvcnRlZCBwYXJhbWV0ZXJzOg0KKHNlZSBodHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA1NjA3
Lmh0bWwpDQoNCjNhLiBDaGFuZ2UgWUFORyB0byBleHBsaWNpdHkgYWxsb3cgZXh0cmEgcGFyYW1l
dGVycyBpbiB0aGUgY2FwYWJpbGl0eQ0KICAgIHN0cmluZy4NCg0Kb3INCg0KM2IuIFVzZSBhIG5v
cm1hbCBjYXBhYmlsaXR5IHRvIHBhc3MgZXh0cmEgcGFyYW1ldGVycy4gIFRoaXMgcmVxdWlyZXMN
CiAgICBubyBjaGFuZ2VzIHRvIFlBTkcuDQoNCkluIGJvdGggM2EgYW5kIDNiIHRoZXJlIHdvdWxk
IGJlIG5vIGZvcm1hbCBZQU5HIHN0YXRlbWVudCB0byBkZWZpbmUNCnRoZXNlIGV4dHJhIHBhcmFt
ZXRlcnMuDQoNCkFuZHkgcHJlZmVycyAzYiwgYW5kIEkgcGVyc29uYWxseSB0aGluayBib3RoIDNh
IGFuZCAzYiB3b3Jrcy4NCg0KSSB0aGluayBKdWVyZ2VuIG9iamVjdHMgdG8gYm90aCAzYSBhbmQg
M2IsIGJlY2F1c2UgaGUgd2FudHMgYSBmb3JtYWwNCndheSB0byBzcGVjaWZ5IGV4dHJhIHBhcmFt
ZXRlcnMgaW4gWUFORy4gIEp1ZXJnZW4gaXMgdGhhdCBjb3JyZWN0Pw0KDQoNCg0KL21hcnRpbg0K
DQoNCg0KDQogICAgDQo=

From lhotka@cesnet.cz  Mon Apr 12 06:29:47 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EB73A6832 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.064
X-Spam-Level: 
X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqJAKpy51aLq for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:29:46 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7D9183A68B9 for <netconf@ietf.org>; Mon, 12 Apr 2010 06:29:46 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 1CB7A2CDE059; Mon, 12 Apr 2010 15:29:40 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100412.144053.17641150.mbj@tail-f.com>
References: <4BBE0E11.4090008@iwl.com> <20100408.204525.17558573.mbj@tail-f.com> <1270801567.6878.1.camel@missotis> <20100412.144053.17641150.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Mon, 12 Apr 2010 15:29:38 +0200
Message-ID: <1271078978.14883.47.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 13:29:47 -0000

Martin Bjorklund píše v Po 12. 04. 2010 v 14:40 +0200:
> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
> > Martin Bjorklund píše v Čt 08. 04. 2010 v 20:45 +0200:
> > > It seems we have an acceptable solution.  So what do other people
> > > think?
> > 
> > Martin, could you please summarize this solution? I must admit I am a
> > bit lost.
> 
> 1.  The base:1.1 capability is used by the server and client to
>     indicate support for 4741bis message layer.

And the base:1.0 capability will have to be advertized in any case,
right? If so, I think it would make a very good sense to emphasize the
NETCONF layering and use a separate URI for operations, e.g.

urn:ietf:params:xml:ns:netconf:ops:1.1

In this case, a server/client supporting 4741bis would advertize
base:1.0 and ops:1.1, old server/client would advertize either base:1.0
and ops:1.0 or just base:1.0 (ops:1.0 will be considered default so that
old implementations continue to work). Finally, a server/client
supporting both versions would advertize base:1.0, ops:1.0 and ops:1.1.

The base:1.0 URI will only have to be changed if the hello protocol or
RPC layer changes (which may also never happen).

> 
>     Then the normal YANG capability (with features= etc) is used by a
>     4741bis server to indicate support for 4741bis operations, and the
>     old capabilities are used to indicate support for the 4741
>     operations to old clients.

Is the YANG capability really needed, if the 4741bis support is already
indicated via the capability URI?

> 
>     (see
>     http://www.ietf.org/mail-archive/web/netconf/current/msg05602.html
>     for more details)
> 
> 2.  A client that wants the strict capability change behavior
>     advertises:
> 
>      :base:1.1?strict-capabilities

Again, aren't capabilities sufficient to perform this task?

> 
>     (or something like that)
> 
>     If the client doesn't advertise that, the server will allow
>     capabilities to dynamically change w/o giving any
>     'capabilities-changed' errors.
> 
> The remaining problem is how to deal with the :url scheme parameter
> and the :with-defaults basic-mode and also-supported parameters:
> (see http://www.ietf.org/mail-archive/web/netconf/current/msg05607.html)
> 
> 3a. Change YANG to explicity allow extra parameters in the capability
>     string.
> 
> or
> 
> 3b. Use a normal capability to pass extra parameters.  This requires
>     no changes to YANG.
> 
> In both 3a and 3b there would be no formal YANG statement to define
> these extra parameters.
> 
> Andy prefers 3b, and I personally think both 3a and 3b works.

I prefer 3b.

Lada

> 
> I think Juergen objects to both 3a and 3b, because he wants a formal
> way to specify extra parameters in YANG.  Juergen is that correct?
> 
> 
> 
> /martin
> 
> 
> 
> 
>     


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From mbj@tail-f.com  Mon Apr 12 06:38:39 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F753A6A3E for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.158
X-Spam-Level: 
X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=0.888,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4jrG27HoNzQ for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:38:38 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC6373A6A49 for <netconf@ietf.org>; Mon, 12 Apr 2010 06:38:37 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A439376C528; Mon, 12 Apr 2010 15:38:32 +0200 (CEST)
Date: Mon, 12 Apr 2010 15:38:32 +0200 (CEST)
Message-Id: <20100412.153832.48993389.mbj@tail-f.com>
To: lhotka@cesnet.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1271078978.14883.47.camel@missotis>
References: <1270801567.6878.1.camel@missotis> <20100412.144053.17641150.mbj@tail-f.com> <1271078978.14883.47.camel@missotis>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 13:38:39 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr
bHVuZCBww63FoWUgdiBQbyAxMi4gMDQuIDIwMTAgdiAxNDo0MCArMDIwMDoNCj4gPiBMYWRpc2xh
diBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOg0KPiA+ID4gTWFydGluIEJqb3JrbHVu
ZCBww63FoWUgdiDEjHQgMDguIDA0LiAyMDEwIHYgMjA6NDUgKzAyMDA6DQo+ID4gPiA+IEl0IHNl
ZW1zIHdlIGhhdmUgYW4gYWNjZXB0YWJsZSBzb2x1dGlvbi4gIFNvIHdoYXQgZG8gb3RoZXIgcGVv
cGxlDQo+ID4gPiA+IHRoaW5rPw0KPiA+ID4gDQo+ID4gPiBNYXJ0aW4sIGNvdWxkIHlvdSBwbGVh
c2Ugc3VtbWFyaXplIHRoaXMgc29sdXRpb24/IEkgbXVzdCBhZG1pdCBJIGFtIGENCj4gPiA+IGJp
dCBsb3N0Lg0KPiA+IA0KPiA+IDEuICBUaGUgYmFzZToxLjEgY2FwYWJpbGl0eSBpcyB1c2VkIGJ5
IHRoZSBzZXJ2ZXIgYW5kIGNsaWVudCB0bw0KPiA+ICAgICBpbmRpY2F0ZSBzdXBwb3J0IGZvciA0
NzQxYmlzIG1lc3NhZ2UgbGF5ZXIuDQo+IA0KPiBBbmQgdGhlIGJhc2U6MS4wIGNhcGFiaWxpdHkg
d2lsbCBoYXZlIHRvIGJlIGFkdmVydGl6ZWQgaW4gYW55IGNhc2UsDQo+IHJpZ2h0Pw0KDQpObyBp
ZiB5b3UgZm9sbG93IHRoZSBsaW5rIEkgaW5jbHVkZWQgeW91IHdpbGwgc2VlIHRoYXQgaXQgaXMg
bm90LiAgVGhlDQppZGVhIGlzIHRoYXQgOmJhc2U6MS4wIG1lYW5zIHRoYXQgdGhlIDQ3NDEgbWVz
c2FnZSBsYXllciBpcyBzdXBwb3J0ZWQsDQphbmQgOmJhc2U6MS4xIG1lYW5zIHRoYXQgdGhlIDQ3
NDFiaXMgbWVzc2FnZSBsYXllciBpcyBzdXBwb3J0ZWQuDQoNCkEgbmV3IHNlcnZlciB3aGljaCBk
b2VzIG5vdCBoYXZlIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdvdWxkDQphZHZlcnRpc2Ug
OmJhc2U6MS4xIG9ubHkuDQoNCg0KPiBJZiBzbywgSSB0aGluayBpdCB3b3VsZCBtYWtlIGEgdmVy
eSBnb29kIHNlbnNlIHRvIGVtcGhhc2l6ZSB0aGUNCj4gTkVUQ09ORiBsYXllcmluZyBhbmQgdXNl
IGEgc2VwYXJhdGUgVVJJIGZvciBvcGVyYXRpb25zLCBlLmcuDQo+IA0KPiB1cm46aWV0ZjpwYXJh
bXM6eG1sOm5zOm5ldGNvbmY6b3BzOjEuMQ0KPiANCj4gSW4gdGhpcyBjYXNlLCBhIHNlcnZlci9j
bGllbnQgc3VwcG9ydGluZyA0NzQxYmlzIHdvdWxkIGFkdmVydGl6ZQ0KPiBiYXNlOjEuMCBhbmQg
b3BzOjEuMSwgb2xkIHNlcnZlci9jbGllbnQgd291bGQgYWR2ZXJ0aXplIGVpdGhlciBiYXNlOjEu
MA0KPiBhbmQgb3BzOjEuMCBvciBqdXN0IGJhc2U6MS4wIChvcHM6MS4wIHdpbGwgYmUgY29uc2lk
ZXJlZCBkZWZhdWx0IHNvIHRoYXQNCj4gb2xkIGltcGxlbWVudGF0aW9ucyBjb250aW51ZSB0byB3
b3JrKS4gRmluYWxseSwgYSBzZXJ2ZXIvY2xpZW50DQo+IHN1cHBvcnRpbmcgYm90aCB2ZXJzaW9u
cyB3b3VsZCBhZHZlcnRpemUgYmFzZToxLjAsIG9wczoxLjAgYW5kIG9wczoxLjEuDQo+IA0KPiBU
aGUgYmFzZToxLjAgVVJJIHdpbGwgb25seSBoYXZlIHRvIGJlIGNoYW5nZWQgaWYgdGhlIGhlbGxv
IHByb3RvY29sIG9yDQo+IFJQQyBsYXllciBjaGFuZ2VzICh3aGljaCBtYXkgYWxzbyBuZXZlciBo
YXBwZW4pLg0KPiANCj4gPiANCj4gPiAgICAgVGhlbiB0aGUgbm9ybWFsIFlBTkcgY2FwYWJpbGl0
eSAod2l0aCBmZWF0dXJlcz0gZXRjKSBpcyB1c2VkIGJ5IGENCj4gPiAgICAgNDc0MWJpcyBzZXJ2
ZXIgdG8gaW5kaWNhdGUgc3VwcG9ydCBmb3IgNDc0MWJpcyBvcGVyYXRpb25zLCBhbmQgdGhlDQo+
ID4gICAgIG9sZCBjYXBhYmlsaXRpZXMgYXJlIHVzZWQgdG8gaW5kaWNhdGUgc3VwcG9ydCBmb3Ig
dGhlIDQ3NDENCj4gPiAgICAgb3BlcmF0aW9ucyB0byBvbGQgY2xpZW50cy4NCj4gDQo+IElzIHRo
ZSBZQU5HIGNhcGFiaWxpdHkgcmVhbGx5IG5lZWRlZCwgaWYgdGhlIDQ3NDFiaXMgc3VwcG9ydCBp
cyBhbHJlYWR5DQo+IGluZGljYXRlZCB2aWEgdGhlIGNhcGFiaWxpdHkgVVJJPw0KDQpZZXMsIGIv
YyB0aGUgcmV2aXNpb24gYW5kIGFsbCB0aGUgZmVhdHVyZXMgYXJlIHNwZWNpZmllZCB0aGVyZS4N
Cg0KPiA+ICAgICAoc2VlDQo+ID4gICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl
L3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDU2MDIuaHRtbA0KPiA+ICAgICBmb3IgbW9yZSBkZXRh
aWxzKQ0KPiA+IA0KPiA+IDIuICBBIGNsaWVudCB0aGF0IHdhbnRzIHRoZSBzdHJpY3QgY2FwYWJp
bGl0eSBjaGFuZ2UgYmVoYXZpb3INCj4gPiAgICAgYWR2ZXJ0aXNlczoNCj4gPiANCj4gPiAgICAg
IDpiYXNlOjEuMT9zdHJpY3QtY2FwYWJpbGl0aWVzDQo+IA0KPiBBZ2FpbiwgYXJlbid0IGNhcGFi
aWxpdGllcyBzdWZmaWNpZW50IHRvIHBlcmZvcm0gdGhpcyB0YXNrPw0KDQpZZXMsIHRoaXMgY291
bGQgYmUgaW5kaWNhdGVkIGJ5IHRoZSBjbGllbnQgZWl0aGVyIGFzIGEgc2VwYXJhdGUNCmNhcGFi
aWxpdHkgb3IgYXMgYSBwYXJhbWV0ZXIgdG8gdGhlIGJhc2UgY2FwYWJpbGl0eS4gIEkgcHJlZmVy
IHRoZQ0KbGF0dGVyLg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KPiA+ICAgICAob3Igc29tZXRoaW5n
IGxpa2UgdGhhdCkNCj4gPiANCj4gPiAgICAgSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFkdmVydGlz
ZSB0aGF0LCB0aGUgc2VydmVyIHdpbGwgYWxsb3cNCj4gPiAgICAgY2FwYWJpbGl0aWVzIHRvIGR5
bmFtaWNhbGx5IGNoYW5nZSB3L28gZ2l2aW5nIGFueQ0KPiA+ICAgICAnY2FwYWJpbGl0aWVzLWNo
YW5nZWQnIGVycm9ycy4NCj4gPiANCj4gPiBUaGUgcmVtYWluaW5nIHByb2JsZW0gaXMgaG93IHRv
IGRlYWwgd2l0aCB0aGUgOnVybCBzY2hlbWUgcGFyYW1ldGVyDQo+ID4gYW5kIHRoZSA6d2l0aC1k
ZWZhdWx0cyBiYXNpYy1tb2RlIGFuZCBhbHNvLXN1cHBvcnRlZCBwYXJhbWV0ZXJzOg0KPiA+IChz
ZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9t
c2cwNTYwNy5odG1sKQ0KPiA+IA0KPiA+IDNhLiBDaGFuZ2UgWUFORyB0byBleHBsaWNpdHkgYWxs
b3cgZXh0cmEgcGFyYW1ldGVycyBpbiB0aGUgY2FwYWJpbGl0eQ0KPiA+ICAgICBzdHJpbmcuDQo+
ID4gDQo+ID4gb3INCj4gPiANCj4gPiAzYi4gVXNlIGEgbm9ybWFsIGNhcGFiaWxpdHkgdG8gcGFz
cyBleHRyYSBwYXJhbWV0ZXJzLiAgVGhpcyByZXF1aXJlcw0KPiA+ICAgICBubyBjaGFuZ2VzIHRv
IFlBTkcuDQo+ID4gDQo+ID4gSW4gYm90aCAzYSBhbmQgM2IgdGhlcmUgd291bGQgYmUgbm8gZm9y
bWFsIFlBTkcgc3RhdGVtZW50IHRvIGRlZmluZQ0KPiA+IHRoZXNlIGV4dHJhIHBhcmFtZXRlcnMu
DQo+ID4gDQo+ID4gQW5keSBwcmVmZXJzIDNiLCBhbmQgSSBwZXJzb25hbGx5IHRoaW5rIGJvdGgg
M2EgYW5kIDNiIHdvcmtzLg0KPiANCj4gSSBwcmVmZXIgM2IuDQo+IA0KPiBMYWRhDQo+IA0KPiA+
IA0KPiA+IEkgdGhpbmsgSnVlcmdlbiBvYmplY3RzIHRvIGJvdGggM2EgYW5kIDNiLCBiZWNhdXNl
IGhlIHdhbnRzIGEgZm9ybWFsDQo+ID4gd2F5IHRvIHNwZWNpZnkgZXh0cmEgcGFyYW1ldGVycyBp
biBZQU5HLiAgSnVlcmdlbiBpcyB0aGF0IGNvcnJlY3Q/DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4g
L21hcnRpbg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ICAgICANCj4gDQo+IA0KPiAtLSAN
Cj4gTGFkaXNsYXYgTGhvdGthLCBDRVNORVQNCj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo=

From lhotka@cesnet.cz  Mon Apr 12 06:47:47 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE013A6A48 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level: 
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwO3Vi4TCNI1 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 06:47:46 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 820FD3A67E3 for <netconf@ietf.org>; Mon, 12 Apr 2010 06:47:46 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 543522CDE05B; Mon, 12 Apr 2010 15:47:40 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100412.153832.48993389.mbj@tail-f.com>
References: <1270801567.6878.1.camel@missotis> <20100412.144053.17641150.mbj@tail-f.com> <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Mon, 12 Apr 2010 15:47:39 +0200
Message-ID: <1271080059.14883.54.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 13:47:47 -0000

Martin Bjorklund píše v Po 12. 04. 2010 v 15:38 +0200:
> > >     Then the normal YANG capability (with features= etc) is used by a
> > >     4741bis server to indicate support for 4741bis operations, and the
> > >     old capabilities are used to indicate support for the 4741
> > >     operations to old clients.
> > 
> > Is the YANG capability really needed, if the 4741bis support is already
> > indicated via the capability URI?
> 
> Yes, b/c the revision and all the features are specified there.

The revision can be specified in (or as a parameter to) the base
capability URI and optional features can use special capability elements
as in 3b below for with-defaults. I really think this is out of YANG's
scope and not needed anyway.

Lada


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From mbj@tail-f.com  Mon Apr 12 07:01:53 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E553A6A3C for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.336
X-Spam-Level: 
X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.710,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1astmQ6Y5MgE for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:01:53 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3E3D23A6A3A for <netconf@ietf.org>; Mon, 12 Apr 2010 07:01:52 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3982176C528; Mon, 12 Apr 2010 16:01:46 +0200 (CEST)
Date: Mon, 12 Apr 2010 16:01:45 +0200 (CEST)
Message-Id: <20100412.160145.118692208.mbj@tail-f.com>
To: lhotka@cesnet.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1271080059.14883.54.camel@missotis>
References: <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 14:01:53 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr
bHVuZCBww63FoWUgdiBQbyAxMi4gMDQuIDIwMTAgdiAxNTozOCArMDIwMDoNCj4gPiA+ID4gICAg
IFRoZW4gdGhlIG5vcm1hbCBZQU5HIGNhcGFiaWxpdHkgKHdpdGggZmVhdHVyZXM9IGV0YykgaXMg
dXNlZCBieSBhDQo+ID4gPiA+ICAgICA0NzQxYmlzIHNlcnZlciB0byBpbmRpY2F0ZSBzdXBwb3J0
IGZvciA0NzQxYmlzIG9wZXJhdGlvbnMsIGFuZCB0aGUNCj4gPiA+ID4gICAgIG9sZCBjYXBhYmls
aXRpZXMgYXJlIHVzZWQgdG8gaW5kaWNhdGUgc3VwcG9ydCBmb3IgdGhlIDQ3NDENCj4gPiA+ID4g
ICAgIG9wZXJhdGlvbnMgdG8gb2xkIGNsaWVudHMuDQo+ID4gPiANCj4gPiA+IElzIHRoZSBZQU5H
IGNhcGFiaWxpdHkgcmVhbGx5IG5lZWRlZCwgaWYgdGhlIDQ3NDFiaXMgc3VwcG9ydCBpcyBhbHJl
YWR5DQo+ID4gPiBpbmRpY2F0ZWQgdmlhIHRoZSBjYXBhYmlsaXR5IFVSST8NCj4gPiANCj4gPiBZ
ZXMsIGIvYyB0aGUgcmV2aXNpb24gYW5kIGFsbCB0aGUgZmVhdHVyZXMgYXJlIHNwZWNpZmllZCB0
aGVyZS4NCj4gDQo+IFRoZSByZXZpc2lvbiBjYW4gYmUgc3BlY2lmaWVkIGluIChvciBhcyBhIHBh
cmFtZXRlciB0bykgdGhlIGJhc2UNCj4gY2FwYWJpbGl0eSBVUkkgYW5kIG9wdGlvbmFsIGZlYXR1
cmVzIGNhbiB1c2Ugc3BlY2lhbCBjYXBhYmlsaXR5IGVsZW1lbnRzDQo+IGFzIGluIDNiIGJlbG93
IGZvciB3aXRoLWRlZmF1bHRzLiBJIHJlYWxseSB0aGluayB0aGlzIGlzIG91dCBvZiBZQU5HJ3MN
Cj4gc2NvcGUgYW5kIG5vdCBuZWVkZWQgYW55d2F5Lg0KDQpUaGUgWUFORyBtb2R1bGUgaWV0Zi1u
ZXRjb25mIGRlZmluZXMgdGhlIG9wZXJhdGlvbnMgZWRpdC1jb25maWcgZXRjLg0KVGhlIHN0YW5k
YXJkIFlBTkcgcnVsZXMgc2F5cyB0aGF0IGEgc2VydmVyIHRoYXQgaW1wbGVtZW50cyB0aGlzIG1v
ZHVsZQ0Kc2hvdWxkIGFkdmVydGlzZSB0aGUgY2FwYWJpbGl0eToNCg0KICAgdXJuOmlldGY6cGFy
YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wXA0KICAgICA/bW9kdWxlPWlldGYtbmV0Y29uZlwN
CiAgICAgJnJldmlzaW9uPTIwMTAtMDItMDRcDQogICAgICZmZWF0dXJlcz1zdGFydHVwLHVybCx2
YWxpZGF0ZQ0KDQpIb3cgaXMgdGhpcyBvdXQgb2YgWUFORydzIHNjb3BlPyAgV2Ugd291bGQgbmVl
ZCBzcGVjaWFsIHJ1bGVzIHRvIE5PVA0KYWR2ZXJ0aXNlIHRoaXMgY2FwYWJpbGl0eS4NCg0KDQov
bWFydGluDQoNCg==

From andyb@iwl.com  Mon Apr 12 07:06:38 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9250328C0DB for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.353
X-Spam-Level: 
X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCPdbvZlDHDa for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:06:37 -0700 (PDT)
Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 0F43928C0CF for <netconf@ietf.org>; Mon, 12 Apr 2010 07:06:37 -0700 (PDT)
Received: from relay17.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 6E9491B9619; Mon, 12 Apr 2010 10:06:31 -0400 (EDT)
Received: by relay17.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 13BE11B9640;  Mon, 12 Apr 2010 10:06:30 -0400 (EDT)
Message-ID: <4BC328B7.4030606@iwl.com>
Date: Mon, 12 Apr 2010 07:05:43 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@cesnet.cz>
References: <1270801567.6878.1.camel@missotis>	 <20100412.144053.17641150.mbj@tail-f.com>	 <1271078978.14883.47.camel@missotis>	 <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis>
In-Reply-To: <1271080059.14883.54.camel@missotis>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 14:06:38 -0000

Ladislav Lhotka wrote:
> Martin Bjorklund píše v Po 12. 04. 2010 v 15:38 +0200:
>>>>     Then the normal YANG capability (with features= etc) is used by a
>>>>     4741bis server to indicate support for 4741bis operations, and the
>>>>     old capabilities are used to indicate support for the 4741
>>>>     operations to old clients.
>>> Is the YANG capability really needed, if the 4741bis support is already
>>> indicated via the capability URI?
>> Yes, b/c the revision and all the features are specified there.
> 
> The revision can be specified in (or as a parameter to) the base
> capability URI and optional features can use special capability elements
> as in 3b below for with-defaults. I really think this is out of YANG's
> scope and not needed anyway.
> 

This is incorrect.
The ietf-netconf.yang contents are clearly within the scope of YANG
or the module would be empty.

I have implemented an automated system based on the YANG module
capability URI.  It is critical that the set of modules being
advertised is complete.  Since with-defaults imports ietf-netconf,
it needs to be in the set of advertised modules.

Even without with-defaults, ietf-netconf.yang is the module
for the XML namespace of the 4741bis operations.  It does not
hurt anything to advertise the YANG capability for this namespace,
since it will not be identified in the <hello>
any other way.


> Lada
> 
> 

Andy

From lhotka@cesnet.cz  Mon Apr 12 07:33:40 2010
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EB13A6A3A for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level: 
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl7JW94OB7wW for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:33:40 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F11763A6818 for <netconf@ietf.org>; Mon, 12 Apr 2010 07:33:39 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id B9B3D2CDE05C; Mon, 12 Apr 2010 16:33:33 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: andyb@iwl.com
In-Reply-To: <4BC328B7.4030606@iwl.com>
References: <1270801567.6878.1.camel@missotis> <20100412.144053.17641150.mbj@tail-f.com> <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis>  <4BC328B7.4030606@iwl.com>
Content-Type: text/plain; charset="UTF-8"
Organization: CESNET
Date: Mon, 12 Apr 2010 16:33:32 +0200
Message-ID: <1271082812.14883.61.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 14:33:40 -0000

Andy Bierman píše v Po 12. 04. 2010 v 07:05 -0700:
> Ladislav Lhotka wrote:
> > Martin Bjorklund píše v Po 12. 04. 2010 v 15:38 +0200:
> >>>>     Then the normal YANG capability (with features= etc) is used by a
> >>>>     4741bis server to indicate support for 4741bis operations, and the
> >>>>     old capabilities are used to indicate support for the 4741
> >>>>     operations to old clients.
> >>> Is the YANG capability really needed, if the 4741bis support is already
> >>> indicated via the capability URI?
> >> Yes, b/c the revision and all the features are specified there.
> > 
> > The revision can be specified in (or as a parameter to) the base
> > capability URI and optional features can use special capability elements
> > as in 3b below for with-defaults. I really think this is out of YANG's
> > scope and not needed anyway.
> > 
> 
> This is incorrect.
> The ietf-netconf.yang contents are clearly within the scope of YANG
> or the module would be empty.

YANG features were not designed for client-server negotiation - that's
why they don't have parameters.

> 
> I have implemented an automated system based on the YANG module
> capability URI.  It is critical that the set of modules being
> advertised is complete.  Since with-defaults imports ietf-netconf,
> it needs to be in the set of advertised modules.
> 
> Even without with-defaults, ietf-netconf.yang is the module
> for the XML namespace of the 4741bis operations.  It does not
> hurt anything to advertise the YANG capability for this namespace,
> since it will not be identified in the <hello>
> any other way.

>From what Martin wrote I understood that base:1.1 will be advertized as
a capability.

Lada

> 
> 
> > Lada
> > 
> > 
> 
> Andy


-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


From andyb@iwl.com  Mon Apr 12 07:43:41 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F4528C0E1 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.17
X-Spam-Level: 
X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA-Ylo8frrlF for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 07:43:40 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 362B13A67FC for <netconf@ietf.org>; Mon, 12 Apr 2010 07:43:40 -0700 (PDT)
Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BA0B330001;  Mon, 12 Apr 2010 10:43:34 -0400 (EDT)
Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 75E282FFF3;  Mon, 12 Apr 2010 10:43:34 -0400 (EDT)
Message-ID: <4BC33167.5000606@iwl.com>
Date: Mon, 12 Apr 2010 07:42:47 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@cesnet.cz>
References: <1270801567.6878.1.camel@missotis>	 <20100412.144053.17641150.mbj@tail-f.com>	 <1271078978.14883.47.camel@missotis>	 <20100412.153832.48993389.mbj@tail-f.com>	 <1271080059.14883.54.camel@missotis> <4BC328B7.4030606@iwl.com> <1271082812.14883.61.camel@missotis>
In-Reply-To: <1271082812.14883.61.camel@missotis>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 14:43:41 -0000

Ladislav Lhotka wrote:
> Andy Bierman píše v Po 12. 04. 2010 v 07:05 -0700:
>> Ladislav Lhotka wrote:
>>> Martin Bjorklund píše v Po 12. 04. 2010 v 15:38 +0200:
>>>>>>     Then the normal YANG capability (with features= etc) is used by a
>>>>>>     4741bis server to indicate support for 4741bis operations, and the
>>>>>>     old capabilities are used to indicate support for the 4741
>>>>>>     operations to old clients.
>>>>> Is the YANG capability really needed, if the 4741bis support is already
>>>>> indicated via the capability URI?
>>>> Yes, b/c the revision and all the features are specified there.
>>> The revision can be specified in (or as a parameter to) the base
>>> capability URI and optional features can use special capability elements
>>> as in 3b below for with-defaults. I really think this is out of YANG's
>>> scope and not needed anyway.
>>>
>> This is incorrect.
>> The ietf-netconf.yang contents are clearly within the scope of YANG
>> or the module would be empty.
> 
> YANG features were not designed for client-server negotiation - that's
> why they don't have parameters.

No -- they were designed to partition a YANG module into sections.

I don't see what :url or :with-defaults has to
do with advertising the YANG modules.


> 
>> I have implemented an automated system based on the YANG module
>> capability URI.  It is critical that the set of modules being
>> advertised is complete.  Since with-defaults imports ietf-netconf,
>> it needs to be in the set of advertised modules.
>>
>> Even without with-defaults, ietf-netconf.yang is the module
>> for the XML namespace of the 4741bis operations.  It does not
>> hurt anything to advertise the YANG capability for this namespace,
>> since it will not be identified in the <hello>
>> any other way.
> 
>>From what Martin wrote I understood that base:1.1 will be advertized as
> a capability.

There needs to be a YANG capability
mapping for the XML namespace of the operations.
This allows an implementation to handle <edit-config>
the same way it handles <acme:restart>.

I do not see why an implementation should be forced to special-case
all the standard protocol operations.


> 
> Lada
> 
>>
>>> Lada
>>>
>>>
>> Andy
> 
> 

Andy


From andyb@iwl.com  Mon Apr 12 08:48:50 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BC73A699E for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zufCMiU30x01 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 08:48:49 -0700 (PDT)
Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id 5C6013A68F3 for <netconf@ietf.org>; Mon, 12 Apr 2010 08:48:49 -0700 (PDT)
Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 97ECF16F20D8; Mon, 12 Apr 2010 11:48:43 -0400 (EDT)
Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7A816D3002B;  Mon, 12 Apr 2010 11:46:56 -0400 (EDT)
Message-ID: <4BC34041.60105@iwl.com>
Date: Mon, 12 Apr 2010 08:46:09 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <1271078978.14883.47.camel@missotis>	<20100412.153832.48993389.mbj@tail-f.com>	<1271080059.14883.54.camel@missotis> <20100412.160145.118692208.mbj@tail-f.com>
In-Reply-To: <20100412.160145.118692208.mbj@tail-f.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 15:48:50 -0000

Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
>> Martin Bjorklund píše v Po 12. 04. 2010 v 15:38 +0200:
>>>>>     Then the normal YANG capability (with features= etc) is used by a
>>>>>     4741bis server to indicate support for 4741bis operations, and the
>>>>>     old capabilities are used to indicate support for the 4741
>>>>>     operations to old clients.
>>>> Is the YANG capability really needed, if the 4741bis support is already
>>>> indicated via the capability URI?
>>> Yes, b/c the revision and all the features are specified there.
>> The revision can be specified in (or as a parameter to) the base
>> capability URI and optional features can use special capability elements
>> as in 3b below for with-defaults. I really think this is out of YANG's
>> scope and not needed anyway.
> 
> The YANG module ietf-netconf defines the operations edit-config etc.
> The standard YANG rules says that a server that implements this module
> should advertise the capability:
> 
>    urn:ietf:params:xml:ns:netconf:base:1.0\
>      ?module=ietf-netconf\
>      &revision=2010-02-04\
>      &features=startup,url,validate
> 
> How is this out of YANG's scope?  We would need special rules to NOT
> advertise this capability.
> 

This point about special cases is important to me.
I want to avoid them in the standard and in everybody's code.

In order to implement a data-driven system in a modular fashion,
it is important to keep the algorithms rigid and self-contained.
It is desirable for a software module to process the entire
YANG module capability, without any coupling to arbitrary external
modules.

The current YANG spec works this way, and does a nice job of allowing
an on-the-fly compile of the advertised module (e.g. patch in the
deviations and disable the unannounced features).

For protocol capabilities like :url and :with-defaults, special code
is needed, and it is better if this is not coupled to other URI processing.

>From a standards perspective, it is cleaner to keep the YANG module
contents and the special protocol capabilities separate.
The server provides a translation from 1.0 capabilities
to 1.1 features so a client can use either one, and transition
to YANG features over time.


----------------------------------------------------------------------------------
*** WITH-DEFAULTS TEXT CHANGE ***

I think the with-defaults capability should be split into 2
modules and the XML namespace for the <with-defaults> leaf should
use the YANG format base-part, not the NETCONF capability base part:

OLD:


*** 1 combined capability:

   urn:ietf:params:netconf:capability:with-defaults?module=ietf-netconf-
   with-defaults&revision=2010-03-25&basic-mode=report-all&
   also-supported=trim,explicit

*** module namespace uses NETCONF protocol capability base part.

 module ietf-netconf-with-defaults {

    namespace "urn:ietf:params:netconf:capability:with-defaults";



NEW:


*** protocol capability for with-defaults parameters

   urn:ietf:params:netconf:capability:with-defaults?basic-mode=report-all&
   also-supported=trim,explicit

*** module capability using YANG base-part instead or protocol base-part

   urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&
   revision=2010-03-25

*** module namespace follows usage guidelines and our naming conventions

 module ietf-netconf-with-defaults {

    namespace "urn:ietf:params:xml:ns:yang:with-defaults";


Unless there are any strong objections, I am going to make these changes to
the next revision of the with-defaults draft.


> 
> /martin
> 


Andy

From andyb@iwl.com  Mon Apr 12 08:56:33 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8003A67C1 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 08:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level: 
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwI3cS7aLu2c for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 08:56:33 -0700 (PDT)
Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id E2C423A66B4 for <netconf@ietf.org>; Mon, 12 Apr 2010 08:56:14 -0700 (PDT)
Received: from relay18.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8730C1B4004; Mon, 12 Apr 2010 11:56:09 -0400 (EDT)
Received: by relay18.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D28A01B409B;  Mon, 12 Apr 2010 11:55:59 -0400 (EDT)
Message-ID: <4BC34260.2050606@iwl.com>
Date: Mon, 12 Apr 2010 08:55:12 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
References: <1271078978.14883.47.camel@missotis>	<20100412.153832.48993389.mbj@tail-f.com>	<1271080059.14883.54.camel@missotis>	<20100412.160145.118692208.mbj@tail-f.com> <4BC34041.60105@iwl.com>
In-Reply-To: <4BC34041.60105@iwl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2010 15:56:33 -0000

...
> 
>  module ietf-netconf-with-defaults {
> 
>     namespace "urn:ietf:params:xml:ns:yang:with-defaults";
> 

oops -- the full module name needs to be in the new namespace:

  namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults";


> 
> Unless there are any strong objections, I am going to make these changes to
> the next revision of the with-defaults draft.
> 
> 
>> /martin
>>
> 
> 
> Andy


Andy

From mbj@tail-f.com  Mon Apr 12 23:25:24 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8483A67D7 for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 23:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.146
X-Spam-Level: 
X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=-1.008,  BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_26=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaLd68-r87iQ for <netconf@core3.amsl.com>; Mon, 12 Apr 2010 23:25:22 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B832F3A6774 for <netconf@ietf.org>; Mon, 12 Apr 2010 23:25:21 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B0F7616004; Tue, 13 Apr 2010 08:25:15 +0200 (CEST)
Date: Tue, 13 Apr 2010 08:25:14 +0200 (CEST)
Message-Id: <20100413.082514.128186248.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BBF931E.4060603@iwl.com>
References: <4BBF931E.4060603@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] making more 4741bis waves
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 06:25:25 -0000

Andy Bierman <andyb@iwl.com> wrote:
> Hi,
> 
> I have some new issues for 4741bis:
> 
> 1) test-only enum
> 
>    I really dislike using a protocol capability for 1 enum value of
>    1 parameter of 1 RPC operation.  Is there a way to avoid this?

Yes, if 4741bis defines base:1.1 we don't need this capability.

>    We never actually solved the problem of what <validate> means,
>    or what 'test-then-set', 'test-only' means, so it's not like the :validate
>    capability is something special. (See 2 below).
> 
>    We should make it more clear what a server does for validation:
>         #1)  test-then-set == test-only == validate, except for a conceptual
>              config made from the config source and the target config.
>              A validate is done on a conceptually complete database.

I'm not sure I understand the "except..." part above, but I agree that
"test-" should be the same as validate.  So if you do:

  edit-config candidate, test-option=set
  validate candidate

you would detect the same errors as

  edit-config candidate test-option=test-then-set

(the db contents will be different, but that's not the point)

>              Only the test part of test-then-set is considered here.
>         #2) The server MUST detect all schema errors
>         #3) The server SHOULD detect all platform-specific constraints
>             that are specified in description statements instead of
>             machine-readable statements.

s/platform-specific//

But this depends on the text in the description statement.  If the
textual constraint says that a server MUST detect a certain constraint
in a valid config, then this is a MUST, not SHOULD.

>         #4) The server MAY detect resource allocation errors.
>         #5) The server MAY detect network-wide constraint violations

I do not undertand what #5 means.  Typically, network-wide constraints
cannot be checked on a single device - that's what makes then network
wide!


> 2) <test-option> present is an error
> 
>    Balazs complained before that a client MUST NOT set the <test-option>
>    leaf if :validate is not advertised, even though there are
>    defaults defined for the server for both modes.  This is a CLR.
>    We should just make the <test-option> optional in base:1.1
>    and the server MUST use the appropriate default.

I disagree.  The behavior you describe is what you get from this leaf:

      leaf test-option {
        if-feature validate;
        type enumeration {
          enum test-then-set;
          enum set;
          enum test-only;
        }
        default "test-then-set";
      }

The leaf itself is conditional based on the feature.  If the feature
is enabled, there is a default value.

Is this leaf construct in some way bad design?


> 3) <test-option> default
> 
>    It is very resource-intensive to default the test-option to test-then-set
>    on the candidate config.  This also breaks incremental changes to candidate,
>    since the test-then-set option means "make sure the entire
>    database is valid". 
> 
>    IMO, this should be fixed.  It would be simpler if there was just
>    an plain optional default with a default:
> 
>    OLD:
> 
>         leaf test-option {
>            if-feature validate;
>            type enumeration {
>              enum test-then-set;
>              enum set;
>              enum test-only {
>                description
>                  "This value can only be used if the 'validate-1.1'
>                   feature is supported.";
>              }
>            }
>          }
> 
>    NEW:
> 
>         leaf test-option {
>            type enumeration {
>              enum test-then-set {
>                description
>                  "This value can only be used if the 'validate'
>                   feature is supported.";
>              enum set;
>              enum test-only {
>                description
>                  "This value can only be used if the 'base-1.1'
>                   capability is supported.
> 
>                   If the 'validate' feature is also supported,
>                   then the server will perform a complete
>                   validation procedure.
> 
>                   If the 'validate' feature is not supported,
>                   then the server will make a best-effort attempt
>                   to detect any errors in the <edit-config> request.";
>              }
>            }
>            default set;
>         }
> 
> 4) new 'destroy' operation

Yes please!!

>    The nc:delete operation is too picky.
>    The server MUST return a 'data-missing' error-tag if the data
>    instances do not exist as predicted by the client.
> 
>    A new operation called 'destroy' would be like an 'rm -f' command.
>    The data is deleted if it exists.
>    The requested data MUST identify data nodes that the server supports
>    but if the requested instances do not exist, then <ok/>  is still returned.


/martin

From andyb@iwl.com  Tue Apr 13 08:53:31 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CEB3A6937 for <netconf@core3.amsl.com>; Tue, 13 Apr 2010 08:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.031
X-Spam-Level: 
X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtmA-oaE2qnA for <netconf@core3.amsl.com>; Tue, 13 Apr 2010 08:53:29 -0700 (PDT)
Received: from smtp244.iad.emailsrvr.com (smtp244.iad.emailsrvr.com [207.97.245.244]) by core3.amsl.com (Postfix) with ESMTP id 2E4FF3A6895 for <netconf@ietf.org>; Tue, 13 Apr 2010 08:53:29 -0700 (PDT)
Received: from relay14.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 1B7E523A828; Tue, 13 Apr 2010 11:53:23 -0400 (EDT)
Received: by relay14.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B15E423A80F;  Tue, 13 Apr 2010 11:53:22 -0400 (EDT)
Message-ID: <4BC4933A.3070308@iwl.com>
Date: Tue, 13 Apr 2010 08:52:26 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BBF931E.4060603@iwl.com> <20100413.082514.128186248.mbj@tail-f.com>
In-Reply-To: <20100413.082514.128186248.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] making more 4741bis waves
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 15:53:31 -0000

Martin Bjorklund wrote:
> Andy Bierman <andyb@iwl.com> wrote:
>> Hi,
>>
>> I have some new issues for 4741bis:
>>
>> 1) test-only enum
>>
>>    I really dislike using a protocol capability for 1 enum value of
>>    1 parameter of 1 RPC operation.  Is there a way to avoid this?
> 
> Yes, if 4741bis defines base:1.1 we don't need this capability.
> 
>>    We never actually solved the problem of what <validate> means,
>>    or what 'test-then-set', 'test-only' means, so it's not like the :validate
>>    capability is something special. (See 2 below).
>>
>>    We should make it more clear what a server does for validation:
>>         #1)  test-then-set == test-only == validate, except for a conceptual
>>              config made from the config source and the target config.
>>              A validate is done on a conceptually complete database.
> 
> I'm not sure I understand the "except..." part above, but I agree that
> "test-" should be the same as validate.  So if you do:
> 

validate applies to an entire config provided by the client

test-* applies to the conceptual config made from
combining the client config fragment with the real config
to construct a complete config to validate


>   edit-config candidate, test-option=set
>   validate candidate
> 
> you would detect the same errors as
> 
>   edit-config candidate test-option=test-then-set
> 
> (the db contents will be different, but that's not the point)
> 
>>              Only the test part of test-then-set is considered here.
>>         #2) The server MUST detect all schema errors
>>         #3) The server SHOULD detect all platform-specific constraints
>>             that are specified in description statements instead of
>>             machine-readable statements.
> 
> s/platform-specific//
> 

OK

> But this depends on the text in the description statement.  If the
> textual constraint says that a server MUST detect a certain constraint
> in a valid config, then this is a MUST, not SHOULD.
> 
>>         #4) The server MAY detect resource allocation errors.
>>         #5) The server MAY detect network-wide constraint violations
> 
> I do not undertand what #5 means.  Typically, network-wide constraints
> cannot be checked on a single device - that's what makes then network
> wide!
> 

A constraint doe not have to be local.
What if the device can use the network
to check an identifier that is
supposed to be unique within the entire administrative domain?


> 
>> 2) <test-option> present is an error
>>
>>    Balazs complained before that a client MUST NOT set the <test-option>
>>    leaf if :validate is not advertised, even though there are
>>    defaults defined for the server for both modes.  This is a CLR.
>>    We should just make the <test-option> optional in base:1.1
>>    and the server MUST use the appropriate default.
> 
> I disagree.  The behavior you describe is what you get from this leaf:
> 
>       leaf test-option {
>         if-feature validate;
>         type enumeration {
>           enum test-then-set;
>           enum set;
>           enum test-only;
>         }
>         default "test-then-set";
>       }


This is what we have now.

The 'set' option is a NO-OP for this parameter.

It is a lot simpler to implement test-only than validate.

It seems better if test-only were available on all
servers, even if it does not check all the errors
that :validate is supposed to check.

But this is not that important.  Server developers just
need to do more work and support :validate.


> 
> The leaf itself is conditional based on the feature.  If the feature
> is enabled, there is a default value.
> 
> Is this leaf construct in some way bad design?

Yes.

The 'set' enum is a NO-OP.
A server that does not support :validate
supports the NO-OP mode already.

I would rather get back an invalid-value for setting the leaf
to 'test-only', than get an error that the leaf does not exist
at all.

But this is not important either I guess.
The client will get an error either way.

This switch is also counter-intuitive because the test-then-set
enum is pointless (since it is the default).  The only thing for
a client to do is disable this test-option by being forced to
provide the 'set' value.

IMO, the client should opt-in for this testing because:
  - the candidate is supposed to allow incremental edits
  - this parameter has no affect on the running config (test-then-set
    is always done on running -- 'set' means nothing here)

> 
> 
>> 3) <test-option> default
>>
>>    It is very resource-intensive to default the test-option to test-then-set
>>    on the candidate config.  This also breaks incremental changes to candidate,
>>    since the test-then-set option means "make sure the entire
>>    database is valid". 
>>
>>    IMO, this should be fixed.  It would be simpler if there was just
>>    an plain optional default with a default:
>>
>>    OLD:
>>
>>         leaf test-option {
>>            if-feature validate;
>>            type enumeration {
>>              enum test-then-set;
>>              enum set;
>>              enum test-only {
>>                description
>>                  "This value can only be used if the 'validate-1.1'
>>                   feature is supported.";
>>              }
>>            }
>>          }
>>
>>    NEW:
>>
>>         leaf test-option {
>>            type enumeration {
>>              enum test-then-set {
>>                description
>>                  "This value can only be used if the 'validate'
>>                   feature is supported.";
>>              enum set;
>>              enum test-only {
>>                description
>>                  "This value can only be used if the 'base-1.1'
>>                   capability is supported.
>>
>>                   If the 'validate' feature is also supported,
>>                   then the server will perform a complete
>>                   validation procedure.
>>
>>                   If the 'validate' feature is not supported,
>>                   then the server will make a best-effort attempt
>>                   to detect any errors in the <edit-config> request.";
>>              }
>>            }
>>            default set;
>>         }
>>
>> 4) new 'destroy' operation
> 
> Yes please!!
> 
>>    The nc:delete operation is too picky.
>>    The server MUST return a 'data-missing' error-tag if the data
>>    instances do not exist as predicted by the client.
>>
>>    A new operation called 'destroy' would be like an 'rm -f' command.
>>    The data is deleted if it exists.
>>    The requested data MUST identify data nodes that the server supports
>>    but if the requested instances do not exist, then <ok/>  is still returned.
> 
> 
> /martin
> 


Andy


From bertietf@bwijnen.net  Thu Apr 15 01:05:14 2010
Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6596E3A6856 for <netconf@core3.amsl.com>; Thu, 15 Apr 2010 01:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.93
X-Spam-Level: 
X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.669,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcDBG3-fJNYr for <netconf@core3.amsl.com>; Thu, 15 Apr 2010 01:05:11 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 9BA853A67D7 for <netconf@ietf.org>; Thu, 15 Apr 2010 01:05:03 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <bertietf@bwijnen.net>) id 1O2K4A-00056A-9d for netconf@ietf.org; Thu, 15 Apr 2010 10:04:55 +0200
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-95.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from <bertietf@bwijnen.net>) id 1O2K4A-0007ed-6U for netconf@ietf.org; Thu, 15 Apr 2010 10:04:50 +0200
Message-ID: <4BC6C8A2.1000307@bwijnen.net>
Date: Thu, 15 Apr 2010 10:04:50 +0200
From: "Bert (IETF) Wijnen" <bertietf@bwijnen.net>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41d07a8d7bca04dba211c41b70b77a23b
X-RIPE-Spam-Level: ----
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41d07a8d7bca04dba211c41b70b77a23b
Subject: [Netconf] Netconf Implementations - as reported on our netconf twiki page
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 08:05:14 -0000

Dear WG participants, on our NETCONF TWIKI, we have various
pointers to additional NetConf and YANG related materials.
The page is at:

    http://trac.tools.ietf.org/wg/netconf/trac/wiki

Over the years we (as current and past WG chairs) have collected
information. However, you as the community need to help us to keep
this up to date.

Yesterday we got a report that various links were broken.
We have fixed those that we could quickly track down.

There are a few that we cannot (yet) track down.
If you have pointers them, pls do let us know.
If we cannot find the pointers in the next few weeks,
we plan to disable the links... maybe even better to
remove the item completely.

Also it seems some companies have merged or been bought?
So we appologize if the data is not 100% correct. It is
only the owners of the pages that can keep us informed and
up to date.

Bert and Mehmet

Below is a list of changes made and still open problems:

> Regarding the Wiki:
>
> http://trac.tools.ietf.org/wg/netconf/trac/wiki
>
> I think it’s a great idea to have a list of tool vendors. Some changes 
> are recommended for this section of the Wiki:
>
> embeddedMIND™ <http://embeddedmind.com/mindagentnetconf> from 
> Silicon&Software Systems (S3) now has an extensible Netconf agent with 
> integrated configuration store and CLI, SNMP and Web interfaces.
>
> -> Looks like S3 was bought by GoAhead Software.
>
Fixed the ptr.
Also added ??Now GoAhead?? Hope the owners can tell us more.
>
> XML Based Device Management 
> <http://www.wipro.com/webpages/prodesign/reusableframeworks/ip/xml.htm> 
> by Wipro, including an agent written in C and a manager in Java
>
> -> This URL doesn’t work anymore.
>
Can't find info for it anymore

> Applied Informatics' C++-based NetConf implementation 
> <http://www.appinf.com/poco/wiki/tiki-index.php?page=NetConf> based on 
> the POCO framework ( Howto 
> <http://www.appinf.com/poco/wiki/tiki-index.php?page=NetConf>).
>
> -> This URL doesn’t work anymore.
>
Same

> XMS (eXtensible Management System) 
> <http://www.6wind.com/Network.html>, written in C, by 6WIND
>
> -> This URL doesn’t work anymore.
>
Same

> Another implementation written in C by 
> http://www.postech.ac.kr/Postech in Korea
>
> -> This URL doesn’t work anymore.
>
Same... but I may be able to track it down with a few emails in the next
few days
>
> Also, the Ncclient module is now located at 
> http://oss.schmizz.net/ncclient/.
>
> · NANOG28 (June 2003): Panel on XML Router Configs - Progress and 
> Predictions <http://www.nanog.org/mtg-0306/xml.html>
>
> · NANOG28 (June 2003) BOF on XML-based Network Management Tools 
> <http://www.nanog.org/mtg-0306/enns.html>
>
> -> These links have moved as well.
>

fixed




From j.schoenwaelder@jacobs-university.de  Fri Apr 16 08:26:29 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A2528C21B for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 08:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.581
X-Spam-Level: 
X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.668,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6BSQ0nWgbGp for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 08:26:28 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E1C83A67AF for <netconf@ietf.org>; Fri, 16 Apr 2010 08:22:36 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 391D6C0006; Fri, 16 Apr 2010 17:22:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8EaxhzrYTYZU; Fri, 16 Apr 2010 17:22:28 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 040B0C000F; Fri, 16 Apr 2010 17:22:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 745A2118F221; Fri, 16 Apr 2010 17:22:22 +0200 (CEST)
Date: Fri, 16 Apr 2010 17:22:21 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100416152221.GA7050@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis> <20100412.160145.118692208.mbj@tail-f.com> <4BC34041.60105@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BC34041.60105@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 15:26:30 -0000

On Mon, Apr 12, 2010 at 05:46:09PM +0200, Andy Bierman wrote:
 
> For protocol capabilities like :url and :with-defaults, special code
> is needed, and it is better if this is not coupled to other URI processing.

But :url is specific to the url feature of the ietf-netconf.yang
module. And the same goes for :with-defaults.
 
> From a standards perspective, it is cleaner to keep the YANG module
> contents and the special protocol capabilities separate.
> The server provides a translation from 1.0 capabilities
> to 1.1 features so a client can use either one, and transition
> to YANG features over time.

I consider the 4741 protocol operations just another data model
defined in YANG in 4741 and hence :url and :with-defaults are not
"special protocol capabilities" to keep separate from the data
model. This is where our views of the world differ.

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

From andyb@iwl.com  Fri Apr 16 09:07:35 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7141828C1B9 for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 09:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level: 
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enbc37mx3gyB for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 09:07:34 -0700 (PDT)
Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 82C9528C1A0 for <netconf@ietf.org>; Fri, 16 Apr 2010 09:07:32 -0700 (PDT)
Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BCF4517FEC7; Fri, 16 Apr 2010 12:07:24 -0400 (EDT)
Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8A1C117FBF1;  Fri, 16 Apr 2010 12:07:24 -0400 (EDT)
Message-ID: <4BC88B52.4070207@iwl.com>
Date: Fri, 16 Apr 2010 09:07:46 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis> <20100412.160145.118692208.mbj@tail-f.com> <4BC34041.60105@iwl.com> <20100416152221.GA7050@elstar.local>
In-Reply-To: <20100416152221.GA7050@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 16:07:35 -0000

Juergen Schoenwaelder wrote:
> On Mon, Apr 12, 2010 at 05:46:09PM +0200, Andy Bierman wrote:
>  
>   
>> For protocol capabilities like :url and :with-defaults, special code
>> is needed, and it is better if this is not coupled to other URI processing.
>>     
>
> But :url is specific to the url feature of the ietf-netconf.yang
> module. And the same goes for :with-defaults.
>   

There is no with-defaults YANG feature.
The url YANG feature is new and poorly defined.
It's purpose is just to enable the <url> parameter.
The :url capability is still needed to find out what schemes
are supported by the server.

>  
>   
>> From a standards perspective, it is cleaner to keep the YANG module
>> contents and the special protocol capabilities separate.
>> The server provides a translation from 1.0 capabilities
>> to 1.1 features so a client can use either one, and transition
>> to YANG features over time.
>>     
>
> I consider the 4741 protocol operations just another data model
> defined in YANG in 4741 and hence :url and :with-defaults are not
> "special protocol capabilities" to keep separate from the data
> model. This is where our views of the world differ.
>
>   

The NETMOD WG decided not to support NETCONF capabilities
in YANG.  The YANG draft is done and sent to the IESG.
Sorry you don't agree with that decision, but it has already
been made.  The YANG spec does not support the addition
of arbitrary parameters to the module capability URI.


> /js
>
>   
Andy


From j.schoenwaelder@jacobs-university.de  Fri Apr 16 09:37:22 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CB23A6872 for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 09:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level: 
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.643,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtsH+N8nfsYq for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 09:37:21 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 08ED63A6935 for <netconf@ietf.org>; Fri, 16 Apr 2010 09:37:18 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0879C0014; Fri, 16 Apr 2010 18:37:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LzF7Ng2Ppqxc; Fri, 16 Apr 2010 18:37:09 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56540C0006; Fri, 16 Apr 2010 18:37:09 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DAEF9118F6EB; Fri, 16 Apr 2010 18:37:04 +0200 (CEST)
Date: Fri, 16 Apr 2010 18:37:04 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andyb@iwl.com>
Message-ID: <20100416163702.GA7630@elstar.local>
Mail-Followup-To: Andy Bierman <andyb@iwl.com>, Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis> <20100412.160145.118692208.mbj@tail-f.com> <4BC34041.60105@iwl.com> <20100416152221.GA7050@elstar.local> <4BC88B52.4070207@iwl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BC88B52.4070207@iwl.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 16:37:22 -0000

On Fri, Apr 16, 2010 at 06:07:46PM +0200, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > On Mon, Apr 12, 2010 at 05:46:09PM +0200, Andy Bierman wrote:
> >  
> >   
> >> For protocol capabilities like :url and :with-defaults, special code
> >> is needed, and it is better if this is not coupled to other URI processing.
> >>     
> >
> > But :url is specific to the url feature of the ietf-netconf.yang
> > module. And the same goes for :with-defaults.
> >   
> 
> There is no with-defaults YANG feature.
> The url YANG feature is new and poorly defined.
> It's purpose is just to enable the <url> parameter.
> The :url capability is still needed to find out what schemes
> are supported by the server.

Andy, I think I understand how it works. I think the reason we have
the capability is because we can't pass the schemas as a parameter of
the feature. (And there is backwards compatibility mess here.)

> >> From a standards perspective, it is cleaner to keep the YANG module
> >> contents and the special protocol capabilities separate.
> >> The server provides a translation from 1.0 capabilities
> >> to 1.1 features so a client can use either one, and transition
> >> to YANG features over time.
> >>     
> >
> > I consider the 4741 protocol operations just another data model
> > defined in YANG in 4741 and hence :url and :with-defaults are not
> > "special protocol capabilities" to keep separate from the data
> > model. This is where our views of the world differ.
> 
> The NETMOD WG decided not to support NETCONF capabilities
> in YANG.  The YANG draft is done and sent to the IESG.
> Sorry you don't agree with that decision, but it has already
> been made.  The YANG spec does not support the addition
> of arbitrary parameters to the module capability URI.

We likely regret this timing later on. Its likely this is not the
last time we run into this.

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

From andyb@iwl.com  Fri Apr 16 12:15:03 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED7E28C186 for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 12:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.324
X-Spam-Level: 
X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=1.275,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f94a88TVCfR5 for <netconf@core3.amsl.com>; Fri, 16 Apr 2010 12:15:01 -0700 (PDT)
Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 41CB83A6AA7 for <netconf@ietf.org>; Fri, 16 Apr 2010 12:14:28 -0700 (PDT)
Received: from relay7.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D078B1DD18C;  Fri, 16 Apr 2010 15:14:20 -0400 (EDT)
Received: by relay7.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9B4341DE414;  Fri, 16 Apr 2010 15:14:19 -0400 (EDT)
Message-ID: <4BC8B71C.7000109@iwl.com>
Date: Fri, 16 Apr 2010 12:14:36 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <1271078978.14883.47.camel@missotis> <20100412.153832.48993389.mbj@tail-f.com> <1271080059.14883.54.camel@missotis> <20100412.160145.118692208.mbj@tail-f.com> <4BC34041.60105@iwl.com> <20100416152221.GA7050@elstar.local> <4BC88B52.4070207@iwl.com> <20100416163702.GA7630@elstar.local>
In-Reply-To: <20100416163702.GA7630@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] base:1.1 capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 19:15:03 -0000

Juergen Schoenwaelder wrote:
> On Fri, Apr 16, 2010 at 06:07:46PM +0200, Andy Bierman wrote:
>   
>> Juergen Schoenwaelder wrote:
>>     
>>> On Mon, Apr 12, 2010 at 05:46:09PM +0200, Andy Bierman wrote:
>>>  
>>>   
>>>       
>>>> For protocol capabilities like :url and :with-defaults, special code
>>>> is needed, and it is better if this is not coupled to other URI processing.
>>>>     
>>>>         
>>> But :url is specific to the url feature of the ietf-netconf.yang
>>> module. And the same goes for :with-defaults.
>>>   
>>>       
>> There is no with-defaults YANG feature.
>> The url YANG feature is new and poorly defined.
>> It's purpose is just to enable the <url> parameter.
>> The :url capability is still needed to find out what schemes
>> are supported by the server.
>>     
>
> Andy, I think I understand how it works. I think the reason we have
> the capability is because we can't pass the schemas as a parameter of
> the feature. (And there is backwards compatibility mess here.)
>
>   

It is more a conceptual mess than a real problem.
In reality, it is just different letters to parse in a URI string.
There is no impact on the protocol here.

>>>> From a standards perspective, it is cleaner to keep the YANG module
>>>> contents and the special protocol capabilities separate.
>>>> The server provides a translation from 1.0 capabilities
>>>> to 1.1 features so a client can use either one, and transition
>>>> to YANG features over time.
>>>>     
>>>>         
>>> I consider the 4741 protocol operations just another data model
>>> defined in YANG in 4741 and hence :url and :with-defaults are not
>>> "special protocol capabilities" to keep separate from the data
>>> model. This is where our views of the world differ.
>>>       
>> The NETMOD WG decided not to support NETCONF capabilities
>> in YANG.  The YANG draft is done and sent to the IESG.
>> Sorry you don't agree with that decision, but it has already
>> been made.  The YANG spec does not support the addition
>> of arbitrary parameters to the module capability URI.
>>     
>
> We likely regret this timing later on. Its likely this is not the
> last time we run into this.
>   

We already fell down that slippery slope.
There is no real criteria for what monitoring information
should be sent in the <hello> vs. polled by the client.
It is not clear that anybody really wants (or ever asked for)
parameters in YANG features.

We have some legacy cruft that does not fit the design,
but going forward, if we use YANG for all the operations,
data nodes, and notifications, then we will be OK.

Each new protocol capability has to be evaluated on
a case-by-case basis.  There may be a need for URI
parameters in the future.  We should not rule it out
for session properties which the client should know about
from the very start of the session.

> /js
>
>   
Andy


From root@core3.amsl.com  Mon Apr 19 05:45:04 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id B2FDB3A69D6; Mon, 19 Apr 2010 05:45:04 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100419124504.B2FDB3A69D6@core3.amsl.com>
Date: Mon, 19 Apr 2010 05:45:04 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 12:45:04 -0000

--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           : With-defaults capability for NETCONF
	Author(s)       : A. Bierman, B. Lengyel
	Filename        : draft-ietf-netconf-with-defaults-07.txt
	Pages           : 21
	Date            : 2010-04-19

The NETCONF protocol defines ways to read configuration data from a
NETCONF server.  Part of this data is not set by the NETCONF client,
but rather a default value is used.  In many situations the NETCONF
client has a priori knowledge about default data, so the NETCONF
server does not need to send it to the client.  In other situations
the NETCONF client will need this data as part of the NETCONF <rpc-
reply> messages.  This document defines a capability-based extension
to the NETCONF protocol that allows the NETCONF client to control
whether default values are part of NETCONF <rpc-reply> messages or
<copy-config> output to the target URL.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-netconf-with-defaults-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-19054301.I-D@ietf.org>


--NextPart--

From mehmet.ersue@nsn.com  Tue Apr 20 03:11:49 2010
Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051333A68DF for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 03:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.748
X-Spam-Level: 
X-Spam-Status: No, score=0.748 tagged_above=-999 required=5 tests=[AWL=-2.853,  BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTOlkZSkFCGM for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 03:11:44 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1B88728C0DC for <netconf@ietf.org>; Tue, 20 Apr 2010 03:02:59 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3KA2n8i021757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <netconf@ietf.org>; Tue, 20 Apr 2010 12:02:49 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3KA2mTk030047 for <netconf@ietf.org>; Tue, 20 Apr 2010 12:02:48 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 20 Apr 2010 12:02:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAE070.A148EDF7"
Date: Tue, 20 Apr 2010 12:02:47 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6473A981@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft IETF 77 NETCONF Session Minutes
Thread-Index: AcrgcKDgq8Afq5/AQWWd+khj7jagzw==
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "NETCONF WG" <netconf@ietf.org>
X-OriginalArrivalTime: 20 Apr 2010 10:02:49.0216 (UTC) FILETIME=[A1FD2000:01CAE070]
Subject: [Netconf] Draft IETF 77 NETCONF Session Minutes
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 10:11:50 -0000

This is a multi-part message in MIME format.

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


Dear NETCONF WG,

please comment on the draft IETF 77 NETCONF session=20
minutes by April 27, 2010. Thank you.

 <<100420_Merged_77_NETCONF_Minutes_.txt>>=20

Mehmet



------_=_NextPart_001_01CAE070.A148EDF7
Content-Type: text/plain;
	name="100420_Merged_77_NETCONF_Minutes_.txt"
Content-Transfer-Encoding: base64
Content-Description: 100420_Merged_77_NETCONF_Minutes_.txt
Content-Disposition: attachment;
	filename="100420_Merged_77_NETCONF_Minutes_.txt"

DQpNaW51dGVzIG9mIHRoZSBORVRDT05GIFdHIHNlc3Npb24sIDIyIE1hcmNoIDIwMTANCj09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpNaW51dGVzIGJhc2VkIG9uIG5v
dGVzIHRha2VuIGJ5IExhZGEgTGhvdGthIGFuZCBMYXJyeSBCaWdncyAodGhhbmtzKQ0KDQpUaGUg
c2Vzc2lvbiBzdGFydGVkIGF0IDk6MDMsIGJsdWUgc2hlZXRzIHdlcmUgY2lyY3VsYXRlZC4NCg0K
Tm90ZSBXZWxsLCBuZWVkIHRvIGFjY2VwdCBydWxlcyBldGMgSVAgaXNzdWVzLCBwYXRlbnQgb3Ig
cmVsYXRlZCBpc3N1ZXMsIHNob3VsZCBkaXNjbG9zZSBhbnl0aGluZyBwZXJ0aW5lbnQNCg0KDQpB
Z2VuZGEgYmFzaGluZyAtIG5vIG9iamVjdGlvbnMvYWRkaXRpb25zLg0KDQpXRyBTdGF0dXMgKE1l
aG1ldCBFcnN1ZSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KNDc0MWJpcyBmaXJzdCB1cA0K
NDc0MmJpcyBuZXh0DQpub24gY2hhcnRlcmVkIGl0ZW1zDQpyb2J1c3QgY29uZmlnDQphY2Nlc3Mt
Y29udHJvbA0KV2FsayB1cCBpdGVtIC0gd2FzbnQgYWJsZSB0byBnZXQgdGhlIHRvcGljDQpTdGF0
dXMgc2luY2UgSGlyb3NoaW1hDQoNCi0gUGFydGlhbCBsb2NrIHB1Ymxpc2hlZCBhcyBSRkMgNTcx
Ny4NCi0gIE1vbml0b3Jpbmcgc2NoZW1hIGRyYWZ0IGlzIGF0IEFEIHJldmlldywgbmVlZHMgYmV0
dGVyIHNlY3VyaXR5IHNlY3Rpb24gZm9yIFlBTkcgbW9kdWxlIGZvciBkaXNjdXNzaW9uDQotIDQ3
NDFiaXMgaXNzdWUgZGlzY3Vzc2lvbiBvbmdvaW5nDQotIFdpdGgtZGVmYXVsdHMgY2FwYWJpbGl0
eSByZWFkeSBBRCByZXZpZXc/DQotIFVzaW5nIE5FVENPTkYgb3ZlciBTU0g6IHJmYzQ3NDJiaXMs
IG5ldyBXRyBpdGVtIGFkZHJlc3NpbmcgNDc0MiBlcnJhdGEgbmVhciB0afMgZmluYWwNClVuY2hh
cnRlcmVkIGl0ZW1zOg0KLSBSb2J1c3QgQ29uZmlndXJhdGlvbiBNYW5hZ2VtZW50IHdpdGhpbiBO
RVRDT05GDQpuZXcgdmVyc2lvbiB3aXRoIHVwZGF0ZWQgdGV4dA0KLSBOZXRjb25mIEFjY2VzcyBD
b250cm9sIE1vZGVsIA0KQSBmaXJzdCBhbmQgdXNlZnVsIHN0YXJ0DQoNCg0KNDc0MWJpcyAoQW5k
eSBCaWVybWFuKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2xpZGUgMQ0KQW5keTogYmFzZXMg
MS4xIGNhcGFiaWxpdHkgLSBwcm9wb3NpbmcgbmVlZCBhIGJhc2UgMS4xIGNhcGFiaWxpdHkgLCB0
byBkaXN0aW5uZ3Vpc2ggYmV0d2VlbiBleGlzdGluZyByZmMgYW5kIHRoZSBuZXcgdmVyc2lvbiwg
Y3VycmVudGx5IG5vIHdheSB0byB0ZWxsIHRoZSBhIG5ldyBzZXJ2ZXIgaXMgZm9sbG93aW5nIHdo
YXQgc3BlYyBieSBpbnRyb2R1Y2luZyBhIG5ldyBjYXBhYmlsaXR5IGFzIHBhcnQgb2YgdGhlICJo
ZWxsbyIgYWxsb3dzIHRvIHB1dCBuZXcgdGhpbmdzIGluIHRoZSBwcm90b2NvbCB3aGVuIGEgbmV3
IHNlcnZlciBpcyB0YWxraW5nIHRvIGEgbmV3IGNsaWVudC4gZG9lc24ndCB3YW50IHRvIHRyeSB0
byBjaGFuZ2UgNDc0MSwgYSBzZXJ2ZXIgY29uIGZvcm1pbmcgdG8gdGhhdCBjYW4gc3RheSB0aGF0
IHdheSwgY2FuJ3QgdHJ5IGFuZCBmaXggaXQgaW4gdGhlIHByb3RvY29sLCBkb250IHdhbnQgdG8g
YnJlYWsgb2xkIGNsaWVudHMNCnByb3Bvc2FsIC0gY2xpZW50cyB3aWxsIGFkdmVyc3Rpc2Ugd2hh
dCB0aGV5IGNhbiB1c2UsIHdoYXRldmVyIHRoZSBiZXN0IG1hdGNoIGlzIHdpbGwgYmUgdXNlZCwg
b2xkIHNlcnZlciB3aWxsIGJlIHN1cHBvcnRlZCBieSBuZXcgY2xpZW50LCBuZWdvdGlhdGUgYSB2
ZXJzaW9uIGFuZCB0aGVuIGdvIGZyb20gdGhlcmUNCg0Kc2xpZGUgMw0KUGhpbCBTaGFmZXI6IERv
ZXMgaXQgbWVhbiB0aGF0IFJGQyA0NzQxIGRvZXNuJ3QgZ2V0IGRlcHJlY2F0ZWQ/DQpBbmR5OiBO
bywgaXQncyBnb25uYSBiZSBvYnNvbGV0ZWQNClBoaWw6ICBvcmlnaW5hbCB2ZXJzaW9uIHdhcyBh
biBpbXBsaWNpdCBleGNoYW5nZSwgV0cgd2FudGVkIGFuIGV4cGxpY2l0IGV4Y2hhbmdlLiBBcmUg
d2UgZ29pbmcgYmFjayB0byB0aGUgb2xkIGlkZWEgb2YgbmVnb3RpYXRpbmcgY2FwYWJpbGl0aWVz
IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyIGFuZCBzZWxlY3RpbmcgdGhlaXIgaW50ZXJz
ZWN0aW9uPw0KQW5keTogTm90IGluIGdlbmVyYWwsIGJ1dCB0aGlzIGJhc2UgMS4xIGNhcGFiaWxp
dHkgaXMgZXNzZW50aWFsLCBzbyBpdCBzaG91bGQgYmUgYW5ub3VuY2VkIGJ5IHRoZSBjbGllbnQu
IE9sZCBjbGllbnQgc2VuZHMganVzdCBiYXNlLCBuZXcgY2xpZW50IHNlbmRzIGJvdGguIEN1cnJl
bnRseSBzZXJ2ZXIgaXNuJ3QgcmVxdWlyZWQgdG8gc2VuZCB0aGUgYmFzZSBjYXBhYmlsaXR5LCBh
IG5ldyBjbGllbnQgd291bGQgaGF2ZSBuZXcgcmVxdWlyZW1lbnRzIGFuZCBzZW5kIHVwZGF0ZWQg
ZGF0YS4NClBoaWw6IFRyeWluZyB0byBuYWlsIGRvd24gdGhhdCBpdCBzb3VuZHMgbGlrZSBhbiBp
bXBsaWNpdCBjaGFuZ2UgaXMgc29tZXRoaW5nIHRoYXQgd2FzIGRpc2NhcmRlZCBwcmV2aW91c2x5
IGJ5IHRoZSBXRywgdGhpcyBpc250IGFuIGV4cGxpY2l0IGNoYW5nZS4gU28gdGhlIGhlbGxvIHBy
b3RvY29sIGlzIGltcGxpY2l0bHkgY2hhbmdlZC4NCg0KQW5keTogWWVzLCBJIGd1ZXNzIHdlIGNo
YW5nZSB0aGUgcHJvdG9jb2wuIEJ5IHB1dHRpbmcgMS4xIGluIGhlbGxvLCB0aGUgY2xpZW50IGFz
a3MgZm9yIHRoZSBuZXcgYmVoYXZpb3IuDQpXZXMgSGFyZGFrZXI6IFdoYXQgZG9lcyBpdCBicmVh
az8gSWYgaXQgaXMgYW4gaW1wbGljaXQgY2hhbmdlIHZzIGV4cGxpY2l0IGNoYW5nZQ0KDQpQaGls
OiBMZXQncyBtb3ZlIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQpLZW50IFdh
dHNlbjogQ2xpZW50IG1heSB3YW50IGFuIG9sZCB2ZXJzaW9uIG9mIG9uZSBjYXBhYmlsaXR5IGFu
ZCBuZXcgdmVyc2lvbiBvZiBhbm90aGVyIG9uZS4gU29tZXRoaW5nIHRoYXQgbWlnaHQgYnJlYWsg
LSBpZiB3ZSBoYXZlIGNhcGFiaWxpdGllcyB3aXRoIG11bHRpcGxlIHZlcnNpb25zLCB3aGF0IGlm
IGEgY2xpZW50IHdhbnRlZCB0byBtaXggdmVyc2lvbnMgb2YgdGhlIHByb2NvdG9sLg0KDQpBbmR5
OiJidWZmZXQiIHdvbnQgYmUgYWxsb3dlZC0gdGhlIG9sZCBwcm90b2NvbCB3aWxsIGJlIGRlcHJl
Y2F0ZWQNClBoaWw6dGhlcmUgbmVlZHMgdG8gYmUgYSBkZXByZWNhdGlvbiBwb2xpY3kgb3RoZXJ3
aXNlIG9sZGVyIGNsaWVudHMgd2lsbCBicmVhayAtIGFncmVlZC4NCg0KQW5keTogU2VydmVyIG5l
ZWRuJ3Qgc3VwcG9ydCB0aGUgb2xkIHZlcnNpb24gbm9yIGFkdmVydGlzZSBpdC4NCldlczogSSBj
YW4gZW52aXNpb24gdmVuZG9ycyB3aG8gd2lsbCB3YW50IHRvIHdvcmsgd2l0aCB0aGUgb2xkIHZl
cnNpb24tIDEuMSwgMS4yLCAxLjMgLSBkbyB5b3UgaGF2ZSB0byBoYXZlIGEgbWF0cml4IG9mIHdo
YXQgaXMgY29tcGF0aWJpbGUgd2l0aCB3aGF0PyBjb3VsZCBtYWtlIGxpZmUgaW50ZXJlc3Rpbmcu
DQpBbmR5OiBtYXkgaGF2ZSB0byBsb29rIGF0IHRoZSBjbGllbnQgaGVsbG8gLSBjdXJyZW50bHkg
dGhlcmUgaXNudCBhIHdheSB0byBhc2sgZm9yIGEgZG93biByZXYgdmVyc2lvbiBvZiB0aGUgcHJv
dG9jb2wsIHdlIHJlYWxseSBuZWVkIHRvIGxvb2sgYXQgdGhpcyBhbmQgc2VlIHdoYXQgd2UgbmVl
ZCBpZiB0aGUgb2xkIHdheSB3YXMgYnVnZ3ksIA0KQW5keTogZG8gd2UgaW5zaXN0IHRoYXQgc2Vy
dmVycyBzdXBwb3J0IHNvbWV0aGluZyBvbGQgdGhhdCBpcyBrbm93biBicm9rZW4/IFNvIHRoZSBz
ZXJ2ZXIgd2lsbCBoYXZlIHRvIHN1cHBvcnQgc29tZXRoaW5nIHRoYXQgaXMgYnJva2VuIGluZGVm
aW5pdGx5PyBIYWQgYW4gZXJyb3IgaW4gdGhlIG5hbWVzcGFjZS4NCm5lZWQgdG8gZml4LCBNYXJ0
aW4gbWF5IG5lZWQgdG8gZXhwbGFpbiB0aGlzIG5leHQgb25lLCBoYXMgYW4gaXNzdWUgd2l0aCB0
aGUgbmFtZXNwYWNlIC0gbmFtZXNwYWNlIG1vZHVsZQ0KQW5keTogbmFtZXNwYWNlIHN0YXlzIHRo
ZSBzYW1lIGFuZCBsb29raW5nIGF0IHRoZSBiYXNlIDEuMSA8aGVsbG8+IG1vZHVsZSwgZG8gd2Ug
bmVlZCB0byBzcGVjaWZ5IHRoZSBvcmRlcj8gDQpubyBhZHZlcnRpc2UgdGhlIDEuMCBhbmQgdGhl
IDEuMSwgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCBhbGwgdGhlIHlhbmcgc3R1ZmYgZXhpc3Rp
bmcgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgZXhwZWN0aW5nIGNlcnRhaW4gdGhpbmdzLCBkb250
IHdhbnQgdG8gYnJlYWsgdGhpbmdzDQoNCnNsaWRlNA0KTWFydGluIEJq9nJrbHVuZDogRWl0aGVy
IGNvbnRpbnVlIHVzaW5nIGNhcGFiaWxpdGllcyBvciBzdGFydCB1c2luZw0KWUFORyBmZWF0dXJl
cy4NCkFuZHk6IFRoaXMgd2lsbCBiZSBkaXNjdXNzZWQgbGF0ZXIuIA0KDQowMDQtZXJyb3Igc2V2
ZXJpdHkNCkFuZHk6IG5lZWQgdG8gYmUgYWJsZSB0byB0ZWxsIHRoZSB2ZXJzaW9ucyBhcGFydCwg
dG8gZml4IHRoZW0gd2UgbmVlZCB0byBicmVhayBvbGQgY2xpZW50cw0Kd2l0aG91dCBzdGFuZGFy
ZCB3YXJuaW5ncywgbm90IG5lZWRlZCB0byBhZGQgd2FybmluZ3MgLSBjb21wbGV0ZSBvdmVyc2l0
ZSBpbiA0NzQxIC0gc2hvdWxkIHdlIGFkZCB3YXJuaW5ncyBub3c/IG5vdGhpbmcNCg0KMDA2IC0g
bXVsdGlwbGUgbmFtZXNwYWNlcw0KQW5keTogbGVnYWN5IHRleHQgLSBpbiA3LjEgZGlmZmVyZW50
IG5hbWVzcGFjZXMgY2FuIGhhdmUgZGlmZmVyZW50IGZvcm1hdHMsIG5vdCBhIHByb3RvY29sIHRo
aW5nIGlzIGEgZGF0YSBtb2RlbCB0aGluZywgbm90IGEgbmV0Y29uZiB0aGluZywgcmVtb3Zpbmcg
dGhhdCB0ZXh0DQoNCjAwOC0gc3VidHJlZSBmaWx0ZXJpbmcNCkFuZHk6IGVuYWJsZSBzcGVsbGNo
ZWNraW5nPyBsb2w/IHN1YnRyZWUgZmlsdGVyaW5nIGlzc3Vlcywgc29tZSBvZiBpdCB3cml0dGVu
IGJlZm9yZSB4bWwgd2FzIGZ1bGx5IHVuZGVyc3Rvb2QgcHJvcGVybHkuIFRoZSB0ZXh0IGltcGxp
ZXMgYXR0cmlidXRlcyBuZWVkIHRvIGJlIGluIGEgY2VydGFpbiBwbGFjZSBidXQgdGhhdCBpc250
IHRoZSBjYXNlIGluc3RhbmNlIG1hdGNoZXM/IA0KTWFydGluOiBpZiB5b3UgaGF2ZSBhIGxlYWYg
bGlzdCB3aXRoIGEgY291cGxkIHZhbHVlcyBhbmQgZ2V0IGEgY291cGxlIG1hdGNoZXNvbmUgaW5z
dGFuY2UgbWF5IG1hdGNoIGFub3RoZXIgbWF5IG5vdD8gDQpBbmR5OiBuZWVkIHRvIGZpbmQgdGhl
IHRleHQgdG8gY2hhbmdlIGl0IC0gc2hvdWxkJ3QgbG9vayBsaWtlIGFuZCAiYW5kIiBzaG91bGQg
YmUgY2xlYW5lZCB1cA0KDQowMDktIHBhcnRpYWwgb3BlcmF0aW9uIGVycm9yDQpBbmR5OiBubyBv
bmUgY2FyZXMsIG5vIG9uZSBpcyBnb25uYSBtaW5kIG9yIHVzZSBpdCAtIHJyZXR1cm5zIGEgZmxh
dCBsaXN0IG9mIGtleXMgLSBnb25uYSByZW1vdmUgaXQsIG5ldmVyIHdlbnQgYW55d2hlcmUNCg0K
MDEwLSBmaWx0ZXIgbmFtZXBzcGFjZSB3aWxkY2FyZA0KQW5keTogbmV3IGFkZGl0aW9uIC0gb2sg
dG8gdXNlIHRoZSBudWxsIG5hbWVzcGFjZSB0byBtYXRjaCBhbGwgbmFtZXMgLSBzdXBwb3J0IGlu
IHZhcmlvdXMgcHJvcGlldGFyeSB3YXlzIC0gYWx0aG91Z2ggYSAxLjEgc2VydmVyIGNvdWxkIHNh
eSBJIGRvbnQgaGF2ZSBhbnl0aGluZyBpbiB0aGUgbnVsbCBuYW1lcHNhY2UsIGFyZSBubyBlcnJv
cmVzIGluIHRoZSBmaWx0ZXIsIGl0IGVpdGhlciBtYXRjaGVzIG9yIGRvZXNudCByZXR1cm4gYW55
dGhpbmcNCmNvdWxkIHVzZSBpdCBvbiBhIDEuMSBzZXJ2ZXIgYnV0IHdvdWxkIG50IHdvcmsNCg0K
MDEyIC0gY29weSBjb25maWcNCkFuZHk6IGN1cnJlbnRseSBkb2VzbnQgaGF2ZSBhIHRvcCBsZXZl
bCAtIHNob3VsZCBiZSB0aGUgbmV0Y29uZiBiYXNlIGNvbmZpZyBlbGVtZW50IC0gaGFzIHRvIHN0
YXJ0IHdpdGggdGhhdCB0b3BpY2FsIGVsZW1lbnQgLSBhbnkgaXNzdWVzPyBub3RoaW5nDQoNCjAx
MyAtIGNvbmZpZ21yZWQgY29tbWl0DQpBbmR5OiB3ZWFrbmVzcywgc2FtZSB1c2VyIHNlc3Npb24g
dGhhdCBzdGFydGVkIHRoZSBwcm9jZWR1cmUgaGFzIHRvIGZpbnNpaCBpdCwgd2UgYWdyZWUgd2Ug
ZG9udCBsaWtlIHRoYXQgcmVzdHJpY3Rpb24gLSBpZiB0aGUgY29uZmlnIGdldHMgY2hhbmdlZCB5
b3UgY2FudCBkbyBhbnl0aGluZyBhYm91dCBpdCAtIG1hcnRpbiB0aGlua2luZyB0byBhZGQgbmV3
IHBhcm1zIHRvIHN1cHBvcnQgMS4xDQp3aGF0IGFib3V0IG5vdGlmaWNhdGlvbnM/DQpzeXN0ZW0g
Z3JvdXAgbGF0ZXINCg0KMDE0IC0gY2FwYWJpbGl0eSBjaGFuZ2UNCkFuZHk6IGJpZ2dlc3QgY2hh
bmdlIC0gbmV3IGVycm9yLCBjb25maWd1cmF0aW9uIGNoYW5nZSwgd2hlbiB0aGUgY29uZmlndXJh
dGlvbiBjaGFuZ2VzLCBldmVyeW9uZSBuZWVkcyB0byByZXN5bmMgdmlhIHJlc2VuZGluZyB0aGUg
PGhlbGxvPiBhZ2FpbiB0byBnZXQgYWxpZ25tZW50IC0gb25seSBvbiB0aGUgMS4xIHNlcnZlciwg
d291bGRuJ3QgaW1wYWN0IHRoZSAxLjAgc2VydmVyIC0gc29tZSBkaXNjdXNzaW9uLSBhc3NvcnRl
ZCBzcGVjaWFsIGNhc2VzIG9yIHJlYXNvbnMgd2h5IG5vdCB0byBkbyB0aGlzIG9yIHRvIGRvIHRo
aXMgLSBjYW4gcmVzeW5jIGFsbG93IGFuIGV4aXN0aW5nIGV4Y2hhbmdlIHRvIGtlZXAgZ29pbmcg
d2l0aCBhY2tvd2xlZGdlbWVudCAtDQp0aGlzIGlzIGEgYmlnIGNoYW5nZSB0byBrZWVwIHRoZSBj
bGllbnRzIHVwIHRvIGRhdGUNCg0Kc2xpZGUxOA0KRGF2aWQgUGFydGFpbjogQWx0aG91Z2ggSSdk
IGJlIGluIGZhdm9yIG9mIHVzaW5nIFlBTkcgZmVhdHVyZXMsIEkgZG9uJ3QgaGF2ZSBhIGdvb2Qg
ZmVlbGluZyBhYm91dCB0aGUgcmlwcGxlIGVmZmVjdC4NCkFuZHk6IEl0IHdvdWxkIGFsc28gYmUg
cXVpdGUgYSBidXJkZW4gdG8gd29yayBib3RoIHdpdGggY2FwYWJpbGl0eSBhbmQgZmVhdHVyZSBu
b3RhdGlvbi4NCg0KMDE5IC0gY2xhcmlmeSBjb3B5LWNvbmZpZw0KQW5keTogZXNvdGVyaWMgdGV4
dCB0aGF0IG5lZWRzIHRvIGJlIGNoYW5nZWQgLSB3aHkgZG8gd2UgbmVlZCBkaXNjYXJkIGNoYW5n
ZXMgYnV0IHdoYXQgYWJvdXQgY29weSBmcm9tIGNhbmRpZGF0ZSB0byB0byBydW5uaW5nIGlzbnQg
dGhlIHNhbWUgdGhpbmcNCnRob3JueSBpc3N1ZSB3aXRoIGFjY2VzcyBjb250cm9sIC0gZG9lcyBh
IGdldCBjb25maWcsIGdvbm5hIHB1dCB0aGF0IGNvbmZpZyBiYWNrLCByZXN0b3JlIGZyb20gbXkg
Y29weSwgYWNjZXNzIGNvbnRyb2wgaGFzIGNoYW5nZWQgdGhlIGNvbmZpZyAtIHNlcnZlciBzYXlz
IHdhaXQgYSBzZWMsIGknbSByZWplY3RpbmcgdGhlIGVudGlyZSBvcGVyYXRpb24uIG5lZWQgdG8g
YWRkIHRleHQgdG8gY2xhcmlmeSBpdCwgcG9zc2libGUgcG9pbnQgb2YgY29uZnVzaW9uDQoNCjAy
MC0gY2hhbmdlcyBkdXJpbmcgY29tbWl0DQpBbmR5OiBhcmUgeW91IGFsbG93ZWQgdG8gY2hhbmdl
IHRoaW5ncyBpbiB0aGUgcnVubmluZyBjb25maWcgb3I/IHRleHQgbWF5IG5vdCBiZSBjbGVhciBl
bm91ZyB1bmxlc3MgeW91IHJlcmVhZCBpdCwgaWYgeW91IGFkZCBuZXcgdGhpbmdzIGluIHRoZSBz
ZWNvbmQgY29tbWl0LCB0aGUgc2VydmVyIG1heSB0byBleHBlY3QgYW5vdGhlciB0aGlyZCBjaGFu
Z2UgZXRjIC0gaXMgYSAiZmVhdHVyZSIgdW5wcm90ZWN0ZWQgZmVhdHVyZSwgaWYgdGhlIGNvbmZp
cm0gY2hhbmdlIHRpbWVzIG91dCwgeW91ciBjaGFuZ2VzIGdldCBjbG9iYmVyZWQsIGFuZCB5b3Ug
ZGVhbCB3aXRoIGl0DQoNCjAyMSAtIGRlZmF1bHQgZGF0YQ0KQW5keTogaG93IG11Y2ggZG8gd2Ug
bmVlZCB0byBzYXkgaW4gdGhlIHByb3RvY29sIHNwZWMgb24gaGFuZGxpbmcgZGVmYXVsdHMgLSBk
b250IHdhbnQgdG8gaW50cm9kdWNlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBoZXJlDQpvbmUgaXNz
dWUgLSB0aGUgc2VydmVyIGtub3dzIGhvdyBpdHMgc3VwcG9zZWQgdG8gc2F2ZSB0aGluZ3MgaW4g
bnZyYW0gLSAic2hvdWxkIGl0IGJlIGRvbmUgaW4gdGhlIGJhc2ljIG1vZGUiIG9yIG90aGVyIGZv
cm1hdHMsIG5vdCBzdXJlIHdoYXQgdG8gc2F5Li4gY29tbW9uIHRoaW5nIHRvIGRvIGlzIHRvIHVz
ZSBleHBsaWNpdCBtb2RlLCBvbmx5IHRoZSBjb21tYW5kcyB0aGUgb3BlcmF0b3Igd2FudHM/DQoN
CjAyMi0gY2FwYWJpbGl0ZXMgdGV4dA0KQW5keTogbGFzdCBvcGVuIGlzc3VlLCBZQU5HIGZlYXR1
cmVzIG5ldyBpc3N1ZQ0KdGhlIGludGVudCBpcyB0aGUgWUFORyBtb2R1bGUgaXMgdGhlIG5ldyBp
c3N1ZSwgNDc0MSBoYXMgdGhpbmdzIGFib3V0IG5ldyBzdHVmZiAtIFlhbmcgd2FudHMgeW91IHRv
IGRlZmluZSBhIG1vZHVsZSBhbmQgcGFydGl0aW9uIGl0IHdpdGggZmVhdHVyZXMgLSB3aGF0IGRv
IHdlIHdhbnQgdG8gZG8/IGNvbnZlcnQgZmVhdHVyZXMgdG8gPw0KaXRzIGp1c3QgYSBkaWZmZXJl
bnQgc3RyaW5nIGZvciB0aGUgc2VydmVyIHRvIHBhcnNlLCB0aGF0IGlzbnQgYSBiaWcgZGVhbCwg
aXQgZG9lcyBjaGFuZ2UgdGhlIG1pbmRzZXQgdGhvdWdoDQoNCkRhbjogdGhpcyB3b3VsZCBvbmx5
IHdvcmsgaW4gMS4xPyANCkFuZHk6IHdvdWRubHQgYmUgY29tcGF0aWJsZSB3aXRoIDEuMA0KaW5j
bGluZWQgdG8gbm90IGRvIGl0PyBmb3IgbmV3IGZ1bmN0aW9uYWxpdHkgdGhlIFlhbmcgbW9kdWxl
IGlzIHRoZSBuZXcgZmVhdHVyZSB3aXRoIHRhZ3MgaW4gdGhlIFVSST8gQXV0aG9ycyBsaWtlIHRo
ZSBZYW5nIGZlYXR1cmVzIGJ1dCB3aWxsIHRoZXJlIGJlIHRvbyBtdWNoIHdvcmsNCg0KRGF2aWQ6
IG5vbmF1dGhvcnMgbGlrZSBpdCBhcyB3ZWxsLCBob3dldmVyIHdoYXQgaXMgdGhlIHJpcHBsZSBm
YWN0b3IsIGhvdyBkcmFtYXRpYyBhcmUgdGhlIGNoYW5nZXM/IA0KQW5keTogU29tZXRpbWVzIHlv
dSB3YW50IHRoZSBvbGQgdmVyc2lvbiBvZiBhIGNhcGFiaWxpdHkgLSBkbyB3ZSB3YW50IHRvIHN1
cHBvcnQgdGhhdCwgc29tZXRoaW5nIHRoZSBjb2RlIGNoYW5nZXMga2VlcCBwaWxpbmcgaW4gYW5k
IGJlY29tZXMgYSBidXJkZW4gdG8gc3VwcG9ydCBldmVyeXRoaW5nIGlzc3VlIG9mIHRoZSBjbGll
bnQgc2VkbmluZyB0aGUgaGVsbG8gLSB0aGV5IGN1cnJlbnRseSBkb250IHNlbmQgYWxsIHRoZSBy
ZXF1aXJlbWVudHMgb2Ygd2hhdCB0aGV5IG1pZ2h0IG5lZWQgdG8gYmUgYWJsZSB0byBrbm93IHdo
YXQgdGhlIHNlcnZlciBpcyBnb25uYSBkbyAtIHdvdWxkIHJlcXVpcmUgdHdvIGhlbGxvJ3MgdG8g
YWN0dWFsbHkgZ2V0IHRocm91Z2ggaXQgYWxsDQoNCkJlcnQ6IHdoYXQgSSBzZWUgaXMgbW9yZSBk
aXNjdXNzaW9uIG9uIGJhc2UgMS4xIHRoaXMgd2VlayBob3BlZnVsbHksIGdldCBpdCB0byB0aGUg
bWFpbGluZyBsaXN0LCB0aGlzIG5ldyBpc3N1ZSBuZWVkcyBzb21lIGhhbGx3YXkgZGlzY3NzaW9u
cyB0aGlzIHdlZWsgdGhlbiBtYWlsaW5nIGxpc3QsIG5ldyBjaGFuZ2VzLSANCmRpZG50IHNlZSBt
dWNoIGNvbW1lbnQgdGhhdCB0aGUgY2hhbmdlcyBhcmUgYWNjZXB0YWJsZT8gcG9sbGluZyB0aGUg
cm9vbSAtIHJlc3BvbnNlPyBhbGwgb2YgdGhlbT8gDQpXRyBjaGFpciB3YW50cyBjb25zZW5zdXMg
b24gdGhpbmdzLSBkaWQgdGhlIGhtbSB0ZXN0DQoNCnJ1bm5pbmcgb3V0IG9mIHRpbWUgLSBzb3Vu
ZHMgbGlrZSBvbiB0aGUgcmlnaHQgdHJhY2sgYW55d2F5LCB3aWxsIGdldCBpdCBvdXQgdG8gdGhl
IG1haWxpbmcgbGlzdCwgdHdvIGlzc3VlcyB0byBkaXNjdXNzIGluIG1vcmUgZGV0YWlsLCANCg0K
QW5keTogbGFzdCBjeWNsZSB3ZSBoYWQgb3BlbiBpc3N1ZXMgYW5kIHRoZXkgZGlkbnQgZ2V0IGRp
c2N1c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0IC0gDQpXRyBjaGFpciAtIHBlb3BsZSBkaWRudCBy
ZWFjdCBhbmQgd2UgbmVlZCB0byBkbyBhIGxhc3QgY2FsbCBvbiB0aGUgaXNzdWVzIHNvIHdlIGNh
biBiZSBkb25lIHdpdGggaXQgDQpleGFtaW5lIGNvbnZlcnRpbmcgY2FwYWJpbGl0ZXMgdG8gWWFu
ZyAtIG1heWJlIHdlIGRpc2N1c3MgdGhpcyB3ZWVrIGFuZCBkZWNpZGUgaWYgd2UgbW92ZSBmb3J3
YXJkIA0KDQpCZXJ0IFdpam5lbiAoYXMgV0cgY2hhaXIpOiBTdW1tYXJpemluZyAtIG1vcmUgZGlz
Y3Vzc2lvbiBpbiB0aGUgTUwgbmVlZGVkIGFib3V0IGJhc2UgMS4xLg0KVGhlcmUgd2FzIGEgcm91
Z2ggaHVtbWluZyBjb25zZW5zdXMgb24gQW5keSdzIHByb3Bvc2FscyBmb3IgcmVzb2x2aW5nIHRo
ZSBpc3N1ZXMsIGJ1dCBlYWNoIG9uZSBoYXMgdG8gYmUgY29uZmlybWVkIGluIE1MLg0KDQp3aXRo
LWRlZmF1bHRzIChBbmR5KQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQW5keTogY2hhbmdlcyBm
cm9tIC0wNCB0byAtMDUgLSBjaGFuZ2VkIHRoZSBib2lsZXJwbGF0ZSBhbmQgbWF5IG5lZWQgdG8g
ZG8gaXQgYWdhaW4gMjAgdGltZXMNCndpdGggZGVmYXVsdHMgZmVhdHVyZSBoYWQgYSBZYW5nIGZl
YXR1cmUgdGhhdCBkaWRudCBkbyBhbnl0aGluZywgcmVtb3ZlZCBpdCAtIG5vdCBzdXJlIHdoeSBp
dCB3YXMgaW4gdGhlcmUNCmNoYW5nZWQgdGhlIGRlZmluaXRpb24gb2YgZXhwbGljaXQgdG8gbWF0
Y2ggdGhlIFlhbmcgbW9kZSAtIGhhcyBhIGh1Z2UgaW1wYWN0IG9uIGNyZWF0ZWFuZCBkZWxldGUg
LSBjbGllbnQgbmVlZHMgdG8gcGF5IGF0ZW50aW9uIHRvIGhvdyBhIHNlcnZlciBpcyBnb2luZyB0
byB0cmVhdCBkZWZhdWx0cywgZW1haWxzIHdpdGggUGhpbCAtIGZvciBjcmVhdGUsIHRoZSBzZXJ2
ZXIgbXVzdCB0cmVhdCBpdCBpZiBpdCBpc250IHRoZXJlIC0gY2xpZW50IGNhbiBzZXQgYSB2YWx1
ZSAzIC0gaWYgYSBkaWZmZXJlbnQgY2xpZW50IGNoYW5nZXMgaXQgIml0IGlzbnQgdGhlcmUiIC0g
dGhpbmtzIGl0cyBiZXN0IHRoYXQgdGhlIFlhbmcgZGVmaW5pdGlvbiBhbGlnbnMgd2l0aCBpbmR1
c3RyeQ0KDQpyZW1vdmVkIHhzZCBhbmQgbWFkZSBpdCBub3JtYXRpdmUNCnVwZGF0ZWQgdXJpIG1v
ZHVsZSAtIA0KZXZlciBuZXRjb25mIHNlcnZlciBTSE9VTEQgDQphbnkgcXVlc3Rpb25zPw0KDQpJ
dHMgdGltZSB0byB1c2UgWWFuZyBub3csIGxldHMgdXNlIG91ciBZYW5nIGhhdHMgbm93DQpiaWcg
Y2hhbmdlIHRoYXQgWWFuZyBpcyBub3JtYXRpdmUgYW5kIG5vdCB0cnlpbmcgdG8gcHVzaCB0aGlz
IGFoZWFkIHdpdGhvdXQgYSBZYW5nIG1vZHVsZQ0KDQpXRyBjaGFpciAtIGFyZSB3ZSByZWFkeSBm
b3IgbGFzdCBjYWxsIG9uIHRoaXMgb25lPyBQaGlsIGFyZSB3ZT8geWVzDQpqdXN0IGxpc3RlZCB0
aGUgY2hhbmdlcyB0aGF0IHdlcmUgbWFkZSwgbm90IHRoYXQgbmVlZCB0byBiZSBtYWRlLCB0aGlu
ayBzbyAtIHRha2UgYSBsb29rIGFuZCBsZXQgdXMga25vdw0KDQpCZXJ0OiBTaG91bGQgdGhlIGRv
Y3VtZW50IGdvIHRvIFdHTEM/DQpNYXJ0aW46IEkgYW5kIExhZGEgc2VudCBjb21tZW50cywgc28g
d2UgbmVlZCBhbiB1cGRhdGVkIHJldmlzaW9uIGJlZm9yZSBXR0xDLiAgDQpCZXJ0OiBXaWxsIGlz
c3VlIGEgbGFzdCBjYWxsIGFuZCBtb3ZlIGZvcndhcmQNCg0KNDc0MmJpcyAoTWFyZ2FyZXQgV2Fz
c2VybWFuKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpyZmMgNDc0MiBzdGF0dXMgdXBk
YXRlDQp0aGUgcG9pbnQgdG8gdGhlIHVwZGF0ZSB3YXMgdG8gbWVyZ2UgaW4gc2V2ZXJhbCBlcnJh
dGEgYW5kIGNoYW5nZXMsIGdldCB0aGVtIGluIHF1aWNrIGFuZCBnZXQgdGhlbSBvdXQNCk1hcnRp
biBoYWQgY29tbWVudHMsIEp1ZXJnZW4gaGFkIGNvbW1lbnRzDQpDbGllbnQvU2VydmVyLCBBZ2Vu
dC9tYW5hZ2VyLCBpbnN0ZWFkIHJlZmVyIHRvIHRoZSBTU0ggY2xpZW50LCB0aGUgU1NIIHNlcnZl
ciwgdGhlIE5FVENPTkYgY2xpZW50IGFuZCB0aGUgTkVUQ09ORiBzZXJ2ZXIgdGhyb3VnaG91dA0K
DQpzbGlkZSA0DQpEYXZpZCBQLjogVGVybWlub2xvZ3kgU1NIIGNsaWVudC9zZXJ2ZXIgYW5kIE5F
VENPTkYgY2xpZW50L3NlcnZlciBtYWtlcyBhIGdvb2Qgc2Vuc2UuDQpBbmR5OiBXb3VsZCB0aGlz
IHRlcm1pbm9sb2d5IGZhaWwgZm9yIFNTSCBjYWxsYmFjaz8gd291bGQgdGhpcyBtYWtlIGl0IGhh
cmRlciB0byBhZGQgImNhbGwgaG9tZSIgY2FwYWJpbGl0eSB0byBuZXRjb25mIC0gc2VydmVyIG1p
Z2h0IGFodmUgdG8gaW50aWF0ZSB0aGUgY2FsbCwgZG9jIHNheXMgdGhlIGNsaWVudCB3aWxsIGFs
d2F5cyBpbml0aWF0ZS4NCk1hcmdyZXQ6IG1vcmUgY2FsbCBob21lIC0gdGNwIGNsaWVudCB0Y3Ag
c2VydmVyLCBvbiB0b3Agb2YgdGhlIGFjY2VwdGVkIGNsaWVudCwgc3NoIG9uIHRvcCBvZiB0aGF0
Pw0KS2VudDogV2l0aCB0aGUgY2FsbGJhY2ssIHRoZSBORVRDT05GIHNlcnZlciB3aWxsIG9ubHkg
YmVjb21lIFRDUCBjbGllbnQsIFNTSCBjbGllbnQgd2lsbCBhbHdheXMgYmUgdGhlIE5FVENPTkYg
Y2xpZW50IGFzIGJlZm9yZS4gU28gdGhlIG5ldyB0ZXJtaW5vbG9neSBpcyBmaW5lIGZvciB0aGUg
Y2FsbGJhY2ssIHRvby4NCg0KTWFyZ2FyZXQgc2F5cyBpcyB0aGlzIG91dCBvZiBzY29wZT8gUXVl
c3Rpb24gaXMgdGhpcyBpcyBhIGdvb2Qgc3VnZ2VzdGlvbiBiZWNhdXNlIGl0cyBub3Qgc3BlY2lm
aWMgZW5vdWdoIHRoZSBhZmZlY3QgdGhlICJjYWxsIGhvbWUiIGRpc2N1c3Npb24NCk9wZXJhdGlv
bnMgdnMgQ29tbWFuZHMsIGRvYyBhcyBub3csIHJlZmVycnJlZCB0byB4bWwgY29tbWFuZHMgZXRj
LCBjaGFuZ2UgImNvbW1hbmRzIiB0byBvcGVyYXRpb25zIC0gYW55IG9iamVjdGlvbnMgLSB0aGlz
IHdvdWxkIG1ha2UgdGhpcyBtb3JlIGFsaWdubWVudCB3aXRoIHBhcmVudCBkb2MNCg0Kc2xpZGUg
NQ0KS2VudDogUlBDIG1lc3NhZ2UgaXMgbm90IGFuIG9wZXJhdGlvbi4NCk1hcnRpbjogWWVzLCB3
ZSBoYXZlIHRvIGtlZXAgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBSUEMgbWVzc2FnZSBhbmQgb3Bl
cmF0aW9uLg0KDQpNYXJnYXJldCAtIGhlYXJkIGtlbnQgYWdyZWUgd2l0aCBNYXJ0aW4gLSBvayB0
byBwcm9jZWVkPyANCmNvbmZ1c2VkIC0gcnBjIG1lc3NhZ2VzIGFuZCAtIHNvdW5kcyBsaWtlIHdl
IGFyZSBnb2luZyB0byBjaGFuZ2UgaXQgdG9vIG11Y2g/IA0KDQpQaGlsOiBCdXQgdGhlIGRyYWZ0
IHdhbnRzIHRvIGNoYW5nZSBib3RoIHRvICJvcGVyYXRpb24iLg0KTWFyZ2FyZXQ6IE9LLCB3ZSBz
aG91bGQga2VlcCB0aGUgdGVybSAibWVzc2FnZSIgaWYgd2Ugc3BlYWsgYWJvdXQgdGhlIGVudGly
ZSBSUEMgbWVzc2FnZS4gDQpHb2luZyBmb3J3YXJkIHdpdGggTWFyZ2FyZXQncyBjbGFyaWZpY2F0
aW9uDQoNCk5vdGlmaWNhdGlvbnMtIA0KbGlrZXMgdGhlIGlkZWEgb2YgYW55IG1lc3NhZ2Ugd2l0
aG91dCBoYXZpbmcgdG8gcmV2IHRoZSBkb2MgLSB3aGVyZSBleGFtcGxlcyAiYW55IG1lc3NhZ2Ui
IGNhbiBiZSBzZW50DQoNCnNsaWRlIDYNCk1hcmdhcmV0OiBJIHBlcnNvbmFsbHkgc3VwcG9ydCBK
dWVyZ2VuJ3Mgc3VnZ2VzdGlvbi4NCldvcmRpbmcgY2hhbmdlIG5vdCBpbnRlbmRlZCBmdWNudGlv
bmFsIGNoYW5nZSwgdHJ5IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBpdHMgbm90IGp1c3QgcnBjIGNv
bW1hbmRzIHJlY2VpdmVkLCBpdHMgYWxsIG1lc3NhZ2VzIHJlY2VpdmVkIHdvdWxkIG5vdCBiZSBo
YW5kbGVkIGFmdGVyIHRoZSBzZXNzaW9uIGlzIGNsb3NlZC4NCg0KTWFydGluOiBZZXMsIGl0J3Mg
YmV0dGVyIHRvIHRhbGsgYWJvdXQgZ2VuZXJpYyBtZXNzYWdlcy4NCk1hcmdyZXQ6IE5leHQgU3Rl
cHMgLSBtYWtlIGFsbCB0aGUgY2hhbmdlcywgdGhlbiBnbyB0byBsYXN0IGNhbGwNCg0Kc2xpZGUg
Nw0KS2VudDogQnV0IHRoZXJlIGlzIG5vIHNlc3Npb24gYWZ0ZXIgPGNsb3NlLXNlc3Npb24+LiBM
YW5ndWFnZSBvbiB0aGUgbGFzdCBzbGlkZSAtIGNsb3NlIHNlc3Npb24gLSBzb3VuZHMgbGlrZSBj
dXJyZW50IHNzaCBjaGFubmVsIGlzIG1vcmUgdGhlIHdvcmRpbmcgZGVzaXJlZC4NCk1hcmdhcmV0
OiB0aGUgc3BlYyBzaG91bGQgcmVhZCBvbmNlIHRoZSBzZXNzaW9uIGNsb3NlIGlzIHJlY2VpdmVk
LCBzZXJ2ZXIgcmVzcG9uZHMgYW5kIHRoYXRzIGl0LCANCk1hcnRpbiBhZ3JlZXMuDQpNYXJnYXJl
dDogbmVlZCB0byB3b3JrIG9uIHRoZSB3b3JkaW5nIHRvIGJlIGNsZWFyIG9uIHRoZSBzc2ggc2lk
ZSBzaW5jZSB5b3UgbmVlZCB0aGF0IHRvIGZpbnNpaCB0aGUgY2xvc2UgLSAibXVzdCBub3QgcHJv
Y2VzcyBhbnkgbmV0Y29uZiBtZXNzYWdlcyByZWNldmllZCBhZnRlciB0aGUgY2xvc2Ugc2Vzc2lv
biBvcGVyYXRpb24iDQpNYXJ0aW46IFdlIHNob3VsZCByYXRoZXIgc2F5IHRoYXQgdGhlIHNlcnZl
ciBNVVNUIE5PVCBwcm9jZXNzIGFueSBtZXNzYWdlcyBvbiB0aGUgc2FtZSBTU0ggY2hhbm5lbCBh
ZnRlciA8Y2xvc2Utc2Vzc2lvbj4uIFRoZSBzZXJ2ZXIgc2hvdWxkIGFjdHVhbGx5IGNsb3NlIHRo
ZSBjaGFubmVsLCBvdGhlcndpc2Ugd2UgaGF2ZSB0byBpbnZlbnQgYSB3YXkgZm9yIG9wZW5pbmcg
YSBuZXcgc2Vzc2lvbiBpbiB0aGUgc2FtZSBjaGFubmVsLg0KDQpCZXJ0IChhcyBXRyBjaGFpcik6
IENhbiB0aGUgZG9jdW1lbnQgcHJvY2VlZHMgdG8gV0dMQz8gSHVtbWluZyBjb25zZW5zdXMgb24g
WUVTLg0KDQpCZXJ0OiBJdCBzaG91bGQgZ28gdG9nZXRoZXIgd2l0aCBSRkMgNDc0MWJpcy4gSXQn
cyBiZXR0ZXIgaWYgdGhlIHJlZmVyZW5jZSBpcyB0byB0aGUgbmV3IE5FVENPTkYgcHJvdG9jb2wg
c3BlYy4NCnJlZmVyZW5jZSB0aGUgNDc0MWJpcyAtIGhvcGVmdWxseSBzZW5kIHRoZW0gYm90aCB0
b2dldGhlciB0byBnZXQgc3VjY2Vzc2l2ZSBudW1iZXJzLCB3ZSBjYW4gYXNrIGZvciBjb25zZWN1
dGl2ZSBudW1iZXJzLg0KDQpSb2J1c3QgQ29uZmlndXJhdGlvbiBNYW5hZ2VtZW50IChCb2IgQ29s
ZSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkJvYjogdGFsayBh
Ym91dCB0aGUgM3JkIHZlcnNpb24gb2YgdGhlIHJvYnVzdCBuZXRjb25mIGRyYWZ0LCB0aGlua2lu
ZyBhYm91dCBjaGFuZ2luZyB0aGUgbmFtZSAtIGRlZmluaW5nIHZlcmlmaWNhdGlvbiBjYXBhYmls
aXR5IHZhbGlkYXRpb24gaXMgY2hlY2tpbmcgYWdhaW5zdCBydWxlcywgdmVyaWZpY2F0aW9uIGlz
IG1lYXN1cmVpbmcgYWdhaW5zdCBydW5uaW5nIGNvZGUgY2hhbmdlcyBmcm9tIDAxIHRvIDAyDQoN
CnZlcnNpb24gMiBkZWZpbmVzIHZlcmlmeS15YW5nIGRlZmluaXRpb25zLCBvcGVyYXRpb25zLCBu
b3RpaWNhdGlvbnMsIHJlcXVpcmVtZW50cw0KdmVyaWZ5LnlhbmcgbW9kdWxlIHB1c2hlZCB0ZXN0
aW5nIHRvIHRoZSBzZXJ2ZXIgLSBjYW4gZG8gY3JvcyB2ZXJpZmljYXRpb24sIG11bHRpc3RhZ2Ug
b3BlcmF0aW9uLCA5Z29pbmcgb3ZlciB0aGUgc2xpZGUpIGNhbiBjYW5jZWwgdGhlIHZlcmlmaXkg
DQp2ZXJpZmljYXRpb24gdGVzdCBzdWl0ZSBjYW4gYmUgY29tcG9zZWQgb2YgbXVsdGlwbGUgdGVz
dCBzZXRzIHdpdGggbXVsdGlwbGUgcGFybXMsIHRpbWUgYWxsb3dlZCBldGMsIHZlcmJvc2VuZXNz
IG9mIHRoZSBjbGllbnQgcmVwb3J0aW5nIGJhY2sgZXRjIA0KdmVyaWZ5IGV4YW1wbGUgLSByZWZl
ciB0byB0aGUgc2xpZGUgZ29pbmcgb3ZlciB0aGUgZXhhbXBsZQ0KY2FuY2VsLXZlcmlmeSBleGFt
cGxlIC0gZm9sbG93IHRoZSBzbGlkZQ0KZXhhbXBsZSBwaW5nLnlhbmcgcmVmZXIgdG8gdGhlIHNs
aWRlIChuYXR1cmUgb2YgdGhlIHJlcG9ydGluZyBhbmQgdGhlIG5hdHVyZSBvZiB0aGUgcGFzcyBm
YWlsIGFuZCBjb25zaXN0ZW50LSBsZWFmIGxpc3QgaW5kZXggcGFzc2VkICwgY2FuIHB1bGwgcmF3
IHJlc3VsdHMgZXRjDQoNCkRpc2N1c3Npb24gYWZ0ZXIgdGhlIHByZXNlbnRhdGlvbjoNCktlbnQ6
IElzIHRoaXMgY29tcGxlbnRlbHkgaW5kZXBlbmRlbnQgb2YgY2FuZGlkYXRlIGNvbmZpZ3VyYXRp
b24/IEJvYjpTaG91bGQgYmUgaW5kZXBlbmRlbnQsIHNldCBvZiB0ZXN0cyB5b3UgcnVuIGFnYWlu
cyB0aGUgcnVubmluZyBjb25maWcsIGNhbiBmaXggdGhhdCBmb3IgY2xhcml0eS4NCkJvYjogSSBh
c3N1bWUgaXQgaXMuIHRyaWVkIHRvIG1pbmltaXplIHRoZSB2ZXJiaWFnZSBpbiB0aGUgbWFpbiBi
b2R5IGFuZCBwdXQgdGhlIHJlc3QgaW4gdGhlIGFwcGVuZGl4DQoNCkRhbiBSb21hc2NhbnUgKGFz
IGNvbnRyaWJ1dG9yKTogV2UgaGF2ZSBwbGFucyB0byBhZGQgb3RoZXIgdHlwZXMgb2YgdGVzdHMg
bGlrZSBPRU0uIGFjdGl2YXRpbmcgc3R1ZmYgbGlrZSBvZW0gdGVzdGluZyBhdCBhIGxvdyBsYXll
ciBldGMgYXMgYW4gZXhhbXBsZSBvZiB3aGF0IGNhbiBiZSBkb25lDQpCb2I6IHVzZSBjYXNlcyBl
dGMgbmVlZCBjbGFyaWZpY2F0aW9uDQoNCktlbnQ6IFdvdWxkIHNlc3Npb24gdGVybWluYXRpb24g
aW5mbHVlbmNlIHRoZSB2ZXJpZmljYXRpb24/IEFueSB2YWx1ZSB0byBhZGRpbmcgbGFuZ3VhZ2Ug
dG8gY2xvc2luZyBzZXNzaW9ucyByZSBzc2ggYW5kIG5ldGNvbmYgYW5kIGNvbmZpbSBjb21taXQg
LSBkb2VzIGl0IG1ha2VzIHNlbnNlIHRvIGZvbGxvdyB0aGF0IGRpc2N1c3Npb24NCkJvYjp0aGlz
IGlzIGluZGVwZW5kZW50IGZyb20gY29uZmlybS1jb21taXQgLSBuZWVkcyB0byBiZSB0aG91Z2h0
IGFib3V0IC0gY291bGQgY2FzZXMgd2hlcmUgeW91IGFyZSBydW5uaW5nIGEgdGVzdCBhZ2FpbnN0
IGEgZGlmZmVyZW50IHNlcnZlciBpdCBtaWdodCBkcm9wIGJ1dCB0aGVyZSBjb3VsZCBiZSBnb29k
IGRhdGEgc3RpbGwgdGhlcmUgdG8gYmUgbG9va2luZyBhdA0KQm9iOiBHb29kIHF1ZXN0aW9uLCB3
aWxsIGxvb2sgYXQgaXQuDQp0aGFua3MgZm9yIHRoZSBvcHBvcnR1bml0eQ0KDQpNYXJ0aW46IElz
IHBpbmcueWFuZyBqdXN0IGFuIGV4YW1wbGUsIG9yIGlzIGl0IGdvaW5nIHRvIGJlIGEgc3RhbmRh
cmRpemVkIHRlc3QuDQpCb2I6IEkgdGhpbmsgYm90aC4gVGhpbmtzIHRoZXJlIG5lZWRzIHRvIGJl
IG1vZHVsZXMgcmVsYXRlZCB0byBhIHRlc3QueWFuZyBtb2R1bGUsIGNvdWxkIGdvIG9uIGZvcmV2
ZXIsIEJvYiBzYXlzIHN0YXJ0IHNtYWxsIHdpdGggcGluZyBhbmQgYnVpbGQgaXQgdXAgLSBhbHNv
IHdoZXJlIGRvIHRlc3QgbW9kdWxlcyBmaXQgaW4NCkJlcnQ6IHBpbmcueWFuZyBjYW4gYmUganVz
dCBhbiBleGFtcGxlLCBidXQgaXQgc2hvdWxkIHN0aWxsIGJlIHNwZWNpZmllZCBpbiBhIHNlcGFy
YXRlIGRvY3VtZW50LiBUaGlzIHdvcmsgbmVlZHMgYXQgbGVhc3Qgc29tZSB0ZXN0IG1vZHVsZXMg
dG8gd29yayB3aXRoLg0KQm9iIC0gaG93IGRvIHlvdSBtYWtlIGEgdGVzdCBtb2R1bGUgdGhhdCBp
cyBleHRlbnNpYmxlIGFuZCBjb21wbGV0ZSBldGMgLSB0YWxraW5nIGFib3V0IE1JQiBtb2R1bGVz
IGFuZCBybW9uIHdnIHRpZSBpbg0KDQpNZWhtZXQ6IGhhbmRzIG9uIHdobyBoYXMgcmVhZCB0aGUg
ZG9jIC0gc29tZSBoYW5kcyAobWFydGluIGV0YykNCk1laG1ldCAoYXMgV0cgY2hhaXIpOiBBcmUg
dGhlcmUgYW55IHByb3NwZWN0aXZlIGltcGxlbWVudG9ycz8gKFR3byBoYW5kcyByYWlzZWQpLg0K
UGhpbDogV2hhdCdzIHRoZSBwb2ludCBvZiBhdXRvbWF0aW5nIGl0IGluIHRoZSBkZXZpY2U/IFdo
eSBjYW4ndCB0aGUgY2xpZW50IGRyaXZlIHRoZSB0ZXN0cz8gaWYgdGhpcyBpcyBhIGNsaWVudCBk
cml2ZW4gY2hhbmdlLCBzaG91bGRudCB0aGUgY2xpZW50IGJlIGRydmluZyB0aGUgY2hhbmdlPw0K
Qm9iIC10aG91Z2h0IHRoZSBxdXllc3Rpb24gd2FzIHdoeSBjYW4gd2UgZG8gc3NoIHJlcXVlc3Rz
DQpCb2I6IFNvbWV0aW1lcyB0aGUgc2VydmVyIGlzICh0ZW1wb3JhcmlseSkgaW52aXNpYmxlLg0K
DQpQaGlsOmNsaWVudCBzaG91bGQgYmUgZHJpdmluZyB0aGUgdGVzdCAtDQpCb2ItIHRoYXQncyB3
aGF0IHZlcmlmeS55YW5nIGRvZXMgLSBjb29yZGluYXRlIHRoZSB0ZXN0cyBldGMgaW4gYW4gaW50
ZXJvcGVyYWJsZSBiYXNlDQpQaGlsOiBpZiB0aGVyZSBpcyBhIHJlYWwgcGluZy55YW5nIC0gcnBj
IHRvIGEgZGV2aWNlIC0gdGhlcmUgaXMgbW9yZSB2YWx1ZSBoZXJlIHRoZW4gdGhlIG5ldyBpZGVh
DQpEYW4gKGFzIGNvbnRyaWJ1dG9yKTogVGhhdCdzIGhvdyBPRU0gd29ya3MsIHRoZXJlIGlzIGEg
bGV2ZWwgb2YgdGVzdCBhdXRvbWF0aW9uIGFtb25nIHNlcnZlcnMuIG9lbSBpbiBtcGxzIG9yIHNv
IG9uLCBpcyBhIGxheWVyIDIgMi41IHRoYXQgd29ya3MgYmV0d2VlbiByb3V0ZXJzIGFuZCBzd2l0
Y2hlcyAtIGNhbiByZXRyaWV2ZSBvciBkbyBzcGVjaWFsIHRoaW5ncyB0aGF0IGhhcyBhIGxldmVs
IG9mIGF1dG9tIGF0aW9uIHRoYXQgaXMgdGhlcmUuDQoNClBoaWw6IEJ1dCB5b3UgY2FuIHN0aWxs
IGV4cG9zZSB0aGVzZSB0ZXN0cyBhcyBSUENzLiBXaGVuIHdyaXRpbmcsIGUuZy4sIGEgQkdQIG1v
ZHVsZSwgSSBhbHNvIGhhdmUgdG8gd3JpdGUgdGVzdCBvcGVyYXRpb25zLiBhbnl0aGluZyB5b3Ug
Y2FuIGV4cG9zZSB0aHJvdWdodCB0aGlzIHZlcmlmaWNhdGlvbiBtZXRob2QgaW9zIHJlYWxseSBy
YXcgcnBjLCBpZiB5b3UgaGF2ZSB0aGF0IHdvdWxkIGRvZXMgdGhpcyBnZXQ/DQpCb2I6IERlZmlu
aW5nIGFuIFJQQyBzaWduYXR1cmUgaXMgZGlmZmVyZW50IGZyb20gc3BlY2lmeWluZyB0ZXN0IHNl
bWFudGljcy4NCkJvYjogZ2V0cyB5b3UgYW4gaW50ZXJvcGVyYWJsZSBtZXRob2QgYmV0d2VlbiBj
bGllbnRzIGFuZCBzZXJ2ZXJzLA0KDQpQaGlsOiBpZiB5b3UgZGVmaW5lIGEgbW9kdWxlIHlvdSB3
aWxsIGRlZmluZSBvcGVyYXRpb25zIHdpdGhpbiB0aGUgbW9kdWxlLCBzbyBhbnkgc2VydmVyIHNo
b3VsZCBoYXZlIHN0YW5kYXJkIG9wZXJhdGlvbnMgDQpCb2IgLSBjYWxsaW5nIGFuIHJwYyBvcGVy
YXRpb24gc3RhbmRhcmQgaXMgZGlmZmVyZW50IHRoYW4gaGF2aW5nIGNlcnRhaW4gbGVhZiBvYmpl
Y3RzIGNhbGxlZCBvdXQgb3IgZGVmaW5lZCAtIA0KQm9iIC0gaG9waW5nIGZvciBjb21tb25hbGl0
eQ0KDQpBbmR5OiBUaGlzIGlzIHByb3ZpZGluZyBhIGZyYW1ld29yayB3aGVyZSB5b3UgY2FuIGRl
ZmluZSBhIHNldCBvZiB0ZXN0cyBpbiBhbiBpbnRlcm9wZWFyYmxlIHdheS4NCnVzaW5nIHRoZSBN
SUIgYW5hbG9neSwgdGhlcmUgYXJlIHByb3BpZXRhcnkgbW9kdWxlcyBhbmQgdGhlIG4gd2h5IGhh
dmUgYSBzdGFuZGFyZCBvbmUNCg0KQW5keTpkaXNjdXNzaW5nIGl0IGlzIGFsbCBhYm91dCB0aGUg
bW9kdWxlIG9yIHRoZSBmcmFtZXdvcmssIG5hc3R5IG1vZHVsZSwgeW91IGZpeCBpdCwgYnV0IGlm
IHlvdSBoYXZlIDUgcGluZy55YW5nIGZyb20gZGlmZmVyZW50IHZlbmRvcnMgdGhhdCBhcmUgZGlm
ZmVyZW50IHRoZW4gd2hhdCAtIHRoaXMgcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIHRlc3Rpbmcg
YnV0IGRvZXNudCBwcmVjbHVkZSB5b3UgaGF2ZSB0ZXN0aW5nIG9uIHlvdXIgb3duDQphZ2FpbiBp
ZiB0aGVyZSBpcyBhIHN0YW5kYXJkIHlhbmcgbW9kdWxlIHdoYXQgZG9lcyB0aGlzIGFkZD8NCg0K
Qm9iOiBpb2YgdGhlcmUgaXMgYSBtb2R1bGUgYnVpbHQgb25lIHdheSBldGMgLSBhbGwgbWFubmVy
IG9mIHByb3RvY29scywgaXQgZ2V0cyBjb21wbGljYXRlZCBhbmQgdGhlcmUgaXNudCBhIGNvbW1v
biBzdGFuZGFyZCB0byBpbnRlcmFjdCB3aXRoLCBtYXliZSB0aGF0cyB3aGF0IHlvdSB3YW50DQpE
YW46IFdlIG5lZWQgdG8gZ28gYmV5b25kIC0gb3IgYmV0dGVyIGV4cGxhaW4gLSB0aGUgdGVybSAi
ZnJhbWV3b3JrIi4gV2UgYXJlIHRyeWluZyB0byBzdGFuZGFyZGl6ZSBob3cgdGhlIHRlc3RzIGFy
ZSBhY3RpdmF0ZWQuDQpCb2I6IC0wMiByZXZpc2lvbiBnb2VzIGRlZXBlciBpbnRvIGRpZmZlcmVu
Y2VzIGJldHdlZW4gdGVzdCBzaWduYXR1cmUgYW5kIHRlc3QgcHJvY2VkdXJlLg0KDQpXRyBjaGFp
ciBhcyBjb250cmlidXRvcjogVGhhdCBtYXkgaGF2ZSBhbnN3ZXJlZCB0aGUgcXVlc3Rpb24sIHdo
YXQgdGhpcyBpcyBkb2luZyBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvciBkaWZmZXJlbnQg
bW9kdWxlcy9wcm90b2NvbHMgKGJncCwgb3NwZiwgd2hhdGV2ZXIpIC0gZG9lcyB0aGlzIG1ha2Ug
c2Vuc2UgUGhpbDogaWYgd2Ugc3RhbmRhcmRpemUgb24gaXQsIGRvIHdlIHJlcXVpcmUgaXQgLSBp
ZiB5b3Ugd2FudCBpdCB0byB3b3JrIHdpdGggdGhlIHZlcmlmeS55YW5nIG1vZHVsZQ0KDQpCZXJ0
OiBCdXQgaXQgbWFrZXMgbGlmZSBtb3JlIGRpZmZpY3VsdCB0byBtb2R1bGUgd3JpdGVycyBzaW5j
ZSB0aGVyZSBhcmUgbmV3IHJ1bGVzIHRvIG9ic2VydmUuDQpQaGlsOiB5b3UgZG9udCBnZXQgYXdh
eSBmcm9tIGl0LCB5b3UgYXJlIHNhdmluZyBycGMncyB3aXRoIHBhcnRpY3VsYXIgc2V0cyBvZiBh
cmd1bWVudHMsICJydW4gNTcsIDIxLCA0MiIgZXRjIA0KQm9iOiBBcyBhIHVzZXIgSSBkb250IHdh
bnQgYSBjb2xsZWN0aW9uIG9mIGluZGVwZW50YW50bHkgZGV2ZW9wZWQgeWFuZyBtb2R1bGVzLCBy
ZWFsbHkgd2FudCBzb21lIGtpbmQgb2YgY29uZm9ybWl0eSwgc29tZSBkYXkgaGF2ZSBhICJuZXR3
b3JrIHZlcmlmeSIgLSBpdHMgY29vcmRpbmF0ZWQgZXRjDQpCb2I6IFllcywgYnV0IEkgZG9uJ3Qg
d2FudCB0byBoYXZlIGEgcmFuZG9tIHNldCBvZiBpbmRpdmlkdWFsbHkgZGV2ZWxvcGVkIHRlc3Rz
IC0gdGhlcmUgaXMgYSByaXNrIG9mIGNvbmZsaWN0cy4NCihzb3VuZHMgbGlrZSBpdCBib2lscyBk
b3duIHRvIGZyYW1ld29yayB2cyB0aGUgcnBjIGNhbGxzKQ0KDQpXRyBjaGFpcjogQ2FuIHdlIHRh
a2UgdGhpcyB0byB0aGUgbGlzdCAtIGFncmVlZA0KTWVobWV0OiBXaG8gaXMgaW50ZXJlc3RlZCBp
biBoYXZpbmcgdGhpcyB3b3JrIGFzIFdHIGl0ZW0/IChXZWFrIGh1bSkuDQpNYXJ0aW46IEkgYW0g
aW50ZXJlc3RlZCwgYnV0IHdlIHNob3VsZCByZXNvbHZlIHRoZSBkaXNjdXNzaW9uIGZpcnN0Lg0K
Qm9iOiBBZ3JlZWQuDQpNZWhtZXQ6IENhbiB5b3UgYnJpbmcgdGhlIGlzc3VlcyBkaXNjdXNzZWQg
aGVyZSB0byB0aGUgbWFpbGluZyBsaXN0Pw0KQm9iOiBZZXMuDQpEYW4gKGFzIEFEKTogVGhlIGh1
bSB3YXMgdGltaWQsIG1vcmUgZGlzY3Vzc2lvbiBpbiBNTCBpcyBuZWVkZWQuIE5lZWQgdG8gZmxl
c2ggb3V0IHdoYXQgaXMgY2hhcnRlciB2cyBuZWVkcyB0byB3b3JrZWQgb3V0IGFuZCBjb25maXJt
ZWQgb24gdGhlIG1haW4gbGlzdA0KDQoNCkFjY2VzcyBDb250cm9sIE1vZGVsIChBbmR5KQ0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpjb25zaWRlcnMgYWNjZXNzIGNvbnRyb2wgYSBtdXN0
IGhhdmUgbm90IGEgbmljZSB0byBoYXZlIC0gY3VycmVudGx5IHRoZXJlIGlzbnQgYW55IHdheSB0
byBjb250cm9sIGFjY2Vzcw0KYXQgdGhpcyBwb2ludCwgZXZlcnkgdXNlciBpcyBhIHJvb3QgdXNl
ciwgaWYgeW91IGNhbiBnZXQgaW4sIHlvdSBnb3QgaXQgYWxsDQpubyBvbmUgdXNlcyBhIHJ1biBh
cyByb290IG1vZGVsDQoNCnNsaWRlIDUNClBoaWw6IEkgZG9uJ3QgYWdyZWUgdGhhdCB3aXRob3V0
IEFDTSBldmVyeSB1c2VyIGhhcyB0byBiZSByb290Lg0KTWFydGluOiBOZWl0aGVyIGRvIEkuDQpX
ZXM6IEkgYmVsaWV2ZSB0aGUgTkVUQ09ORiBzcGVjIHNheXMgdGhhdCBBQ00gaXMgbmVlZGVkIGJ1
dCBubw0Kc3RhbmRhcmQgZXhpc3RzLg0KV2VzOmRvYyBzYXlzIGV2ZXJ5dGhpbmcgc2hvdWxkIGhh
dmUgYW4gYWNjZXNzIGNvbnRyb2wgbW9kZWwsIGFuZCBkb250IGhvbGQgdXAgZXZlcnl0aGluZyB0
byBkZWJhdGUgdGhlICJyb290IiBkaXVzY3Vzc2lvbg0KDQoNCkFuZHkgLSBnb25uYSBnbyB3aXRo
IG1lbW9yeSBzaW5jZSBzbGlkZXMgZG9udCBsaW5lIHVwDQpDb25jZXB0dWFsIG1vZGVsIGRpYWdy
YW0gLSANCmp1bXBpbmcgdGhyb3VnaCBzbGlkZXMNCm5lZWQgZm9yIGFjY2VzcyBjb250cm9scyBp
cyB0aGVyZSBzaW5jZSBhY2Nlc3MgaXMgdW5ib3VuZGVkDQpuZXRjb25mIGludHJvZHVjZXMgZGlm
ZmVyZWluZyBsYXllcnMgb2YgYWNjZXNzIHdoZXJlIHNubXAgZGlkbnQgbmVlZA0KdGhyZWF0cyBj
b3VsZCBEb1MgYXR0YWNrIHRoZSBzZXJ2ZXIgYW5kIHJlaW5qZWN0IGNyYXAsIG5lZWQgYWNjZXNz
IGNvbnRyb2wNCgkNCnNsaWRlIDgNCkFuZHk6IERvIHdlIG5lZWQgYSBzdGFuZGFyZCBBQ00/IChT
dHJvbmcgaHVtbWluZyBjb25zZW5zdXMuKQ0KQmVydDogVGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9p
bnQuIFRoZSBjb25zZW5zdXMgbWVhbnMgdGhhdCBXRyBzaG91bGQNCndvcmsgb24gaXQgYW5kIHdl
IGhhdmUgdG8gZGVjaWRlIHdoYXQgdG8gZG8uDQoNCk5BQ00gcmVxdWlyZW1lbnRzDQoxLCAyLCAz
IGZyb20gdGhlIHNsaWRlcw0Kbm9uY29udHJvbCBwb2ludCwgaWYgeW91IGNhbiBnZXQgdGhlIHJl
cXVlc3QsIHlvdSBnZXQgdGhlIHJlcGx5IC0gdGhlIHNlcnZlciBpc24ndCByZXF1aXJlZCB0byBw
YXJzZSB0aGUgcmVzdWx0cyBmb3IgYW55dGhpbmcgc3BlY2lhbA0KV0cgY2hhaXIgLSB3b3VsZCBs
aWtlIHRoZSBncm91cCB0byBiZSBhd2FyZSB0aGlzIGlzIGEgYmlnIGRlYWwsIEFuZHkgZGlkIHRo
ZSBpbml0aWFsIHdvcmsgYnV0IGl0IG5lZWRzIHRvIGdvIGJlZm9yZSB0aGUgZ3JvdXANCkFuZHkg
YnJpbmdzIHVwIHRoYXQgd2UgZG9udCB3YW50IHRvIG1ha2UgaXQgdG9vIGNvbXBsZXggYnV0IGl0
IG5lZWRzDQoNCnNsaWRlIDkNCktlbnQ6IFdoYXQgaGFwcGVucyB0byBnZXQtY29uZmlnIGlmIHlv
dSBkb24ndCBoYXZlIGFjY2VzcyB0byBhbGwNCm5vZGVzPw0KQW5keTogVGhhdCdzIGFuIGV4dHJh
IGlzc3VlLCB3aWxsIGJlIGRpc2N1c3NlZCBsYXRlci4NCkFuZHkgd2UgaGF2ZSB0byBiZSBhYmxl
IHRvIHNwZWNpZnkgd2hhdCBpcyBhbGxvd2VkIC0geWFuZyBjYWxscyBpdCBhIGRhdGEgbm9kZSwg
dGhhdCBpcyBjb250cm9sLSANCg0KDQpzbGlkZTEwDQpLZW50OiBTbyBpcyBhY2Nlc3MgY29udHJv
bCBmb3Igbm90aWZpY2F0aW9uIGJhc2VkIG9ubHkgb24gZXZlbnRUeXBlLg0KQW5keTogVGhlIHNl
cnZlciBqdXN0IGRvZXMgc2ltcGxlIGZpbHRlcmluZyBiYXNlZCBvbiBldmVudFR5cGUgYW5kIHRo
ZW4gZG9lc24ndCBjYXJlIGFib3V0IHRoZSBjb250ZW50cyBvZiB0aGUgbm90aWZpY2F0aW9ucy4N
Cg0KQW5keSAtIGRvbnQgd2FudCBldmVyeW9uZSB0byBzZWUgdGhlIGNvbmYgY2hhbmdlIG5vdGlm
aWNhdGlvbiBvciBhY2Nlc3MgY29udHJvbCBicmVhayBpbiBvciBpbnRydXNpb24gZGV0ZWN0aW9u
LCBtYXliZSB5b3UgZG9udCB3YW50IHRvIHRlbGwgdGhlIGhhY2tlciBoZSdzIGhhY2tpbmcNCg0K
c2xpZGUgaXMgc2F5aW5nIHRoaXMgaXMgYSBzaW1wbGUgZmlsdGVyIG9uIHRoZSBldmVudCB0eXBl
IC0gdGhpcyBpcyBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgZnJvbSBzbm1wDQpzaW1wbGljaXR5
IC0gdHJ5aW5nIHRvIGJlIHNpbXBsZSBlbm91Z2ggdG8gYmUgdXNlZA0KVkFDTSBpZ25vcmVkIGxv
Y2FsaXplZCBjb3N0cw0Kc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgcmVhZCwgcmlnaHQgLCBleGVj
IC0gDQphbnkgY29tbWVudHMgb24gdGhpcz8NCmNyZWF0ZSBhbmQgZGVsZXRlIGFyZSBwYXJ0IG9m
IHdyaXRlPyANCg0Kc2xpZGUgMTENCktlbnQ6IElzIGNyZWF0ZSBwZXJtaXNzaW9uIHByb3ZpZGVk
IGJ5IHdyaXRlIHBlcm1pc3Npb24/DQpBbmR5OiBZZXMuDQpNYXJ0aW46IFRoZSBjb25jZXB0IG9m
IGJlaW5nIGFibGUgdG8gY2hhbmdlIHNvbWV0aGluZyBidXQgbm90IGRlbGV0ZQ0KaXQgaXMgc3Ry
YW5nZS4NCmNvbmNlcHQgb2YgY2hhbmdpbmcgc29tZXRoaW5nIGJ1dCBub3QgZGVsZXRpbmcgaXMg
aW1wb3J0YW50Lg0KDQpCZXJ0OiBJcyBsb2NrIHBlcm1pc3Npb24gaW5jbHVkZWQ/DQpBbmR5OiBZ
ZXMsIGxvY2tpbmcgcGVybWlzc2lvbiBzaG91bGQgYmUgYWRkZWQuIHlvdSBjb3VsZCBoYXZlIGFu
IGFjY2VzcyBydWxlIHRoYXQgcHJldmVudHMgbG9jaywgYnV0IG5vdCBzdXJlIGlmIHRoYXQncyBh
IGdvb2QgaWRlYS4NCg0KV2VzOiBJIGFncmVlIHRoYXQgQUNNIGlzIG5lZWRlZCwgdGhpcyBpcyBh
IGdvb2Qgc3RhcnQuIFF1ZXN0aW9uOiBJcyB0aGUgZGVmYXVsdCBwb2xpY3kgdG8gYWxsb3cgb3Ig
ZGlzYWxsb3c/DQpBbmR5OiBEZWZhdWx0IGlzIHJlYWQgYW5kIGV4ZWMsIG5vdCB3cml0ZS4gIEJ1
dCBpdCBpcyBjb25maWd1cmFibGUsIG5lZWQgdG8gZGViYXRlIHRoZSBtb2RlbC9yZXF1aXJtZW50
cy4NCldlczogV2UgbmVlZCB0byBzZXBhcmF0ZSByZXF1aXJlbWVudHMgZnJvbSBzb2x1dGlvbnMu
DQoNCkJlcnQ6IFdlJ2xsIGdldCB0byB0aGF0LiBXZSBhcmUgZGlzY3Vzc2luZyByZXF1aXJlbWVu
dHMsIGJ1dCBpdCdzIGhlbHBmdWwgdG8gaWxsdXN0cmF0ZSB0aGVtIHdpdGggdGVudGF0aXZlIHNv
bHV0aW9ucy4NCkRhdmlkIFBlcmtpbnM6IFRoZSBleHBsYW5hdGlvbiBvZiBTTk1QIGFjY2VzcyBj
b250cm9sIHByb2JsZW1zIGlzIG5vdCBzdWZmaWNpZW50LiBQZW9wbGUgdW5kZXJzdGFuZCBhY2Nl
c3MgY29udHJvbCBhdCB0aGUgdGFzayBsZXZlbCBpbnRvIHRoZSBwYWluIG9mIGZpZ3VyaW5nIG91
dCBvciB0b28gZXhwZW5zaXZlIHRvIGltcGxlbWVudA0KDQpBbmR5OiBJIGRpZG4ndCBpbnRlbmQg
dG8gZGljdXNzIGl0IGluIGFueSBkZXRhaWwuIGxvY2FsaXplZCBjb3N0IGlzIGFuIGlzc3VlLCBz
b3JyeSBoZSBicm91Z2ggdXAgc25tcA0KRGF2aWQgUGVya2luczogSXQgaXMgdW5hY2NlcHRhYmxl
IHRvIGJlIGZhY2VkIHRvIGEgbW9yZSBjb21wbGljYXRlZCB0YXNrd2l0aG91dCBiZWluZyBhYmxl
IHRvIG1hcCBpdCB0byBhY2Nlc3MgY29udHJvbC4NCnN1cmUgdGhlcmUgaXMgYSB3YXkgdG8gd3Jh
cCBzZW5zaXRpdmUgZGF0YSBpbiBhbiBvcGFxdWUgd2F5IHRvIHJldHVybiBzcGVjaWFsIGRhdGEg
DQoNCkFuZHk6IHJlcXVpcmVtZW50IC0gYWNjZXNzaW5nIHRoZSBkYXRhYmFzZSBuZWVkcyB0byBh
cHBseSB0byBjYW5kaWRhdGUgZXRjIC0gcmVmZXIgdG8gdGhlIHNsaWRlDQoNCnNsaWRlIDEyDQpL
ZW50OiBXaGF0IGFib3V0IGFjY2VzcyBjb250cm9sIG9mIG90aGVyIG1ldGhvZHMgb2YgY2hhbmdp
bmcgY29uZmlndXJhdGlvbnMgKENMSSBldGMuKT8NCkFuZHk6IFRoaXMgaXMgb3V0IG9mIHNjb3Bl
Lg0KDQpBbmR5IC0gbG9jayBpcyBpbmRlcGVuZGVudCBvZiBhY2Nlc3MgbWV0aG9kDQpBbmR5IC0g
Y29uY2VwdCBvZiB1c2VycyBhbmQgZ3JvdXBzICwgZXRjDQpBbmR5IC0gY29uY2VwdCBvZiBhIHN1
cGVydXNlciBmb3IgYWNjZXNzIGNvbnRyb2wgYnlwYXNzIGR1ZSB0byBsb3N0IHBhc3N3b3JkcyBl
dGMNCg0Kc2xpZGUgMTQNClBoaWw6IFdlIHNvbWV0aW1lcyBkb24ndCBoYXZlIHRoZSBzdXBlcnVz
ZXIuDQpTT1ggY2F1c2VkIGNlcnRhaW4gdGhpbmdzIHRvIG5vdCBoYXZlIGEgc3VwZXJ1c2VyLCBt
YXkgbm90IGJlIGFibGUgdG8gZG8gdGhhdCBpbiBzb21lIGNhc2VzDQoNCldlczogU29tZSBjdXN0
b21lcnMgbmV2ZXIgZW5hYmxlIGEgcHJvdG9jb2wgdGhhdCBhc3N1bWVzIGEgdXNlciB0aGF0IGNh
biBkbyBldmVyeXRoaW5nLiBJbml0aWFsIGFjY2VzcyBjb250cm9sIGhhcyB0byBiZSBzZXQgb3V0
IG9mIGJhbmQuDQpBbmR5OiBJdCBkb2Vzbid0IHNlZW0gbGlrZSBhIGdvb2QgaWRlYS4gUHJvYmxl
bSB3aXRoIE9PQiBpcyB0aGF0IGl0IHByZWNsdWRlcyBhdXRvbWF0aW9uLg0KQW5keSAtIHNheXMg
dGhpcyBpcyBvdXQgb2YgYmFuZD8gb3IgaWYgeW91IGRvbnQgaGF2ZSBhIHN1cGVydXNlciAoaWYg
dGhhdCBpcyB5b3VyIGNhc2UpIHRoZW4gaWdub3JlIHRoaXMgc2VjdGlvbg0KQW5keSAtIHRhbGtp
bmcgYWJvdXQgc3VwZXJ1c2VyIGFjY2VzcyBhbmQgZmlyc3Qgb25lIGluIHdpbnMsIA0KV2VzIC0g
c2F5aW5nIHRoYXQgc2luY2UgdGhlIHN1cGVydXNlciBpcyB0aGUgYm9vdHN0cmFwLCB0aGF0IGlz
IGFuIGlzc3VlDQpBbmR5IC0gdGhpbmtzIHRoaXMgaXMgYSBib290c3RyYXAgaXNzdWUNCldlcyAt
IHRoZXJlIG5lZWRzIHRvIGJlIGFuIGluaXRpYWwgc2V0dXAgbGF5ZWQgb3V0DQpBbmR5IC0gZG9l
c250IGxpa2UgdGhhdCB0aGVyZSBtdXN0IGJlIGFuIG91dCBvZiBiYW5kIHByb3BpZXJ0YXJ5IG1l
dGhvZCB3aXRoaW4gdGhlIHN0YW5kYXJkLCB3aHkgY2FudCB3ZSBoYXZlIG5ldGNvbmYgZHVlIGl0
DQpXZXMgLSB3ZSBhcmUgY2hvb3NpbmcgYXV0b21hdGlvbiBvdmVyIHNlY3VyaXR5IC0gdGhlcmUg
aXMgdGhlIGJhdHRsZQ0KDQpQaGlsOiBTbyB5b3UgdHJhZGUgc2VjdXJpdHkgZm9yIGF1dG9tYXRp
b24uIEkgZG9uJ3QgYWdyZWUgc3VwZXJ1c2VyIHNob3VsZCBiZSByZXF1aXJlZC4NCkRhbjogSXQg
aXMgYSBkZWrgIHZ1LiBXZSBsZWQgdGhlIHNhbWUgZGlzY3Vzc2lvbnMgMTUgeWVhcnMgYWdvIGFu
ZCB0aGUgY29uY2x1c2lvbiB3YXMgdGhhdCBzdXBlcnVzZXIgd2FzIG5lZWRlZC4NCg0KQW5keTog
b24vb2ZmIHN3aXRjaCBvbiB0aGUgYWNjZXNzIGNvbnRyb2wsIFNlcGFyYXRlIGRlZmF1bHQgbW9k
ZXMgLSByZWFkLWRlZmF1bHQsIHdyaXRlLWRlZmF1bHQsIGV4ZWMtZGVmYXVsdCwgDQppbmRlbnRp
Znlpbmcgc2VjdXJpdHkgaG9sZXMtIA0Kc2xpZGUgLSByaWdodCBub3cgaXQgc2VlbXMgdGhhdCB3
ZSBuZWVkIHRvIHRhZyB0aGUgZGF0YSB3aXRoaW4gdGhlIG1vZHVsZSBmb3Igd2hhdCBpcyBzY25z
aXRpdmUgdnMgZm9yY2luZyB0aGUgb3BlcmF0b3IgZG9pbmcgd29yayBhcm91bmRzIG9yIHNlY3Vy
aXR5IHRvIHByZXZlbnQgaXQsIHdlIHNob3VsZG4ndCBoYXZlIGhvbGVzIHRvIGJlZ2luIHdpdGgs
IHN1Z2dlc3RpbmcgdGhhdCB0aGUgc2Vuc2l0aXZlIGRhdGEgYmUgdGFnZ2VkIHdpdGhpbiB0aGUg
bW9kdWxlDQoNCnNsaWRlMTYNCkJvYjogQ2FuIHRoZSBkZWZhdWx0IHBlcm1pc3Npb25zIGJlIHNl
dCBieSBhbiBvcGVyYXRvcj8NCkFuZHk6IE5vLCBvbmx5IGJ5IG1vZHVsZSB3cml0ZXJzLg0KdGFn
Z2luZyB3b3VsZCBhcHBseSB3aGVuIHRoZXJlIGFyZW4ndCBleHBsaWNpdCBydWxlcw0KDQpzbGlk
ZTE5DQpXZXM6IFtNZW50aW9ucyBwYXJhbm9pZCBjdXN0b21lcnMsIEkgbWlzc2VkIHRoZSBwb2lu
dF0NCg0KZGF0YSBzaGFkb3dpbmcgYW5kIGxlYWthZ2UgLQ0KdGhlIHByb3RvY29sIGxlYWtzIGlu
Zm9ybWF0aW9uLCBsZWFmIHJlZiwgaGlzdG9yeSBjb3VudGVyIGV0YyBmcm9tIGEgc2VjdXJpdHkg
cGVyc3BlY3RpdmUgd2UgbWlnaHQgaGF2ZSBpc3N1ZXMgaWYgd2UgdHJ5IGFuZCBsb2NrIGl0IGRv
d24sIG5vIG9uZSBlbHNlIGRvZXMgdGhpcw0KaWYgeW91IGhhdmUgbGVhZiByZWYncyB0aGF0IGFy
ZSByZWZlcmVuY2luZyBlYWNoIG90aGVyLCB5b3Ugc3RpbGwgbmVlZCBhY2Nlc3MgYWxsIHRoZSB3
YXkgZG93bg0Kd2UgbmVlZCBwcmFjdGljZXMgaG93IHdlIGRvIGRhdGEgbW9kZWxzIGV0YyAtIA0K
DQpXRyBjaGFpcjogY29tbWVudHM/IG5vdGhpbmcgDQptb25pdG9yaW5nIGFuZCBlcnJvcnMgLSAN
Cg0KQW5keSB0aGlua3Mgc2hvdWxkIGtlZXAgdHJhY2sgb2Ygd3JpdGUgb3IgZXhlYyBkZW5pZWQg
aXMgZ29vZCBlbm91Z2gsIG5vdCB0aGF0IHdlIHNob3VsZCB0cmFjayByZWFkcyBldGMNCkFuZHk6
IHNubXAgZ2V0IG5leHQgYmFyZi8NCldlcyAtIGhhcyBjdXN0b21lcnMgdmVyeSBzZW5zaXRpdmUg
YWJvdXQgZGF0YSBsZWFrYWdlLCB0YWxraW5nIGdlbmVyaWNhbGx5ICwgQW5keSBicmluZ3MgdXAg
TUlCIHdhbGtpbmcsIA0KDQpCZXJ0OiBDb25zZW5zdXMgY2FsbCAtIGRvIHlvdSBhZ3JlZSB3aXRo
IHRoZSBnaXN0IG9mIHRoZSByZXF1aXJlbWVudHM/DQpNZWhtZXQ6IFRoaXMgZG9lc24ndCBwcmVj
bHVkZSBvdGhlciBwb3RlbnRpYWwgcmVxdWlyZW1lbnRzLCByaWdodD8NCkJlcnQ6IE5vLCBidXQg
d2Ugc2hvdWxkIGhhdmUgYSBicm9hZCBpZGVhIHdoYXQgdGhlIHNldCBvZiByZXF1aXJlbWVudHMg
aXMuDQpCZXJ0IGVjaG9pbmcgV2VzJ3MgY29tbWVudHMgYWJvdXQgcmVxdWlyZW1lbnRzIGFuZCBz
b2x1dGlvbnMgaW4gdGhlIHNhbWUgZG9jLCBhbHNvIGNvbmNlcm5lZCBhYm91dCB3YWl0aW5nIHVu
dGlsIHdlIGhhdmUgYSBjb21wbGV0ZSByZXF1aXJlbWVudHMsIHdhbnRzIHRvIGtub3cgaWYgdGhl
IGdyb3VwIGhhcyBzb21lIGFncmVlbWVudCBvbiB0aGUgbWFpbiBwb2ludHMsIG5vdGVkIHRoYXQg
dGhlIHN1cGVydXNlciBpZGVhIGlzIGNvbnRlbnRpb3VzIGFyZSB3ZSBhZ3JlZWQgdGhhdCB0aGlz
IGlzIHRoZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHRvIHB1cnN1ZSwgc29tZSBhZ3JlZW1lbnQNCldl
cyBkaXNhZ3JlZXMuDQpXZXM6IEknZCBsaWtlIHRvIHNlZSB0aGUgYXV0aG9ycyBvZiBkaWZmZXJl
bnQgaW1wbGVtZW50YXRpb25zIHRvIGNvbWUgdG9nZXRoZXIgYW5kIGRpc2N1c3MgdGhlIHJpZ2h0
IHRoaW5nIHRvIGRvLiBJIGJlbGlldmUgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGFyZSBu
ZWVkZWQuDQpXZXMgLSBkb2VzbnQgd2FudCBhIDEgeWVhciBlZmZvcnQgZWl0aGVyLCB3YW50cyB0
aGUgbmV0Y29uZiBmb2xrcyB0byB3b3JrIHRvZ2V0aGVyIA0KV2VzIC0gd2Ugc2hvdWxkIHVuZGVy
dGFrZSB0aGUgZWZmb3J0DQpXRyBjaGFpciAtIHdvdWxkIGxpa2UgYW5vdGhlciBhdXRob3IgdG8g
d29yayBvbiB0aGVzZSB3aXRoIGhpbSBmb3IgYm90aCB0ZXN0aW5nIGFzIHdlbGwgaW1wbGVtZW50
YXRpb24NCm90aGVyIGNoYWlyIC0gc2hvdWxkIHRoZXJlIGJlIGEgc2VjdXJpdHkgY29tbWl0ZWU/
DQoNCkJlcnQ6IEFuZHkgaXMgc28gZmFyIHRoZSBvbmx5IGF1dGhvci4gV2UgbmVlZCBhdCBsZWFz
dCBhbm90aGVyIG9uZSBhcyBhIGNvLWVkaXRvci4gW01hcnRpbiB2b2x1bnRlZXJzLl0NCkRhbiAo
YXMgQUQpOiBTb21lIHRhbGtzIHdpdGggdGhlIHNlY3VyaXR5IGNvbW11bml0eSBtaWdodCBiZSBu
ZWVkZWQuDQpBbmR5OiBXZSBhcmUgdHJ5aW5nIHRvIGNvbWUgdXAgd2l0aCBzb21ldGhpbmcgaW1w
bGVtZW50YWJsZSwgaXQgbXkgbm90IGJlIHBlcmZlY3QuIHNvbXRoaW5nIGltcGxpY2l0IGluIHRo
ZSBkcmFmdCAtIHNvbWV0aGluZyBhY2hlaXZhYmxlIHRoYXQgbWF5IG5vdCBiZSBwZXJmZWN0LCB0
aGVyZSBpc250IGFueSBhYmlsaXR5IHRvIGNvbnRyb2wgYSB1c2VyICJ0byBzZXQgdGhlIGtub2Ig
dXAgYnV0IG5vdCBkb3duIg0KDQpCZXJ0OiBXZSBwcm9iYWJseSBkb24ndCBuZWVkIHRvIGNoYW5n
ZSB0aGUgY2hhcnRlciwgdGhlIFdHIGNoYWlycyB3aWxsIGNoZWNrLiBXZSBhbHNvIG5lZWQgdG8g
Zm9jdXMgb24gdGhlIHJlcXVpcmVtZW50cy4gc291bmRzIGxpa2Ugd2UgaGF2ZSBjb25zZW5zdXMg
dG8gcHJvY2VlZCANCmhhdmUgYW5keSBhbmQgbWFydGluIHRvIHdvcmsgb24gdGhlIGRvYywgY2Fu
IHdlIHRha2UgdGhpcyBkb2N1bWVudCBhcyBhIGJhc2UgZG9jPyB3aGVuIHdlIHN0YXJ0IG9mZiBk
byB0aGUgcmVxdWlyZW1lbnRzLCB3ZSBoYXZlIHNvbWUgaW1wbGVtZW50YXRpb24gKGNvdWxkIGJl
IGFuIGFwcGVuZGl4KSBvciByZW1vdmUgaXQgZm9yIG5vdywgd29yayB0aGlzIG91dCBpbiBtaWxl
c3RvbmVzDQoNCldlczogQSBjb21wZXRpbmcgcHJvcG9zYWxzIHNob3VsZG4ndCBiZSBwcmVjbHVk
ZWQuDQpCZXJ0OiBXZSdsbCBhc2sgaW4gdGhlIE1MLiBPdGhlciBwcm9wb3NhbHMgYXJlIGNlcnRh
aW5seSBwb3NzaWJsZSBidXQgSSBkb24ndCBzZWUgdGhlIG5lZWQgZm9yIHRoZW0uDQpXZXM6IEdp
dmUgb25lIHdlZWsgZm9yIGFsdGVybmF0aXZlIHByb3Bvc2Fscy4NCmRvZXNudCBsaWtlIHRoZSAi
ZHJhZnQgYnkgdGhlIElFVEYiIGhhcyBtb3JlIHBvd2VyICwgc3VnZ2VzdHMgYXNraW5nIGlzIHRo
ZXJlIGFueSBvdGhlciB3b3JrIHRoYXQgaXMgbmVlZGVkDQoNCldHIGNoYWlyIC0gY29uY2VybmVk
IHRoYXQgdGhlIHRpbWUgbG9zdCBmb3Igc29tZW9uZSB0byBkbyBhIG9wcG9zaW5nIHZpZXcgbWln
aHQgdGFrZSB0b28gbG9uZw0KV2VzIC0gaXMgY29uY2VybmVkIA0KQmVydDogRG8geW91IHN1cHBv
cnQgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgQUNNIHdvcms/IChI
dW1taW5nIGNvbnNlbnN1cy4pDQphc2tpbmcgZm9yIHByb3Bvc2VkIHRpbWUgZm9yIHlhbmcgbW9k
dWxlcyBldGMgb24gd2VkbmVzZGF5DQoNCkRhbiAoYXMgQUQpIG9mZmVycyB0aW1lIGluIE9QUyBh
cmVhIG1lZXRpbmcgZm9yIHByZXNlbnRpbmcgdGhlIE5FVENPTkYgaW1wbGVtZW50YXRpb24gd3Jp
dHRlbiBieSBSYXkgQXRhcmFzaGkuDQoNClNlc3Npb24gY2xvc2VkIGF0IDExOjMwLg0K

------_=_NextPart_001_01CAE070.A148EDF7--

From balazs.lengyel@ericsson.com  Tue Apr 20 07:36:47 2010
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050A73A693F for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 07:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4vKiAVGFJDM for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 07:36:37 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6D4173A6983 for <netconf@ietf.org>; Tue, 20 Apr 2010 07:34:55 -0700 (PDT)
X-AuditID: c1b4fb39-b7b85ae000005cbc-d4-4bcdbb85f8f5
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B0.26.23740.58BBDCB4; Tue, 20 Apr 2010 16:34:45 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 20 Apr 2010 16:34:45 +0200
Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 20 Apr 2010 16:34:44 +0200
Message-ID: <4BCDBB84.8000609@ericsson.com>
Date: Tue, 20 Apr 2010 16:34:44 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: netconf@ietf.org
References: <20100419124301.8FE2A3A6960@core3.amsl.com>
In-Reply-To: <20100419124301.8FE2A3A6960@core3.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Apr 2010 14:34:44.0929 (UTC) FILETIME=[9EE95B10:01CAE096]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Netconf] New Version Notification for draft-ietf-netconf-with-defaults-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 14:36:47 -0000

Hello Andy,
I have read,/checked the -07 version of the draft and I am happy with it.
Balazs

On 04/19/10 14:43, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-ietf-netconf-with-defaults-07.txt has been successfully submitted by Andy Bierman and posted to the IETF repository.
>
> Filename:	 draft-ietf-netconf-with-defaults
> Revision:	 07
> Title:		 With-defaults capability for NETCONF
> Creation_date:	 2010-04-19
> WG ID:		 netconf
> Number_of_pages: 21
>
> Abstract:
> The NETCONF protocol defines ways to read configuration data from a
> NETCONF server.  Part of this data is not set by the NETCONF client,
> but rather a default value is used.  In many situations the NETCONF
> client has a priori knowledge about default data, so the NETCONF
> server does not need to send it to the client.  In other situations
> the NETCONF client will need this data as part of the NETCONF<rpc-
> reply>  messages.  This document defines a capability-based extension
> to the NETCONF protocol that allows the NETCONF client to control
> whether default values are part of NETCONF<rpc-reply>  messages or
> <copy-config>  output to the target URL.
>
>
>
> The IETF Secretariat.
>
>
>    

From andyb@iwl.com  Tue Apr 20 10:05:58 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AB53A6A61 for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 10:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.129
X-Spam-Level: 
X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq+ifstHfPDV for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 10:05:56 -0700 (PDT)
Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 8DC213A6ACC for <netconf@ietf.org>; Tue, 20 Apr 2010 10:05:19 -0700 (PDT)
Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 7E5CB17FF7A; Tue, 20 Apr 2010 13:05:10 -0400 (EDT)
Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 38C2C17FF34;  Tue, 20 Apr 2010 13:05:10 -0400 (EDT)
Message-ID: <4BCDDF14.4040704@iwl.com>
Date: Tue, 20 Apr 2010 10:06:28 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
References: <20100419124301.8FE2A3A6960@core3.amsl.com> <4BCDBB84.8000609@ericsson.com>
In-Reply-To: <4BCDBB84.8000609@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] New Version Notification for draft-ietf-netconf-with-defaults-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 17:05:58 -0000

Balazs Lengyel wrote:
> Hello Andy,
> I have read,/checked the -07 version of the draft and I am happy with it.

thanks.

I hope all the other WG members will read it and send their
comments (good or bad) to the WG mailing list.
I would really like to move this to the 'done' box,
and get started on access control.

> Balazs

Andy


>
> On 04/19/10 14:43, IETF I-D Submission Tool wrote:
>> A new version of I-D, draft-ietf-netconf-with-defaults-07.txt has
>> been successfully submitted by Andy Bierman and posted to the IETF
>> repository.
>>
>> Filename:     draft-ietf-netconf-with-defaults
>> Revision:     07
>> Title:         With-defaults capability for NETCONF
>> Creation_date:     2010-04-19
>> WG ID:         netconf
>> Number_of_pages: 21
>>
>> Abstract:
>> The NETCONF protocol defines ways to read configuration data from a
>> NETCONF server.  Part of this data is not set by the NETCONF client,
>> but rather a default value is used.  In many situations the NETCONF
>> client has a priori knowledge about default data, so the NETCONF
>> server does not need to send it to the client.  In other situations
>> the NETCONF client will need this data as part of the NETCONF<rpc-
>> reply>  messages.  This document defines a capability-based extension
>> to the NETCONF protocol that allows the NETCONF client to control
>> whether default values are part of NETCONF<rpc-reply>  messages or
>> <copy-config>  output to the target URL.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>>    
>


From bertietf@bwijnen.net  Tue Apr 20 13:35:44 2010
Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FBD3A6B14 for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 13:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.264
X-Spam-Level: 
X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=0.706,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06PctAfR6W55 for <netconf@core3.amsl.com>; Tue, 20 Apr 2010 13:35:43 -0700 (PDT)
Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id E448E3A6BA8 for <netconf@ietf.org>; Tue, 20 Apr 2010 13:35:26 -0700 (PDT)
Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from <bertietf@bwijnen.net>) id 1O4KA8-0007GO-To for netconf@ietf.org; Tue, 20 Apr 2010 22:35:17 +0200
Message-ID: <B25253FC7A7F410CAC72BA9919FC5B83@BertLaptop>
From: "Bert Wijnen \(IETF\)" <bertietf@bwijnen.net>
To: "Netconf" <netconf@ietf.org>
Date: Tue, 20 Apr 2010 22:35:06 +0200
Organization: Consultant
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
Subject: [Netconf] Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 20:35:44 -0000

This email starts a formal WG Last Call for the
draft-ietf-netconf-with-defaults-07.txt document

The document is intended to be published as Proposed Standard.

WGLC ends on May 5th 2010 (any timezone).

Pls do review and send us your comments and feedback.
Also, if you see no problems with the document pls let us know.
A comment like:
      I read the document and am happy with it.
isusefull too.  It helps us determine how many people actually did review.

Thanks,
Bert and Mehmet (WG chairs)


----- Original Message ----- 
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: netconf@ietf.org
Sent: Monday, April 19, 2010 2:45 PM
Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-07.txt


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           : With-defaults capability for NETCONF
Author(s)       : A. Bierman, B. Lengyel
Filename        : draft-ietf-netconf-with-defaults-07.txt
Pages           : 21
Date            : 2010-04-19

The NETCONF protocol defines ways to read configuration data from a
NETCONF server.  Part of this data is not set by the NETCONF client,
but rather a default value is used.  In many situations the NETCONF
client has a priori knowledge about default data, so the NETCONF
server does not need to send it to the client.  In other situations
the NETCONF client will need this data as part of the NETCONF <rpc-
reply> messages.  This document defines a capability-based extension
to the NETCONF protocol that allows the NETCONF client to control
whether default values are part of NETCONF <rpc-reply> messages or
<copy-config> output to the target URL.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/ 


From tmikolajczyk@goahead.com  Mon Apr 26 06:23:50 2010
Return-Path: <tmikolajczyk@goahead.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2E128C164 for <netconf@core3.amsl.com>; Mon, 26 Apr 2010 06:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd1MkGkpASCz for <netconf@core3.amsl.com>; Mon, 26 Apr 2010 06:23:47 -0700 (PDT)
Received: from west.smtp.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by core3.amsl.com (Postfix) with ESMTP id 3050828C165 for <netconf@ietf.org>; Mon, 26 Apr 2010 06:21:50 -0700 (PDT)
Received: from [192.168.85.99] (78.8.254.195) by west.exch021.serverdata.net (10.254.4.40) with Microsoft SMTP Server (TLS) id 14.0.682.2; Mon, 26 Apr 2010 06:21:37 -0700
Message-ID: <4BD59338.5060607@goahead.com>
Date: Mon, 26 Apr 2010 15:20:56 +0200
From: Tomasz Mikolajczyk <tmikolajczyk@goahead.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "Bert (IETF) Wijnen" <bertietf@bwijnen.net>
References: <4BC6C8A2.1000307@bwijnen.net>
In-Reply-To: <4BC6C8A2.1000307@bwijnen.net>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Netconf Implementations - as reported on our netconf twiki page
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 13:23:51 -0000

Hi,

To answer your inline query at
http://trac.tools.ietf.org/wg/netconf/trac/wiki

embeddedMIND is now a GoAhead Software product.

Further information at:
http://goahead.com/products/embeddedmind/default.aspx

Regards,
Tomasz Mikolajczyk

On 04/15/2010 10:04 AM, Bert (IETF) Wijnen wrote:
>
> Dear WG participants, on our NETCONF TWIKI, we have various
> pointers to additional NetConf and YANG related materials.
> The page is at:
>
> http://trac.tools.ietf.org/wg/netconf/trac/wiki
>
> Over the years we (as current and past WG chairs) have collected
> information. However, you as the community need to help us to keep
> this up to date.
>
> Yesterday we got a report that various links were broken.
> We have fixed those that we could quickly track down.
>
> There are a few that we cannot (yet) track down.
> If you have pointers them, pls do let us know.
> If we cannot find the pointers in the next few weeks,
> we plan to disable the links... maybe even better to
> remove the item completely.
>
> Also it seems some companies have merged or been bought?
> So we appologize if the data is not 100% correct. It is
> only the owners of the pages that can keep us informed and
> up to date.
>
> Bert and Mehmet
>
> Below is a list of changes made and still open problems:
>
>> Regarding the Wiki:
>>
>> http://trac.tools.ietf.org/wg/netconf/trac/wiki
>>
>> I think it’s a great idea to have a list of tool vendors. Some changes
>> are recommended for this section of the Wiki:
>>
>> embeddedMIND™ <http://embeddedmind.com/mindagentnetconf> from
>> Silicon&Software Systems (S3) now has an extensible Netconf agent with
>> integrated configuration store and CLI, SNMP and Web interfaces.
>>
>> -> Looks like S3 was bought by GoAhead Software.
>>
> Fixed the ptr.
> Also added ??Now GoAhead?? Hope the owners can tell us more.
>>
>> XML Based Device Management
>> <http://www.wipro.com/webpages/prodesign/reusableframeworks/ip/xml.htm> by
>> Wipro, including an agent written in C and a manager in Java
>>
>> -> This URL doesn’t work anymore.
>>
> Can't find info for it anymore
>
>> Applied Informatics' C++-based NetConf implementation
>> <http://www.appinf.com/poco/wiki/tiki-index.php?page=NetConf> based on
>> the POCO framework ( Howto
>> <http://www.appinf.com/poco/wiki/tiki-index.php?page=NetConf>).
>>
>> -> This URL doesn’t work anymore.
>>
> Same
>
>> XMS (eXtensible Management System)
>> <http://www.6wind.com/Network.html>, written in C, by 6WIND
>>
>> -> This URL doesn’t work anymore.
>>
> Same
>
>> Another implementation written in C by
>> http://www.postech.ac.kr/Postech in Korea
>>
>> -> This URL doesn’t work anymore.
>>
> Same... but I may be able to track it down with a few emails in the next
> few days
>>
>> Also, the Ncclient module is now located at
>> http://oss.schmizz.net/ncclient/.
>>
>> · NANOG28 (June 2003): Panel on XML Router Configs - Progress and
>> Predictions <http://www.nanog.org/mtg-0306/xml.html>
>>
>> · NANOG28 (June 2003) BOF on XML-based Network Management Tools
>> <http://www.nanog.org/mtg-0306/enns.html>
>>
>> -> These links have moved as well.
>>
>
> fixed
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

From dromasca@avaya.com  Tue Apr 27 03:39:33 2010
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A6D28B56A for <netconf@core3.amsl.com>; Tue, 27 Apr 2010 03:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.904
X-Spam-Level: 
X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XX2aToPFy01 for <netconf@core3.amsl.com>; Tue, 27 Apr 2010 03:39:32 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9A15728C103 for <netconf@ietf.org>; Tue, 27 Apr 2010 03:39:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="13338119"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 27 Apr 2010 06:39:16 -0400
X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="468085518"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2010 06:39:13 -0400
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
Date: Tue, 27 Apr 2010 12:39:05 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD review of draft-ietf-netconf-monitoring-12
Thread-Index: Acrl9dvJsQI2CMfTTM+HV6OHQFKwOw==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <netconf@ietf.org>
Subject: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 10:39:33 -0000

Please find below the AD review of draft-ietf-netconf-monitoring-12.
This document is ready for IETF Last Call and the issues and questions
raised below can be solved together with the other IETF Last Call
comments.=20

Technical=20

T1:=20
username (string)
     If present, the username contains an identifier which can be
     used to uniquely identify an individual client (human or
     machine).

Why 'if present'? Are there situations where the server does not know
the unique identity of the client?=20

T2:=20
   =20
 If requested schema is not unique, the <error-tag> is
     'operation-failed', and <error-app-tag> is 'data-not-unique'.


What does 'if requested schema is not unique' mean - that the version
parameter is not included in the request, and there are more than one
version available? Are there other cases?=20

T3. The Security Considerations section will need to be replaced with
text that conforms to the guidelines for SC sections in YANG modules
documents which - hopefully - will be approved by the time of
publication of this document. In the meantime it would not harm to
re-write this section in the next revision of the I-D according go the
latest proposal on this respect (would be a good opportunity to verify
the guidelines with 'running code'.=20


Editorial

E1: ADs commenting on other NETMOD and NETCONF documents consider
NETCONF as acronyms that need to be expanded at first occurrence.=20

E2. copyright year in the YANG module should be changes to 2010.=20

E3. in the description of netconf-soap-ver-beep and
netconf-soap-over-https I think the more correct and complete
description is 'NETCONF over SOAP over BEEP' and 'NETCONF over SOAP over
HTTPS' and not 'NETCONF SOAP ....'

E4. description of yang and yin - no need for 'YANG is a ...' 'YIN is an
...'=20


Thanks and Regards,

Dan


From mbj@tail-f.com  Wed Apr 28 03:56:47 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054793A69EC for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 03:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbRK+1Ex9-t1 for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 03:56:46 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 938253A67B7 for <netconf@ietf.org>; Wed, 28 Apr 2010 03:56:41 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F74A616004; Wed, 28 Apr 2010 12:56:27 +0200 (CEST)
Date: Wed, 28 Apr 2010 12:56:26 +0200 (CEST)
Message-Id: <20100428.125626.169114362.mbj@tail-f.com>
To: dromasca@avaya.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 10:56:47 -0000

Hi,

My comments inline.

"Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> 
> Please find below the AD review of draft-ietf-netconf-monitoring-12.
> This document is ready for IETF Last Call and the issues and questions
> raised below can be solved together with the other IETF Last Call
> comments. 
> 
> Technical 
> 
> T1: 
> username (string)
>      If present, the username contains an identifier which can be
>      used to uniquely identify an individual client (human or
>      machine).
> 
> Why 'if present'? Are there situations where the server does not know
> the unique identity of the client? 

RFC 5539 (NETCONF over TLS) does not specify how to derive a username.
But maybe the intention of 5539 is that implementations will derive a
user name (in a non-standardized way)?  If so, I agree we should
remove the 'if present' text.

> T2: 
>     
>  If requested schema is not unique, the <error-tag> is
>      'operation-failed', and <error-app-tag> is 'data-not-unique'.
> 
> 
> What does 'if requested schema is not unique' mean - that the version
> parameter is not included in the request, and there are more than one
> version available? Are there other cases? 

If the device has multiple revisions and or multiple formats
available, and no revision or format parameter is specified, this
error will occur.   In the YANG model this is described as:

   If more than one schema matches the requested parameters, the
   <error-tag> is 'operation-failed', and <error-app-tag> is
  'data-not-unique'.";

which maybe is better.

> T3. The Security Considerations section will need to be replaced with
> text that conforms to the guidelines for SC sections in YANG modules
> documents which - hopefully - will be approved by the time of
> publication of this document. In the meantime it would not harm to
> re-write this section in the next revision of the I-D according go the
> latest proposal on this respect (would be a good opportunity to verify
> the guidelines with 'running code'. 

Ok.

> Editorial
> 
> E1: ADs commenting on other NETMOD and NETCONF documents consider
> NETCONF as acronyms that need to be expanded at first occurrence. 

Ok.

> E2. copyright year in the YANG module should be changes to 2010. 

Ok.

> E3. in the description of netconf-soap-ver-beep and
> netconf-soap-over-https I think the more correct and complete
> description is 'NETCONF over SOAP over BEEP' and 'NETCONF over SOAP over
> HTTPS' and not 'NETCONF SOAP ....'

Ok.

> E4. description of yang and yin - no need for 'YANG is a ...' 'YIN is an
> ...' 

How about:

  identity yang {
    base schema-format;
    description
      "The YANG data modeling language for NETCONF";
    reference
      "RFC XXXX:  YANG - A data modeling language for NETCONF";
  }

  identity yin {
    base schema-format;
    reference
      "The YIN syntax for YANG.";
    reference
      "RFC XXXX:  YANG - A data modeling language for NETCONF";
   // RFC Ed.: replace XXXX with actual RFC number and remove this note
  }


/martin

From dromasca@avaya.com  Wed Apr 28 04:06:28 2010
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E7F3A6AAB for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 04:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgUoI19qeJEj for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 04:06:27 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 7AABC3A6AF7 for <netconf@ietf.org>; Wed, 28 Apr 2010 04:06:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="13526702"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 Apr 2010 07:06:13 -0400
X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="455707281"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Apr 2010 07:05:37 -0400
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
Date: Wed, 28 Apr 2010 13:05:16 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com>
In-Reply-To: <20100428.125626.169114362.mbj@tail-f.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: AcrmwXVJMmTwEe4JQqu+z7ue4HbBxAAAE8WA
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com> <20100428.125626.169114362.mbj@tail-f.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Martin Bjorklund" <mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 11:06:28 -0000

Thanks for the fast response. See in-line a few responses.

I suggest that you do not update the document now, but we rather send it
to IETF LC and consider these comments together with the other IETF LC
comments. Mehmet (as document shepherd) - are you OK with this?=20

Dan
 =20

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
> Sent: Wednesday, April 28, 2010 1:56 PM
> To: Romascanu, Dan (Dan)
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>=20
> Hi,
>=20
> My comments inline.
>=20
> "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> >=20
> > Please find below the AD review of draft-ietf-netconf-monitoring-12.
> > This document is ready for IETF Last Call and the issues=20
> and questions=20
> > raised below can be solved together with the other IETF Last Call=20
> > comments.
> >=20
> > Technical
> >=20
> > T1:=20
> > username (string)
> >      If present, the username contains an identifier which can be
> >      used to uniquely identify an individual client (human or
> >      machine).
> >=20
> > Why 'if present'? Are there situations where the server=20
> does not know=20
> > the unique identity of the client?
>=20
> RFC 5539 (NETCONF over TLS) does not specify how to derive a username.
> But maybe the intention of 5539 is that implementations will=20
> derive a user name (in a non-standardized way)?  If so, I=20
> agree we should remove the 'if present' text.

I do not know whether we need a standard, but if the user name is always
known than 'if present' is not needed.=20

>=20
> > T2:=20
> >    =20
> >  If requested schema is not unique, the <error-tag> is
> >      'operation-failed', and <error-app-tag> is 'data-not-unique'.
> >=20
> >=20
> > What does 'if requested schema is not unique' mean - that=20
> the version=20
> > parameter is not included in the request, and there are=20
> more than one=20
> > version available? Are there other cases?
>=20
> If the device has multiple revisions and or multiple formats=20
> available, and no revision or format parameter is specified, this
> error will occur.   In the YANG model this is described as:
>=20
>    If more than one schema matches the requested parameters, the
>    <error-tag> is 'operation-failed', and <error-app-tag> is
>   'data-not-unique'.";
>=20
> which maybe is better.

I agree the text in the YANG model is better. 'unique' sounds odd here.=20

>=20
> > T3. The Security Considerations section will need to be=20
> replaced with=20
> > text that conforms to the guidelines for SC sections in=20
> YANG modules=20
> > documents which - hopefully - will be approved by the time of=20
> > publication of this document. In the meantime it would not harm to=20
> > re-write this section in the next revision of the I-D=20
> according go the=20
> > latest proposal on this respect (would be a good=20
> opportunity to verify=20
> > the guidelines with 'running code'.
>=20
> Ok.
>=20
> > Editorial
> >=20
> > E1: ADs commenting on other NETMOD and NETCONF documents consider=20
> > NETCONF as acronyms that need to be expanded at first occurrence.
>=20
> Ok.
>=20
> > E2. copyright year in the YANG module should be changes to 2010.=20
>=20
> Ok.
>=20
> > E3. in the description of netconf-soap-ver-beep and=20
> > netconf-soap-over-https I think the more correct and complete=20
> > description is 'NETCONF over SOAP over BEEP' and 'NETCONF over SOAP=20
> > over HTTPS' and not 'NETCONF SOAP ....'
>=20
> Ok.
>=20
> > E4. description of yang and yin - no need for 'YANG is a=20
> ...' 'YIN is=20
> > an ...'
>=20
> How about:
>=20
>   identity yang {
>     base schema-format;
>     description
>       "The YANG data modeling language for NETCONF";
>     reference
>       "RFC XXXX:  YANG - A data modeling language for NETCONF";
>   }
>=20
>   identity yin {
>     base schema-format;
>     reference
>       "The YIN syntax for YANG.";
>     reference
>       "RFC XXXX:  YANG - A data modeling language for NETCONF";
>    // RFC Ed.: replace XXXX with actual RFC number and remove=20
> this note
>   }
>=20

OK.=20

>=20
> /martin
>=20

From mehmet.ersue@nsn.com  Wed Apr 28 04:24:57 2010
Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CBD3A6BA2 for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 04:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level: 
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=0.265,  BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP8U+9Vh1AjQ for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 04:24:56 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2BAF73A6BA5 for <netconf@ietf.org>; Wed, 28 Apr 2010 04:23:41 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3SBNNUB017242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Apr 2010 13:23:23 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3SBNNPT032440; Wed, 28 Apr 2010 13:23:23 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 13:23:22 +0200
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
Date: Wed, 28 Apr 2010 13:23:22 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: AcrmwXVJMmTwEe4JQqu+z7ue4HbBxAAAE8WAAABMZmA=
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com> <EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com>
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Martin Bjorklund" <mbj@tail-f.com>
X-OriginalArrivalTime: 28 Apr 2010 11:23:22.0886 (UTC) FILETIME=[3662A260:01CAE6C5]
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 11:24:58 -0000

Hi Dan,

yes. We can submit an update later together with other fixes.

Cheers,
Mehmet

=20

> -----Original Message-----
> From: netconf-bounces@ietf.org=20
> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20
> Dan (Dan)
> Sent: Wednesday, April 28, 2010 1:05 PM
> To: Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>=20
> Thanks for the fast response. See in-line a few responses.
>=20
> I suggest that you do not update the document now, but we=20
> rather send it
> to IETF LC and consider these comments together with the other IETF LC
> comments. Mehmet (as document shepherd) - are you OK with this?=20
>=20
> Dan
>  =20
>=20
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
> > Sent: Wednesday, April 28, 2010 1:56 PM
> > To: Romascanu, Dan (Dan)
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
> >=20
> > Hi,
> >=20
> > My comments inline.
> >=20
> > "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> > >=20
> > > Please find below the AD review of=20
> draft-ietf-netconf-monitoring-12.
> > > This document is ready for IETF Last Call and the issues=20
> > and questions=20
> > > raised below can be solved together with the other IETF Last Call=20
> > > comments.
> > >=20
> > > Technical
> > >=20
> > > T1:=20
> > > username (string)
> > >      If present, the username contains an identifier which can be
> > >      used to uniquely identify an individual client (human or
> > >      machine).
> > >=20
> > > Why 'if present'? Are there situations where the server=20
> > does not know=20
> > > the unique identity of the client?
> >=20
> > RFC 5539 (NETCONF over TLS) does not specify how to derive=20
> a username.
> > But maybe the intention of 5539 is that implementations will=20
> > derive a user name (in a non-standardized way)?  If so, I=20
> > agree we should remove the 'if present' text.
>=20
> I do not know whether we need a standard, but if the user=20
> name is always
> known than 'if present' is not needed.=20
>
>=20
> >=20
> > > T2:=20
> > >    =20
> > >  If requested schema is not unique, the <error-tag> is
> > >      'operation-failed', and <error-app-tag> is 'data-not-unique'.
> > >=20
> > >=20
> > > What does 'if requested schema is not unique' mean - that=20
> > the version=20
> > > parameter is not included in the request, and there are=20
> > more than one=20
> > > version available? Are there other cases?
> >=20
> > If the device has multiple revisions and or multiple formats=20
> > available, and no revision or format parameter is specified, this
> > error will occur.   In the YANG model this is described as:
> >=20
> >    If more than one schema matches the requested parameters, the
> >    <error-tag> is 'operation-failed', and <error-app-tag> is
> >   'data-not-unique'.";
> >=20
> > which maybe is better.
>=20
> I agree the text in the YANG model is better. 'unique' sounds=20
> odd here.=20
>=20
> >=20
> > > T3. The Security Considerations section will need to be=20
> > replaced with=20
> > > text that conforms to the guidelines for SC sections in=20
> > YANG modules=20
> > > documents which - hopefully - will be approved by the time of=20
> > > publication of this document. In the meantime it would=20
> not harm to=20
> > > re-write this section in the next revision of the I-D=20
> > according go the=20
> > > latest proposal on this respect (would be a good=20
> > opportunity to verify=20
> > > the guidelines with 'running code'.
> >=20
> > Ok.
> >=20
> > > Editorial
> > >=20
> > > E1: ADs commenting on other NETMOD and NETCONF documents consider=20
> > > NETCONF as acronyms that need to be expanded at first occurrence.
> >=20
> > Ok.
> >=20
> > > E2. copyright year in the YANG module should be changes to 2010.=20
> >=20
> > Ok.
> >=20
> > > E3. in the description of netconf-soap-ver-beep and=20
> > > netconf-soap-over-https I think the more correct and complete=20
> > > description is 'NETCONF over SOAP over BEEP' and 'NETCONF=20
> over SOAP=20
> > > over HTTPS' and not 'NETCONF SOAP ....'
> >=20
> > Ok.
> >=20
> > > E4. description of yang and yin - no need for 'YANG is a=20
> > ...' 'YIN is=20
> > > an ...'
> >=20
> > How about:
> >=20
> >   identity yang {
> >     base schema-format;
> >     description
> >       "The YANG data modeling language for NETCONF";
> >     reference
> >       "RFC XXXX:  YANG - A data modeling language for NETCONF";
> >   }
> >=20
> >   identity yin {
> >     base schema-format;
> >     reference
> >       "The YIN syntax for YANG.";
> >     reference
> >       "RFC XXXX:  YANG - A data modeling language for NETCONF";
> >    // RFC Ed.: replace XXXX with actual RFC number and remove=20
> > this note
> >   }
> >=20
>=20
> OK.=20
>=20
> >=20
> > /martin
> >=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20

From wwwrun@core3.amsl.com  Wed Apr 28 07:35:46 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 6E9863A6A66; Wed, 28 Apr 2010 07:35:46 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20100428143546.6E9863A6A66@core3.amsl.com>
Date: Wed, 28 Apr 2010 07:35:46 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] Last Call: draft-ietf-netconf-monitoring (YANG Module for NETCONF Monitoring) to Proposed Standard
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 14:35:46 -0000

The IESG has received a request from the Network Configuration WG 
(netconf) to consider the following document:

- 'YANG Module for NETCONF Monitoring '
   <draft-ietf-netconf-monitoring-12.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-05-12. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-12.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16856&rfc_flag=0


From mark.scott@ericsson.com  Wed Apr 28 08:10:50 2010
Return-Path: <mark.scott@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF4F28C15A for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 08:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiaQAfHgtyjf for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 08:10:49 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id EFA1C28C1A6 for <netconf@ietf.org>; Wed, 28 Apr 2010 08:06:33 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3SF6HBR016947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Apr 2010 10:06:17 -0500
Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 28 Apr 2010 11:06:17 -0400
From: Mark Scott <mark.scott@ericsson.com>
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>, Martin Bjorklund <mbj@tail-f.com>
Date: Wed, 28 Apr 2010 11:06:15 -0400
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: AcrmwXVJMmTwEe4JQqu+z7ue4HbBxAAAE8WAAABMZmAAB0ijIA==
Message-ID: <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com> <EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 15:10:51 -0000

Hi Dan,

The 'if present' for the username node covers cases where there may not be =
a specific 'username' for the session (as Martin noted below), but also cas=
es where the server may choose to specifically omit this from the response.=
  E.g. user specific data may be considered sensitive in some implementatio=
ns and access to it may be more restricted than the other session details.

In addition to the changes agreed below we will also:
  - fix the double reference (in the yin identity) in the yang module.
  - include the new security text in the RFC body

Mark

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf =
Of Ersue, Mehmet (NSN - DE/Munich)
Sent: April-28-10 7:23 AM
To: ext Romascanu, Dan (Dan); Martin Bjorklund
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12


Hi Dan,

yes. We can submit an update later together with other fixes.

Cheers,
Mehmet

=20

> -----Original Message-----
> From: netconf-bounces@ietf.org=20
> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20
> Dan (Dan)
> Sent: Wednesday, April 28, 2010 1:05 PM
> To: Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>=20
> Thanks for the fast response. See in-line a few responses.
>=20
> I suggest that you do not update the document now, but we=20
> rather send it
> to IETF LC and consider these comments together with the other IETF LC
> comments. Mehmet (as document shepherd) - are you OK with this?=20
>=20
> Dan
>  =20
>=20
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
> > Sent: Wednesday, April 28, 2010 1:56 PM
> > To: Romascanu, Dan (Dan)
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
> >=20
> > Hi,
> >=20
> > My comments inline.
> >=20
> > "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> > >=20
> > > Please find below the AD review of=20
> draft-ietf-netconf-monitoring-12.
> > > This document is ready for IETF Last Call and the issues=20
> > and questions=20
> > > raised below can be solved together with the other IETF Last Call=20
> > > comments.
> > >=20
> > > Technical
> > >=20
> > > T1:=20
> > > username (string)
> > >      If present, the username contains an identifier which can be
> > >      used to uniquely identify an individual client (human or
> > >      machine).
> > >=20
> > > Why 'if present'? Are there situations where the server=20
> > does not know=20
> > > the unique identity of the client?
> >=20
> > RFC 5539 (NETCONF over TLS) does not specify how to derive=20
> a username.
> > But maybe the intention of 5539 is that implementations will=20
> > derive a user name (in a non-standardized way)?  If so, I=20
> > agree we should remove the 'if present' text.
>=20
> I do not know whether we need a standard, but if the user=20
> name is always
> known than 'if present' is not needed.=20
>
>=20
> >=20
> > > T2:=20
> > >    =20
> > >  If requested schema is not unique, the <error-tag> is
> > >      'operation-failed', and <error-app-tag> is 'data-not-unique'.
> > >=20
> > >=20
> > > What does 'if requested schema is not unique' mean - that=20
> > the version=20
> > > parameter is not included in the request, and there are=20
> > more than one=20
> > > version available? Are there other cases?
> >=20
> > If the device has multiple revisions and or multiple formats=20
> > available, and no revision or format parameter is specified, this
> > error will occur.   In the YANG model this is described as:
> >=20
> >    If more than one schema matches the requested parameters, the
> >    <error-tag> is 'operation-failed', and <error-app-tag> is
> >   'data-not-unique'.";
> >=20
> > which maybe is better.
>=20
> I agree the text in the YANG model is better. 'unique' sounds=20
> odd here.=20
>=20
> >=20
> > > T3. The Security Considerations section will need to be=20
> > replaced with=20
> > > text that conforms to the guidelines for SC sections in=20
> > YANG modules=20
> > > documents which - hopefully - will be approved by the time of=20
> > > publication of this document. In the meantime it would=20
> not harm to=20
> > > re-write this section in the next revision of the I-D=20
> > according go the=20
> > > latest proposal on this respect (would be a good=20
> > opportunity to verify=20
> > > the guidelines with 'running code'.
> >=20
> > Ok.
> >=20
> > > Editorial
> > >=20
> > > E1: ADs commenting on other NETMOD and NETCONF documents consider=20
> > > NETCONF as acronyms that need to be expanded at first occurrence.
> >=20
> > Ok.
> >=20
> > > E2. copyright year in the YANG module should be changes to 2010.=20
> >=20
> > Ok.
> >=20
> > > E3. in the description of netconf-soap-ver-beep and=20
> > > netconf-soap-over-https I think the more correct and complete=20
> > > description is 'NETCONF over SOAP over BEEP' and 'NETCONF=20
> over SOAP=20
> > > over HTTPS' and not 'NETCONF SOAP ....'
> >=20
> > Ok.
> >=20
> > > E4. description of yang and yin - no need for 'YANG is a=20
> > ...' 'YIN is=20
> > > an ...'
> >=20
> > How about:
> >=20
> >   identity yang {
> >     base schema-format;
> >     description
> >       "The YANG data modeling language for NETCONF";
> >     reference
> >       "RFC XXXX:  YANG - A data modeling language for NETCONF";
> >   }
> >=20
> >   identity yin {
> >     base schema-format;
> >     reference
> >       "The YIN syntax for YANG.";
> >     reference
> >       "RFC XXXX:  YANG - A data modeling language for NETCONF";
> >    // RFC Ed.: replace XXXX with actual RFC number and remove=20
> > this note
> >   }
> >=20
>=20
> OK.=20
>=20
> >=20
> > /martin
> >=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

From mehmet.ersue@nsn.com  Wed Apr 28 08:44:15 2010
Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1A028C0E3 for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 08:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.966,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f+HGwkQnOsl for <netconf@core3.amsl.com>; Wed, 28 Apr 2010 08:44:15 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 57C053A697C for <netconf@ietf.org>; Wed, 28 Apr 2010 08:43:40 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3SFhQAd025625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <netconf@ietf.org>; Wed, 28 Apr 2010 17:43:26 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3SFhQuC012717 for <netconf@ietf.org>; Wed, 28 Apr 2010 17:43:26 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 28 Apr 2010 17:43:26 +0200
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
Date: Wed, 28 Apr 2010 17:43:24 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A647A23A4@DEMUEXC006.nsn-intra.net>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6473A981@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] Draft IETF 77 NETCONF Session Minutes
Thread-Index: AcrgcKDgq8Afq5/AQWWd+khj7jagzwGeNPZw
References: <80A0822C5E9A4440A5117C2F4CD36A6473A981@DEMUEXC006.nsn-intra.net>
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "NETCONF WG" <netconf@ietf.org>
X-OriginalArrivalTime: 28 Apr 2010 15:43:26.0395 (UTC) FILETIME=[8ACD28B0:01CAE6E9]
Subject: Re: [Netconf] Draft IETF 77 NETCONF Session Minutes
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 15:44:15 -0000

Hi All,

I uploaded the minutes to the meeting material site:
http://www.ietf.org/proceedings/10mar/minutes/netconf.txt

Mehmet

=20

> -----Original Message-----
> From: netconf-bounces@ietf.org=20
> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue,=20
> Mehmet (NSN - DE/Munich)
> Sent: Tuesday, April 20, 2010 12:03 PM
> To: NETCONF WG
> Subject: [Netconf] Draft IETF 77 NETCONF Session Minutes
>=20
>=20
> Dear NETCONF WG,
>=20
> please comment on the draft IETF 77 NETCONF session=20
> minutes by April 27, 2010. Thank you.
>=20
>  <<100420_Merged_77_NETCONF_Minutes_.txt>>=20
>=20
> Mehmet
>=20
>=20
>=20

From dromasca@avaya.com  Thu Apr 29 00:52:48 2010
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E57828C1BA for <netconf@core3.amsl.com>; Thu, 29 Apr 2010 00:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.885
X-Spam-Level: 
X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-Fova8cTTjO for <netconf@core3.amsl.com>; Thu, 29 Apr 2010 00:52:47 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id EA3ED3A6BB5 for <netconf@ietf.org>; Thu, 29 Apr 2010 00:52:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,294,1270440000"; d="scan'208";a="13678645"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 29 Apr 2010 03:52:19 -0400
X-IronPort-AV: E=Sophos;i="4.52,294,1270440000"; d="scan'208";a="468800013"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Apr 2010 03:52:18 -0400
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
Date: Thu, 29 Apr 2010 09:51:56 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com>
In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: AcrmwXVJMmTwEe4JQqu+z7ue4HbBxAAAE8WAAABMZmAAB0ijIAAkCpuQ
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com><EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net> <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Mark Scott" <mark.scott@ericsson.com>, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, "Martin Bjorklund" <mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2010 07:52:48 -0000

=20

> -----Original Message-----
> From: Mark Scott [mailto:mark.scott@ericsson.com]=20
> Sent: Wednesday, April 28, 2010 6:06 PM
> To: Ersue, Mehmet (NSN - DE/Munich); Romascanu, Dan (Dan);=20
> Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>=20
> Hi Dan,
>=20
> The 'if present' for the username node covers cases where=20
> there may not be a specific 'username' for the session (as=20
> Martin noted below), but also cases where the server may=20
> choose to specifically omit this from the response.  E.g.=20
> user specific data may be considered sensitive in some=20
> implementations and access to it may be more restricted than=20
> the other session details.
>=20

This later seems to me a different case than 'if present'. The
information exists but is considered security-sensitive. I also do not
think that it is an implementation-specific issue, but a
deployment-specific issue. How does the server 'choose' to omit the user
name from a response? Is this a global (per server) decision or a per
user decision?=20

Dan


From andyb@iwl.com  Thu Apr 29 19:26:00 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC893A68DF for <netconf@core3.amsl.com>; Thu, 29 Apr 2010 19:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.068
X-Spam-Level: 
X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae6q5-dqhF+Q for <netconf@core3.amsl.com>; Thu, 29 Apr 2010 19:25:57 -0700 (PDT)
Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 377373A67A4 for <netconf@ietf.org>; Thu, 29 Apr 2010 19:25:57 -0700 (PDT)
Received: from relay1.r1.iad.emailsrvr.com (localhost [127.0.0.1]) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 78D0544C02B for <netconf@ietf.org>; Thu, 29 Apr 2010 22:25:43 -0400 (EDT)
Received: by relay1.r1.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 438C244C098 for <netconf@ietf.org>; Thu, 29 Apr 2010 22:25:42 -0400 (EDT)
Message-ID: <4BDA3FA5.4020306@iwl.com>
Date: Thu, 29 Apr 2010 19:25:41 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 02:26:01 -0000

Hi,

Here are more issues for 4741bis:

1) :url as a source for <edit-config>
   (Martin already raised this issue)

         choice edit-content {
           mandatory true;
           anyxml config {
             description
               "Inline Config content: 'config' element.
                This is not full 'anyxml' because the <config>
                element cannot directly contain a text node.";
           }
           leaf url {
             if-feature url;
             type inet:uri;
           }
         }

   The edit-config operation allows <url> as a source,
   but there is no explanation what the file has to contain.
   Does it even have to be XML?

   There is no <get-config> support for a URL database,
   so why should there be any partial database editing?
   Since the URL file always represents a complete database,
   there are no operations other than copy-config and delete-config
   that apply to it.

   Proposed solution:
     - Delete 'url' as a source for <edit-config>
     - Delete section 8.8.5.1.


2) There is no lock support at all for URL databases, so it is 
   not even clear that copy and delete are properly supported.

   Issue: Should <url> be allowed in <lock> and <unlock>
   operations?

3) :url interoperability

   It is not clear what a client application should expect
   for any given scheme, or what schemes a server SHOULD
   or even MAY support.

   Issue: is the :url capability interoperable?
   If not, what should be done about it?

4) :url security considerations

   The security considerations for external database representations
   of NETCONF configurations are ignored, which should probably be
   fixed, if anybody knows what to write.

   Current text:

       Similarly, just because someone says "go write a configuration
       through the URL capability at a particular place", this does not mean
       that an element should do it without proper authorization.

   Issue:  Are the security considerations clear enough or are
   more details needed?  (e.g., file system permissions for 'file' scheme,
   clear-text on-the-wire for 'ftp' and 'http' schemes.

5) 'file' scheme

   It is not clear whether:
     - absolute path specs must be supported by the server
     - the path-spec represents a conceptual file-system in 
       the server, or the real file-system.
     - sub-directories must be supported
     - how many sub-directory levels deep are allowed
     - other restrictions apply, such as naming, number of files, etc.
     - if the internal mirrored NV-store is really a file,
       whether this file is accessible via the <url> parameter.
     - if the external :startup config is accessible via the <url> 
       parameter.

   Issue: are any guidelines needed for the 'file' scheme?
   This is the most likely scheme to be supported by a server.



Andy



From mbj@tail-f.com  Fri Apr 30 03:36:16 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED4D3A6B31 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 03:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.058
X-Spam-Level: 
X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.496,  BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7CaExwk869c for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 03:36:15 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 278733A68E8 for <netconf@ietf.org>; Fri, 30 Apr 2010 03:36:14 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B17C616001; Fri, 30 Apr 2010 12:36:00 +0200 (CEST)
Date: Fri, 30 Apr 2010 12:35:59 +0200 (CEST)
Message-Id: <20100430.123559.164315822.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BDA3FA5.4020306@iwl.com>
References: <4BDA3FA5.4020306@iwl.com>
X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 10:36:16 -0000

Hi,

Andy Bierman <andyb@iwl.com> wrote:
> Hi,
> 
> Here are more issues for 4741bis:
> 
> 1) :url as a source for <edit-config>
>    (Martin already raised this issue)
> 
>          choice edit-content {
>            mandatory true;
>            anyxml config {
>              description
>                "Inline Config content: 'config' element.
>                 This is not full 'anyxml' because the <config>
>                 element cannot directly contain a text node.";
>            }
>            leaf url {
>              if-feature url;
>              type inet:uri;
>            }
>          }
> 
>    The edit-config operation allows <url> as a source,
>    but there is no explanation what the file has to contain.
>    Does it even have to be XML?
> 
>    There is no <get-config> support for a URL database,
>    so why should there be any partial database editing?

But this is url as *source*, not target.  url as target is not
supported by 4741 (actually, it is allowed by the XSD, but not
according to the text).

>    Since the URL file always represents a complete database,
>    there are no operations other than copy-config and delete-config
>    that apply to it.
> 
>    Proposed solution:
>      - Delete 'url' as a source for <edit-config>
>      - Delete section 8.8.5.1.

I agree.  Also, Appendix D must be rewritten.

> 2) There is no lock support at all for URL databases, so it is 
>    not even clear that copy and delete are properly supported.
> 
>    Issue: Should <url> be allowed in <lock> and <unlock>
>    operations?

No.

> 3) :url interoperability
> 
>    It is not clear what a client application should expect
>    for any given scheme, or what schemes a server SHOULD
>    or even MAY support.
> 
>    Issue: is the :url capability interoperable?
>    If not, what should be done about it?

I don't know if it is interoperable, but it does make sense to list
the schemes we expect implementations to support, and for each scheme,
specify how it should be supported.

> 4) :url security considerations
> 
>    The security considerations for external database representations
>    of NETCONF configurations are ignored, which should probably be
>    fixed, if anybody knows what to write.
> 
>    Current text:
> 
>        Similarly, just because someone says "go write a configuration
>        through the URL capability at a particular place", this does not mean
>        that an element should do it without proper authorization.
> 
>    Issue:  Are the security considerations clear enough or are
>    more details needed?  (e.g., file system permissions for 'file' scheme,
>    clear-text on-the-wire for 'ftp' and 'http' schemes.

It is probably a good idea to point out the clear-text on-the-wire
issue.

> 5) 'file' scheme
> 
>    It is not clear whether:
>      - absolute path specs must be supported by the server

This could be clarified.

>      - the path-spec represents a conceptual file-system in 
>        the server, or the real file-system.

An implementation detail IMO.

>      - sub-directories must be supported

No MUST.

>      - how many sub-directory levels deep are allowed

No requirements.

>      - other restrictions apply, such as naming, number of files, etc.

Implementation issue. e.g. filesystem dependent.

>      - if the internal mirrored NV-store is really a file,
>        whether this file is accessible via the <url> parameter.

Implementation issue.

>      - if the external :startup config is accessible via the <url> 
>        parameter.

Implementation issue.

We keep track of 'rollback files', which can be accessed using this
parameter.  We also have a proprietary data model to list the files
available.

>    Issue: are any guidelines needed for the 'file' scheme?
>    This is the most likely scheme to be supported by a server.

Yes, I think this is a good idea.


/martin

From mark.scott@ericsson.com  Fri Apr 30 06:52:07 2010
Return-Path: <mark.scott@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53A53A6BBB for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 06:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnGFoUhrDzSr for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 06:52:06 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 7F8F63A6B6E for <netconf@ietf.org>; Fri, 30 Apr 2010 06:52:06 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3UDpmPv022047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Apr 2010 08:51:49 -0500
Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 30 Apr 2010 09:51:47 -0400
From: Mark Scott <mark.scott@ericsson.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, Martin Bjorklund <mbj@tail-f.com>
Date: Fri, 30 Apr 2010 09:51:46 -0400
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: AcrmwXVJMmTwEe4JQqu+z7ue4HbBxAAAE8WAAABMZmAAB0ijIAAkCpuQADzaXdA=
Message-ID: <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com><EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net> <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se> <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 13:52:07 -0000

Dan,

In one of our previous implementations only users whose privilege level inc=
luded 'security admin' were allowed to see user specific data in any respon=
ses.  Such privileges were configured per user (i.e. per customer deploymen=
t) but the set of sensitive data was fixed on the server (i.e. per our serv=
er implementation).

In this case we consciously chose not to use any of the existing errors to =
indicate partial operation or partial data.  This was on advice of our secu=
rity primes who felt that indicating partial data invites further attempts =
to access it.
	- clearly this implementation was not 4741 compliant so I'm not proposing =
the above behaviour as standard but I assume others have dealt with such ca=
ses similarly

In terms of clarifying this in the monitoring draft:

I agree the term 'if present' isn't clear.

How about:  'if the session is authorized to access such data the username =
will be in the reply.  If not this data must be omitted from the response.'=
?

When adding the new yang module security template I can also specifically l=
ist the 'username' as potentially sensitive read-only data. =20

The template already contains multiple 'may be considered sensitive' clause=
s which reflect the points above.

Mark


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
Sent: April-29-10 3:52 AM
To: Mark Scott; Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund
Cc: netconf@ietf.org
Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12

=20

> -----Original Message-----
> From: Mark Scott [mailto:mark.scott@ericsson.com]=20
> Sent: Wednesday, April 28, 2010 6:06 PM
> To: Ersue, Mehmet (NSN - DE/Munich); Romascanu, Dan (Dan);=20
> Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>=20
> Hi Dan,
>=20
> The 'if present' for the username node covers cases where=20
> there may not be a specific 'username' for the session (as=20
> Martin noted below), but also cases where the server may=20
> choose to specifically omit this from the response.  E.g.=20
> user specific data may be considered sensitive in some=20
> implementations and access to it may be more restricted than=20
> the other session details.
>=20

This later seems to me a different case than 'if present'. The
information exists but is considered security-sensitive. I also do not
think that it is an implementation-specific issue, but a
deployment-specific issue. How does the server 'choose' to omit the user
name from a response? Is this a global (per server) decision or a per
user decision?=20

Dan


From phil@juniper.net  Fri Apr 30 07:54:07 2010
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CE33A69B9 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 07:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImUI+uPC2CNT for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 07:54:07 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 0A1EE3A695C for <netconf@ietf.org>; Fri, 30 Apr 2010 07:54:05 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS9ru/9hjyHVE6vBTjJ2DPYW5jRBddRxx@postini.com; Fri, 30 Apr 2010 07:53:53 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Fri, 30 Apr 2010 07:51:10 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 07:51:10 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Apr 2010 07:51:09 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 07:51:09 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o3UEp6D52474; Fri, 30 Apr 2010 07:51:06 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o3UEY42M068686; Fri, 30 Apr 2010 14:34:04 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <201004301434.o3UEY42M068686@idle.juniper.net>
To: <andyb@iwl.com>
In-Reply-To: <4BDA3FA5.4020306@iwl.com> 
Date: Fri, 30 Apr 2010 10:34:04 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 30 Apr 2010 14:51:09.0418 (UTC) FILETIME=[91D7F4A0:01CAE874]
MIME-Version: 1.0
Content-Type: text/plain
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 14:54:08 -0000

Andy Bierman writes:
>Hi,
>
>Here are more issues for 4741bis:
>
>1) :url as a source for <edit-config>
>   (Martin already raised this issue)
>
>         choice edit-content {
>           mandatory true;
>           anyxml config {
>             description
>               "Inline Config content: 'config' element.
>                This is not full 'anyxml' because the <config>
>                element cannot directly contain a text node.";
>           }

I may be missing something, but why can't I put text in <config>?
If my data model (which NETCONF doesn't care about) is text-based
config, can I not put that config directly in the <config> element?

>           leaf url {
>             if-feature url;
>             type inet:uri;
>           }
>         }
>
>   The edit-config operation allows <url> as a source,
>   but there is no explanation what the file has to contain.

The file contains data acceptable to the data model(s) supported
by the device.  You can say "go load that file" instead of putting
it inline with the <config> element.

>   Does it even have to be XML?

If should be any content that would be acceptable in a <config>
element.

>   There is no <get-config> support for a URL database,
>   so why should there be any partial database editing?

What's an "URL database"?

>   Since the URL file always represents a complete database,
>   there are no operations other than copy-config and delete-config
>   that apply to it.

You aren't editing an URL file, you are using a file as an alternative
to <config>.  That's why it's inside a "choice".

>2) There is no lock support at all for URL databases, so it is 
>   not even clear that copy and delete are properly supported.
>
>   Issue: Should <url> be allowed in <lock> and <unlock>
>   operations?

Again, what's an URL database?  This is a new concept not
currently in 4741.

>3) :url interoperability
>
>   It is not clear what a client application should expect
>   for any given scheme, or what schemes a server SHOULD
>   or even MAY support.
>
>   Issue: is the :url capability interoperable?
>   If not, what should be done about it?

Not sure I follow you here, but the scheme allows the server
to tell the client what it supports.  There is no SHOULD or
MUST, and MAY is pointless.

>   Current text:
>       Similarly, just because someone says "go write a configuration
>       through the URL capability at a particular place", this does not mean
>       that an element should do it without proper authorization.

s/element/device/

s/someone/a client/

>5) 'file' scheme
>
>   It is not clear whether:
>     - absolute path specs must be supported by the server
>     - the path-spec represents a conceptual file-system in 
>       the server, or the real file-system.
>     - sub-directories must be supported
>     - how many sub-directory levels deep are allowed
>     - other restrictions apply, such as naming, number of files, etc.
>     - if the internal mirrored NV-store is really a file,
>       whether this file is accessible via the <url> parameter.
>     - if the external :startup config is accessible via the <url> 
>       parameter.
>
>   Issue: are any guidelines needed for the 'file' scheme?
>   This is the most likely scheme to be supported by a server.

There are massive interoperability issues with "file:", but
clearly absolute paths are required (file:///), but that the
device need not allow direct access to its native file systems,
if any, so the device can use any file naming mechanism.  There
are no requirements in place re: directories, etc.  Given the
extreme range of networking gear, I'm not sure this is worth
diving into.

Thanks,
 Phil

From andyb@iwl.com  Fri Apr 30 10:03:18 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA0A3A69E1 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 10:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level: 
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydF13tWU+7G4 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 10:03:17 -0700 (PDT)
Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id C30A93A6928 for <netconf@ietf.org>; Fri, 30 Apr 2010 10:03:16 -0700 (PDT)
Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 88F5A1B48B3; Fri, 30 Apr 2010 13:02:56 -0400 (EDT)
Received: by relay21.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2B1291B4163;  Fri, 30 Apr 2010 13:02:56 -0400 (EDT)
Message-ID: <4BDB0D40.9050808@iwl.com>
Date: Fri, 30 Apr 2010 10:02:56 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
References: <201004301434.o3UEY42M068686@idle.juniper.net>
In-Reply-To: <201004301434.o3UEY42M068686@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 17:03:18 -0000

Phil Shafer wrote:
> Andy Bierman writes:
>   
>> Hi,
>>
>> Here are more issues for 4741bis:
>>
>> 1) :url as a source for <edit-config>
>>   (Martin already raised this issue)
>>
>>         choice edit-content {
>>           mandatory true;
>>           anyxml config {
>>             description
>>               "Inline Config content: 'config' element.
>>                This is not full 'anyxml' because the <config>
>>                element cannot directly contain a text node.";
>>           }
>>     
>
> I may be missing something, but why can't I put text in <config>?
> If my data model (which NETCONF doesn't care about) is text-based
> config, can I not put that config directly in the <config> element?
>
>   


The NETCONF database is XML.
Standard YANG modules will add child elements to
the <config> element.  Your string database will
be incompatible will all YANG modules.  None of the
filtering or editing operations work on a text <config>
element.

I don't see why the standard should support pointless
or awful data modeling practices.  We forbid XSD list
and XML attributes because they are 'bad practices'.


>>           leaf url {
>>             if-feature url;
>>             type inet:uri;
>>           }
>>         }
>>
>>   The edit-config operation allows <url> as a source,
>>   but there is no explanation what the file has to contain.
>>     
>
> The file contains data acceptable to the data model(s) supported
> by the device.  You can say "go load that file" instead of putting
> it inline with the <config> element.
>   

There is no text in the RFC that treats file contents
differently -- that means they are not different.
That means they must have correct standard contents,
exactly as if the XML was delivered on-the-wire
instead of read from a file.


>   
>>   Does it even have to be XML?
>>     
>
> If should be any content that would be acceptable in a <config>
> element.
>   

Since NETCONF forbids mixed content,
the server either has XML contents or
is a single string.  I suppose if a vendor
wanted to pretend they really support NETCONF,
then a single text string database would seem
like a good idea.  No YANG module could ever be
supported by that vendor.


>   
>>   There is no <get-config> support for a URL database,
>>   so why should there be any partial database editing?
>>     
>
> What's an "URL database"?
>   

an entry in the monitoring data model <databases> element
will exist for each <url> database.  This can be the source
or target of any copy-config operation.  Again, NETCONF
does not make any distinction between copying to <running>
or copying to file:///foo.xml.


>   
>>   Since the URL file always represents a complete database,
>>   there are no operations other than copy-config and delete-config
>>   that apply to it.
>>     
>
> You aren't editing an URL file, you are using a file as an alternative
> to <config>.  That's why it's inside a "choice".
>
>   

You can only provide URL as a source and it represents
an entire config, which is redundant -- the only thing you
can do with edit-config(url) is what you can already do
with copy-config(url).


>> 2) There is no lock support at all for URL databases, so it is 
>>   not even clear that copy and delete are properly supported.
>>
>>   Issue: Should <url> be allowed in <lock> and <unlock>
>>   operations?
>>     
>
> Again, what's an URL database?  This is a new concept not
> currently in 4741.
>
>   

User A: copy-config A to C
User B: copy-config B to C

locking applies to URL as a target just as much as
it applies to the other databases.  I don't understand
why 'hoping for the best' is an acceptable write-collision
strategy for :url, but not for other write targets.


>> 3) :url interoperability
>>
>>   It is not clear what a client application should expect
>>   for any given scheme, or what schemes a server SHOULD
>>   or even MAY support.
>>
>>   Issue: is the :url capability interoperable?
>>   If not, what should be done about it?
>>     
>
> Not sure I follow you here, but the scheme allows the server
> to tell the client what it supports.  There is no SHOULD or
> MUST, and MAY is pointless.
>   


At some point, NETCONF will attempt to advance to Draft Standard.
At that time, we will be forced to assess NETCONF interoperability.
Entire sections will be tossed out at that time, unless there are
2 independent inter-operating implementations.


>   
>>   Current text:
>>       Similarly, just because someone says "go write a configuration
>>       through the URL capability at a particular place", this does not mean
>>       that an element should do it without proper authorization.
>>     
>
> s/element/device/
>
> s/someone/a client/
>
>   
>> 5) 'file' scheme
>>
>>   It is not clear whether:
>>     - absolute path specs must be supported by the server
>>     - the path-spec represents a conceptual file-system in 
>>       the server, or the real file-system.
>>     - sub-directories must be supported
>>     - how many sub-directory levels deep are allowed
>>     - other restrictions apply, such as naming, number of files, etc.
>>     - if the internal mirrored NV-store is really a file,
>>       whether this file is accessible via the <url> parameter.
>>     - if the external :startup config is accessible via the <url> 
>>       parameter.
>>
>>   Issue: are any guidelines needed for the 'file' scheme?
>>   This is the most likely scheme to be supported by a server.
>>     
>
> There are massive interoperability issues with "file:", but
> clearly absolute paths are required (file:///), but that the
> device need not allow direct access to its native file systems,
> if any, so the device can use any file naming mechanism.  There
> are no requirements in place re: directories, etc.  Given the
> extreme range of networking gear, I'm not sure this is worth
> diving into.
>   

IMO, the :url capability is not interoperable and should
be removed from NETCONF, but since we are cycling at
Proposed Standard it is not important.

> Thanks,
>  Phil
>
>   
Andy


From andyb@iwl.com  Fri Apr 30 10:36:05 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A9A3A6A0F for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 10:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level: 
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNLUb8-AH72W for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 10:36:04 -0700 (PDT)
Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 03DC628C0CE for <netconf@ietf.org>; Fri, 30 Apr 2010 10:36:04 -0700 (PDT)
Received: from relay24.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 0FA6834E80E4; Fri, 30 Apr 2010 13:35:50 -0400 (EDT)
Received: by relay24.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 912CF34E803C;  Fri, 30 Apr 2010 13:35:49 -0400 (EDT)
Message-ID: <4BDB14F5.7000509@iwl.com>
Date: Fri, 30 Apr 2010 10:35:49 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Mark Scott <mark.scott@ericsson.com>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com><EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com>	<80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net>	<75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se>	<EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se>
In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 17:36:05 -0000

Mark Scott wrote:
> Dan,
>
> In one of our previous implementations only users whose privilege level included 'security admin' were allowed to see user specific data in any responses.  Such privileges were configured per user (i.e. per customer deployment) but the set of sensitive data was fixed on the server (i.e. per our server implementation).
>
> In this case we consciously chose not to use any of the existing errors to indicate partial operation or partial data.  This was on advice of our security primes who felt that indicating partial data invites further attempts to access it.
> 	- clearly this implementation was not 4741 compliant so I'm not proposing the above behaviour as standard but I assume others have dealt with such cases similarly
>
> In terms of clarifying this in the monitoring draft:
>
> I agree the term 'if present' isn't clear.
>
> How about:  'if the session is authorized to access such data the username will be in the reply.  If not this data must be omitted from the response.'?
>
> When adding the new yang module security template I can also specifically list the 'username' as potentially sensitive read-only data.  
>
> The template already contains multiple 'may be considered sensitive' clauses which reflect the points above.
>
>   

I don't think we should create any special cases that might
conflict with the NACM standard in the future.
The monitoring draft should have a security considerations
section, and not say anything about what the server must do
if unauthorized data needs to be handled.
This draft just needs to identify and explain the sensitive data.

> Mark
>   

Andy

>
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> Sent: April-29-10 3:52 AM
> To: Mark Scott; Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>
>  
>
>   
>> -----Original Message-----
>> From: Mark Scott [mailto:mark.scott@ericsson.com] 
>> Sent: Wednesday, April 28, 2010 6:06 PM
>> To: Ersue, Mehmet (NSN - DE/Munich); Romascanu, Dan (Dan); 
>> Martin Bjorklund
>> Cc: netconf@ietf.org
>> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>>
>> Hi Dan,
>>
>> The 'if present' for the username node covers cases where 
>> there may not be a specific 'username' for the session (as 
>> Martin noted below), but also cases where the server may 
>> choose to specifically omit this from the response.  E.g. 
>> user specific data may be considered sensitive in some 
>> implementations and access to it may be more restricted than 
>> the other session details.
>>
>>     
>
> This later seems to me a different case than 'if present'. The
> information exists but is considered security-sensitive. I also do not
> think that it is an implementation-specific issue, but a
> deployment-specific issue. How does the server 'choose' to omit the user
> name from a response? Is this a global (per server) decision or a per
> user decision? 
>
> Dan
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>   


From mark.scott@ericsson.com  Fri Apr 30 11:00:17 2010
Return-Path: <mark.scott@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7287328C17A for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 11:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level: 
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=2.650,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsqIw+20ENs3 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 11:00:16 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 646263A6B55 for <netconf@ietf.org>; Fri, 30 Apr 2010 11:00:16 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3UI4ZGi004568; Fri, 30 Apr 2010 13:05:02 -0500
Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 30 Apr 2010 13:59:47 -0400
From: Mark Scott <mark.scott@ericsson.com>
To: "andyb@iwl.com" <andyb@iwl.com>
Date: Fri, 30 Apr 2010 13:59:45 -0400
Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12
Thread-Index: Acroi7Uc8xyJTl06S8mwge8FDPbp5gAALhAQ
Message-ID: <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com><20100428.125626.169114362.mbj@tail-f.com><EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net> <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se> <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com>
In-Reply-To: <4BDB14F5.7000509@iwl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 18:00:17 -0000

Thanks Andy,

The security section will be updated and will include 'username' details pe=
r the new yang module template.

I will also remove the text suggesting the special handling ('if present') =
from sec 2.1.4:

"username (string)
     The username contains an identifier which can be used to=20
     uniquely identify an individual client (human or machine)."

and from the yang module:

"leaf username  {
          type string;
          description
            "The username contains an identifier which can
             be used to uniquely identify an individual client (human
             or machine).  This is likely to be implementation specific
             and subject to the security requirements of the device
             vendor and/or operators,  e.g., an SSH user, a host RSA
             fingerprint or other identifier deemed acceptable.";
        }"

cheers,
Mark

-----Original Message-----
From: Andy Bierman [mailto:andyb@iwl.com]=20
Sent: April-30-10 1:36 PM
To: Mark Scott
Cc: Romascanu, Dan (Dan); Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund=
; netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

Mark Scott wrote:
> Dan,
>
> In one of our previous implementations only users whose privilege level i=
ncluded 'security admin' were allowed to see user specific data in any resp=
onses.  Such privileges were configured per user (i.e. per customer deploym=
ent) but the set of sensitive data was fixed on the server (i.e. per our se=
rver implementation).
>
> In this case we consciously chose not to use any of the existing errors t=
o indicate partial operation or partial data.  This was on advice of our se=
curity primes who felt that indicating partial data invites further attempt=
s to access it.
> 	- clearly this implementation was not 4741 compliant so I'm not proposin=
g the above behaviour as standard but I assume others have dealt with such =
cases similarly
>
> In terms of clarifying this in the monitoring draft:
>
> I agree the term 'if present' isn't clear.
>
> How about:  'if the session is authorized to access such data the usernam=
e will be in the reply.  If not this data must be omitted from the response=
.'?
>
> When adding the new yang module security template I can also specifically=
 list the 'username' as potentially sensitive read-only data. =20
>
> The template already contains multiple 'may be considered sensitive' clau=
ses which reflect the points above.
>
>  =20

I don't think we should create any special cases that might
conflict with the NACM standard in the future.
The monitoring draft should have a security considerations
section, and not say anything about what the server must do
if unauthorized data needs to be handled.
This draft just needs to identify and explain the sensitive data.

> Mark
>  =20

Andy

>
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
> Sent: April-29-10 3:52 AM
> To: Mark Scott; Ersue, Mehmet (NSN - DE/Munich); Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>
> =20
>
>  =20
>> -----Original Message-----
>> From: Mark Scott [mailto:mark.scott@ericsson.com]=20
>> Sent: Wednesday, April 28, 2010 6:06 PM
>> To: Ersue, Mehmet (NSN - DE/Munich); Romascanu, Dan (Dan);=20
>> Martin Bjorklund
>> Cc: netconf@ietf.org
>> Subject: RE: [Netconf] AD review of draft-ietf-netconf-monitoring-12
>>
>> Hi Dan,
>>
>> The 'if present' for the username node covers cases where=20
>> there may not be a specific 'username' for the session (as=20
>> Martin noted below), but also cases where the server may=20
>> choose to specifically omit this from the response.  E.g.=20
>> user specific data may be considered sensitive in some=20
>> implementations and access to it may be more restricted than=20
>> the other session details.
>>
>>    =20
>
> This later seems to me a different case than 'if present'. The
> information exists but is considered security-sensitive. I also do not
> think that it is an implementation-specific issue, but a
> deployment-specific issue. How does the server 'choose' to omit the user
> name from a response? Is this a global (per server) decision or a per
> user decision?=20
>
> Dan
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>  =20


From j.schoenwaelder@jacobs-university.de  Fri Apr 30 12:35:00 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D32D3A6B0E for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 12:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.067
X-Spam-Level: 
X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1JEJAnDm9AJ for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 12:34:59 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 091703A6ACA for <netconf@ietf.org>; Fri, 30 Apr 2010 12:34:59 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09BB4C0004; Fri, 30 Apr 2010 21:34:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CEu2qwwq0PAA; Fri, 30 Apr 2010 21:34:44 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6942C0002; Fri, 30 Apr 2010 21:34:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 335A011D5F76; Fri, 30 Apr 2010 21:34:39 +0200 (CEST)
Date: Fri, 30 Apr 2010 21:34:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mark Scott <mark.scott@ericsson.com>
Message-ID: <20100430193439.GA4169@elstar.local>
Mail-Followup-To: Mark Scott <mark.scott@ericsson.com>, "andyb@iwl.com" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <EDC652A26FB23C4EB6384A4584434A04021451FD@307622ANEX5.global.avaya.com> <20100428.125626.169114362.mbj@tail-f.com> <EDC652A26FB23C4EB6384A4584434A0402145534@307622ANEX5.global.avaya.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net> <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se> <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com> <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 19:35:00 -0000

On Fri, Apr 30, 2010 at 07:59:45PM +0200, Mark Scott wrote:
> 
> I will also remove the text suggesting the special handling ('if present') from sec 2.1.4:
> 
> "username (string)
>      The username contains an identifier which can be used to 
>      uniquely identify an individual client (human or machine)."

Now that we have the text in front of us: 'contains an identifier' or
'is an identifier'? what does 'uniquely identify an individual client'
mean? If I have user joe using two clients a and b to access a server
concurrently, will the usernames be "joe-a" and "joe-b"? Likely not,
but the text says "uniquely identify an individual client". And what
does (human or machine) mean? Whether joe relates to a human or a
program, a server won't know. So what about this:

      The username identifies the authenticated identity on which
      behalf a client accesses a server.

I believe this is shorter and more precise.
 
> and from the yang module:
> 
> "leaf username  {
>           type string;
>           description
>             "The username contains an identifier which can
>              be used to uniquely identify an individual client (human
>              or machine).  This is likely to be implementation specific
>              and subject to the security requirements of the device
>              vendor and/or operators,  e.g., an SSH user, a host RSA
>              fingerprint or other identifier deemed acceptable.";
>         }"

Similar changes should be done here if people like my proposal.

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

From mbj@tail-f.com  Fri Apr 30 13:52:28 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6410F3A68FA for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 13:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.152
X-Spam-Level: 
X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=0.894,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjpfb4j1bowZ for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 13:52:27 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8DCD83A67AB for <netconf@ietf.org>; Fri, 30 Apr 2010 13:52:27 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 7EF10616001; Fri, 30 Apr 2010 22:52:12 +0200 (CEST)
Date: Fri, 30 Apr 2010 22:52:11 +0200 (CEST)
Message-Id: <20100430.225211.143795604.mbj@tail-f.com>
To: andyb@iwl.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4BDB14F5.7000509@iwl.com>
References: <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com>
X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 20:52:28 -0000

Andy Bierman <andyb@iwl.com> wrote:
> I don't think we should create any special cases that might
> conflict with the NACM standard in the future.
> The monitoring draft should have a security considerations
> section, and not say anything about what the server must do
> if unauthorized data needs to be handled.
> This draft just needs to identify and explain the sensitive data.

I fully agree with this.


/martin

From mbj@tail-f.com  Fri Apr 30 13:57:58 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9137D3A68B9 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 13:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.297
X-Spam-Level: 
X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN7kdgkO+RMv for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 13:57:58 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D0CBF3A68FA for <netconf@ietf.org>; Fri, 30 Apr 2010 13:57:57 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id A8166616001; Fri, 30 Apr 2010 22:57:43 +0200 (CEST)
Date: Fri, 30 Apr 2010 22:57:43 +0200 (CEST)
Message-Id: <20100430.225743.53755455.mbj@tail-f.com>
To: mark.scott@ericsson.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se>
References: <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com> <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se>
X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 20:57:58 -0000

Mark Scott <mark.scott@ericsson.com> wrote:
> Thanks Andy,
> 
> The security section will be updated and will include 'username'
> details per the new yang module template. 
> 
> I will also remove the text suggesting the special handling ('if
> present') from sec 2.1.4: 
> 
> "username (string)
>      The username contains an identifier which can be used to 
>      uniquely identify an individual client (human or machine)."
> 
> and from the yang module:
> 
> "leaf username  {
>           type string;
>           description
>             "The username contains an identifier which can
>              be used to uniquely identify an individual client (human
>              or machine).  This is likely to be implementation specific
>              and subject to the security requirements of the device
>              vendor and/or operators,  e.g., an SSH user, a host RSA
>              fingerprint or other identifier deemed acceptable.";
>         }"

If we agree that the username is always there, we should add a
'mandatory true;' statement to the leaf.


/martin

From mbj@tail-f.com  Fri Apr 30 14:31:43 2010
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1EE28C0FF for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 14:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level: 
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.828,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZZZns+3H2im for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 14:31:41 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B06283A6C71 for <netconf@ietf.org>; Fri, 30 Apr 2010 14:31:41 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 81E2C616001; Fri, 30 Apr 2010 23:31:27 +0200 (CEST)
Date: Fri, 30 Apr 2010 23:31:26 +0200 (CEST)
Message-Id: <20100430.233126.188322952.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <201004301434.o3UEY42M068686@idle.juniper.net>
References: <4BDA3FA5.4020306@iwl.com> <201004301434.o3UEY42M068686@idle.juniper.net>
X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 21:31:43 -0000

Phil Shafer <phil@juniper.net> wrote:
> Andy Bierman writes:
> >Hi,
> >
> >Here are more issues for 4741bis:
> >
> >1) :url as a source for <edit-config>
> >   (Martin already raised this issue)
> >
> >         choice edit-content {
> >           mandatory true;
> >           anyxml config {
> >             description
> >               "Inline Config content: 'config' element.
> >                This is not full 'anyxml' because the <config>
> >                element cannot directly contain a text node.";
> >           }
> 
> I may be missing something, but why can't I put text in <config>?
> If my data model (which NETCONF doesn't care about) is text-based
> config, can I not put that config directly in the <config> element?
> 
> >           leaf url {
> >             if-feature url;
> >             type inet:uri;
> >           }
> >         }
> >
> >   The edit-config operation allows <url> as a source,
> >   but there is no explanation what the file has to contain.
> 
> The file contains data acceptable to the data model(s) supported
> by the device.  You can say "go load that file" instead of putting
> it inline with the <config> element.
> 
> >   Does it even have to be XML?
> 
> If should be any content that would be acceptable in a <config>
> element.

The problem with this that in the <config> element, you may have
several child elements, e.g.:

  <config>
    <interface xmlns="urn:ietf...:inteface">
      ...
    <interface>
    <nacm xmlns="urn:ietf....nacm">
      ...
    </nacm>
  </config>

If you just copy the stuff in the <config> element and put it into a
file, you will get an invalid XML document.  Now, this may not be a
problem, but if this is something we want to support in an
interoperable way, we need to define how this should work.

(But I don't think this is an important feature, and would rather see
it removed.)



/martin

From andyb@iwl.com  Fri Apr 30 15:49:15 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2502E3A68CB for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 15:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.215
X-Spam-Level: 
X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.384,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKKLvm5nrVz8 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 15:49:14 -0700 (PDT)
Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id 55B2B3A67D7 for <netconf@ietf.org>; Fri, 30 Apr 2010 15:49:14 -0700 (PDT)
Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E0C551B4052; Fri, 30 Apr 2010 18:48:58 -0400 (EDT)
Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 83CAC1B404C;  Fri, 30 Apr 2010 18:48:58 -0400 (EDT)
Message-ID: <4BDB5E5A.5040901@iwl.com>
Date: Fri, 30 Apr 2010 15:48:58 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BDA3FA5.4020306@iwl.com>	<201004301434.o3UEY42M068686@idle.juniper.net> <20100430.233126.188322952.mbj@tail-f.com>
In-Reply-To: <20100430.233126.188322952.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 22:49:15 -0000

Martin Bjorklund wrote:
> Phil Shafer <phil@juniper.net> wrote:
>   
>> Andy Bierman writes:
>>     
>> ....
>>     
>>>   Does it even have to be XML?
>>>       
>> If should be any content that would be acceptable in a <config>
>> element.
>>     
>
> The problem with this that in the <config> element, you may have
> several child elements, e.g.:
>
>   <config>
>     <interface xmlns="urn:ietf...:inteface">
>       ...
>     <interface>
>     <nacm xmlns="urn:ietf....nacm">
>       ...
>     </nacm>
>   </config>
>
> If you just copy the stuff in the <config> element and put it into a
> file, you will get an invalid XML document.  Now, this may not be a
> problem, but if this is something we want to support in an
> interoperable way, we need to define how this should work.
>
> (But I don't think this is an important feature, and would rather see
> it removed.)
>
>   

The IETF is moving forward with YANG and standard
NETCONF data models will use YANG.

Technically, a 4741 server can contain a string.
That does not mean we have to allow that  in 4741bis,
now that we are using YANG instead of continuing
with an ad-hoc opaque content layer.

Since the 'single-string' <config> is completely
incompatible with YANG modules, there is no role
for such a server implementation in the standard.

But we can remove the description-stmt text in question,
and be silent on this issue.  It is a market decision
whether or not a vendor wants to sell a NETCONF server
that can never implement a YANG module.


>
> /martin
>
>   

Andy


From andyb@iwl.com  Fri Apr 30 18:41:42 2010
Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D8A3A6912 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 18:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.179
X-Spam-Level: 
X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKRkAFUcFdjv for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 18:41:41 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 897BA3A67EB for <netconf@ietf.org>; Fri, 30 Apr 2010 18:41:41 -0700 (PDT)
Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 70222303C2;  Fri, 30 Apr 2010 21:41:27 -0400 (EDT)
Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3F85E30032;  Fri, 30 Apr 2010 21:41:27 -0400 (EDT)
Message-ID: <4BDB86C8.6030907@iwl.com>
Date: Fri, 30 Apr 2010 18:41:28 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BDA3FA5.4020306@iwl.com> <20100430.123559.164315822.mbj@tail-f.com>
In-Reply-To: <20100430.123559.164315822.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 May 2010 01:41:42 -0000

Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman <andyb@iwl.com> wrote:
>   
> ....
>   
>>      - the path-spec represents a conceptual file-system in 
>>        the server, or the real file-system.
>>     
>
> An implementation detail IMO.
>
>   


The problem is that way too much of the :url capability
is left as an implementation detail.

There is no way for a client/operator to know from
the standard:
   - what file restrictions are enforced by the server
   - what URL files even exist (the monitoring module
     only supports candidate, running, and startup).

We usually try to announce server capabilities in
the protocol instead of forcing users to call
tech-support, or fish through WEB docs to find out
the same information.

Seems like it would be useful to know what local <url>
database files are available at any given time.
I thought this was supported in the monitoring draft.
I guess locks do not apply, so the existing <database>
element is not appropriate.


Andy


From j.schoenwaelder@jacobs-university.de  Fri Apr 30 23:32:57 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113893A6A6C for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 23:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_40=-0.185, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lskkhS2NgyrE for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 23:32:56 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EB8423A6A64 for <netconf@ietf.org>; Fri, 30 Apr 2010 23:32:55 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20A68C0024; Sat,  1 May 2010 08:32:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D62GhaSyivVT; Sat,  1 May 2010 08:32:39 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5EB9C0009; Sat,  1 May 2010 08:32:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 731FE11D6E7E; Sat,  1 May 2010 08:32:35 +0200 (CEST)
Date: Sat, 1 May 2010 08:32:35 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20100501063235.GB5047@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, "andyb@iwl.com" <andyb@iwl.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <EDC652A26FB23C4EB6384A4584434A040214574C@307622ANEX5.global.avaya.com> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com> <20100430.225211.143795604.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100430.225211.143795604.mbj@tail-f.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 May 2010 06:32:57 -0000

On Fri, Apr 30, 2010 at 10:52:11PM +0200, Martin Bjorklund wrote:
> Andy Bierman <andyb@iwl.com> wrote:
> > I don't think we should create any special cases that might
> > conflict with the NACM standard in the future.
> > The monitoring draft should have a security considerations
> > section, and not say anything about what the server must do
> > if unauthorized data needs to be handled.
> > This draft just needs to identify and explain the sensitive data.
> 
> I fully agree with this.

+1

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